Attaching arbitrary conditions to unconfirmed transactions

This is motivated by the “Short-lived Unconfirmed Transactions: Paying for Coffee” example in section 2.1 of the “Advanced ErgoScript Tutorial”:

alice && HEIGHT <= getVar[Int](1).get

This contract allows Alice to pick an expiry height when they create a spending transaction, by specifying it as part of the context extension.

To make things more interesting, consider the following script:

SigmaAnd(ProveDlog(alice), DeserializeContext(0, SSigmaProp))

(Unfortunately, I don’t think the ErgoScript compiler frontend supports deserializeContext at the moment, so the above is in Scala.)

Now, this allows Alice to specify an arbitrary script at spend time, such that the script must evaluate to true for it to be mined in a particular block.

The conditions most likely to be attached are those relating to the block header e.g. the block height as per the coffee example, but note that a minimum height can be set instead of a maximum height if this is useful (I’m not sure if this case would be immediately rejected from the mempool, however). Alice can specify true if they do not want any conditions at all.

The original concept of setting an expiry height on transactions is quite good, and even Zcash has a built-in nExpiryHeight (set to 20 blocks), the main motivation being to provide more certainty for users: if their transaction is not confirmed with 20 blocks, then they probably need to resend, possibly with a higher fee.

Allowing completely arbitrary conditions to be set (other than an expiry height) for a spending transaction to be mined is probably not particularly useful (and the execution cost is almost definitely higher), but I thought it would be interesting nonetheless.

3 Likes

Another condition that could be attached to unconfirmed transactions is that the miner places particular votes (bribery!). This wouldn’t work at the moment, since votes do not form part of the context used to validate transactions by the mempool.

1 Like

I believe supplying script at run-time can be useful. For the coffee case, Alice has to store funds in a specially created box. This approach allows Alice to store funds in a “generic” box where she can add other conditions. One condition would obviously be HEIGHT <= 1234 as in the coffee case, and she could add HEIGHT >= 1234, where the box can only be spent after a certain height for a different use-case.

There should be more interesting use-cases of specifying the script at run-time. Not sure exactly what what scripts can be supported… For instance, you probably cannot call DeserializeContext within the new script.

1 Like