mimblewimble team mailing list archive

[Myrtle Warren <MoaningMyrtle@xxxxxxxxxxxxxx>]

> 2. Lack of position
>
> We can’t use the position of the script itself, since it won’t enter the
> blockchain until after it has been validated. However, we can use other
> ‘triggers’ instead: simply point to other data on the blockchain (or data
> that will be published at a later date) and use that position instead. As
> the name implies, the data acts as a trigger to the validity of the
> transaction.
>
> A simplified example: transaction A is only valid if a trigger in the form
> of transaction B is in the blockchain and buried under 3 days of work. Note
> how only the owner of transaction B had the ability to publish this
> trigger. It is more versatile than relative locktime in bitcoin and can
> serve the same function as HLTCs for Lightning [3].


I think I'm missing something here; do we need a special construct to do this? Doesn't the input/output system provide this functionality? If the "trigger" is an output (denoted by its commitment) supplied by a counterparty, and transaction A spends this output (in addition to any others it needs to serve its purpose), transaction A can only be broadcast successfully once a transaction that pays this output has been propagated. Due to the need for cooperative transaction creation in mimblewimble it is impossible for the holder of transaction A (or any other party) to create the relevant output without the consent of the counterparty. Combine this with a relative locktime and it seems like you have the pieces you need for the rest of the exchange.