> 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.
--
Mailing list: https://launchpad.net/~mimblewimble
Post to : [email protected]
Unsubscribe : https://launchpad.net/~mimblewimble
More help : https://help.launchpad.net/ListHelp
