On Sun, Aug 16, 2020 at 11:41:30AM -0400, Thomas Hartman via bitcoin-dev wrote: > First, I would like to pay respects to tamas blummer, RIP. > > https://bitcoinmagazine.com/articles/remembering-tamas-blummer-pioneering-bitcoin-developer
RIP, Tamas. > Tamas proposed an additional opcode for enabling bitcoin difficulty > futures, on this list at > > https://www.mail-archive.com/[email protected]/msg07991.html Subsequent to Blummer's post, I heard from Jeremy Rubin about a scheme[1] that allows difficulty futures without requiring any changes to Bitcoin. In short, it takes advantage of the fact that changes in difficulty also cause a difference in maturation time between timelocks and height-locks. As an simple example: 1. Alice and Bob create an unsigned transaction that deposits their money into a 2-of-2 multisig. 2. They cooperate to create and sign two conflicting spends from the multisig: a. Pays Alice with an nLockTime(height) of CURRENT_HEIGHT + 2016 blocks b. Pays Bob with an nLockTime(time) of CURRENT_TIME + 2016 * 10 * 60 seconds 3. After both conflicting spends are signed, Alice and Bob sign and broadcast the deposit transaction from #1. 4. If hashrate increases during the subsequent period, the spend that pays Alice will mature first, so she broadcasts it and receives that money. If hashrate decreases, the spend to Bob matures first, so he receives the money. Of course, this basic formula can be tweaked to create other contracts, e.g. a contract that only pays if hashrate goes down more than 25%. As far as I can tell, this method should be compatible with offchain commitments (e.g. payments within channels) and could be embedded in a taproot commitment using OP_CLTV or OP_CSV instead of nLockTime. -Dave [1] https://powswap.com/
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
