Good morning Tier, Thomas, and aj, > On Sun, Aug 16, 2020 at 4:50 PM Thomas Hartman via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > > My understanding is that adding a single op_difficulty operation as > > proposed would enable not true difficulty futures but binary options > > on difficulty. > > > > https://en.wikipedia.org/wiki/Binary_option > > Any kind of opcode is a binary option. Either the output can be spent or it > can't. > > You could get a pseudo-continuous future by having lots of outputs with > different thresholds. > > Alice and Bob create a transaction with 100 outputs and each having 1% of the > future's value. > > Output 0: Pay Alice if diff < 1.00 trillion else Bob > Output 1: Pay Alice if diff < 1.01 trillion else Bob > .... > Output 98: Pay Alice if diff < 1.98 trillion else Bob > Output 99: Pay Alice if diff < 1.99 trillion else Bob > > If the difficulty is 1.25 trillion, then Alice gets outputs 0-24 and Bob gets > outputs 25-99. The future has a tick size of 1%. It isn't very efficient > though
Taproot MAST to the rescue. * Alice and Bob agree on the number of ticks N and payout schedule. * Alice and Bob generate N fresh keypairs and share them. * Alice and Bob generate tapleaf scripts of the form: * script[i] = Alice[i] && Bob[i] && diff < 1.00 trillion + i * tick_size && CLTV(deadline) * Alice and Bob generate the taproot MAST for the above scripts. * Alice and Bob generate, but do ***NOT*** sign, a funding transaction paying out to the generated taproot MAST. * Bob generates partial signatures for N payout transactions, with lower-difficulty-targets paying out less to Alice and more to Bob, and higher-difficulty-targets paying out more to Alice and less to Bob. * This requires spending the [i]th tapleaf script with the appropriate difficulty target. * Alice saves all the Bob signatures. * At deadline, Alice rationally selects the highest-paying version that is still acceptable, based on the actual difficulty target at the time. This requires publishing only O(log N) data (the merkle path to the selected tapleaf). This translates to the 100-tick example requiring only one TXO, 1 scripthash, and 7 or so Merkle-tree-path hashes, compared to the above example which requires 100 TXOs and 100 script hashes. The same scheme can be used with `OP_CTV` and without keypairs being involved, but basically anything `OP_CTV` can do, signing keypairs with pre-generated signatures from all participants can do just as well, with higher storage and setup costs. Regards, ZmnSCPxj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
