* [bitcoin-dev] How to preserve the value of coins after a fork. @ 2015-12-30 20:08 Emin Gün Sirer 2015-12-30 20:16 ` Peter Todd 0 siblings, 1 reply; 5+ messages in thread From: Emin Gün Sirer @ 2015-12-30 20:08 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1915 bytes --] Ittay Eyal and I just put together a writeup that we're informally calling Bitcoin-United for preserving the value of coins following a permanent fork: http://hackingdistributed.com/2015/12/30/technique-to-unite-bitcoin-factions/ Half of the core idea is to eliminate double-spends (where someone spends a UTXO on chain A and the same UTXO on chain B, at separate merchants) by placing transactions from A on chain B, and by taking the intersection of transactions on chain A and chain B when considering whether a payment has been received. The other half of the core idea is to enable minting of new coins and collection of mining fees on both chains, while preserving the 21M maximum. This is achieved by creating a one-to-one correspondence between coins on one chain with coins on the other. Given the level of the audience here, I'm keeping the description quite terse. Much more detail and discussion is at the link above, as well as the assumptions that need to hold for Bitcoin-United. The high bit is that, with a few modest assumptions, it is possible to create a cohesive coin in the aftermath of a fork, even if the core devs are split, and even if one of the forks is (in the worst case) completely non-cooperative. Bitcoin-United is a trick to create a cohesive coin even when there is no consensus at the lowest level. Bitcoin-United opens up a lot of new, mostly game-theoretic questions: what happens to native clients who prefer A or B? What will happen to the value of native-A or native-B coins? And so on. We're actively working on these questions and more, but we wanted to share the Bitcoin-United idea, mainly to receive feedback, and partly to provide some hope about future consensus to the community. It turns out that it is possible to craft consensus at the network level even when there isn't one at the developer level. Happy New Year, and may 2016 be united, - egs & ittay [-- Attachment #2: Type: text/html, Size: 2285 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] How to preserve the value of coins after a fork. 2015-12-30 20:08 [bitcoin-dev] How to preserve the value of coins after a fork Emin Gün Sirer @ 2015-12-30 20:16 ` Peter Todd 2015-12-30 20:22 ` Emin Gün Sirer 0 siblings, 1 reply; 5+ messages in thread From: Peter Todd @ 2015-12-30 20:16 UTC (permalink / raw) To: Emin Gün Sirer, Emin Gün Sirer via bitcoin-dev, Bitcoin Dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Note how transaction malleability can quickly sabotage naive notions of this idea. Equally, if this looks like it might ever be implemented, rather than using a hard fork, using a forced soft-fork to deploy changes becomes attractive. On 30 December 2015 12:08:36 GMT-08:00, "Emin Gün Sirer via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote: >Ittay Eyal and I just put together a writeup that we're informally >calling >Bitcoin-United for preserving the value of coins following a permanent >fork: > > >http://hackingdistributed.com/2015/12/30/technique-to-unite-bitcoin-factions/ > >Half of the core idea is to eliminate double-spends (where someone >spends a >UTXO on chain A and the same UTXO on chain B, at separate merchants) by >placing transactions from A on chain B, and by taking the intersection >of >transactions on chain A and chain B when considering whether a payment >has >been received. > >The other half of the core idea is to enable minting of new coins and >collection of mining fees on both chains, while preserving the 21M >maximum. >This is achieved by creating a one-to-one correspondence between coins >on >one chain with coins on the other. > >Given the level of the audience here, I'm keeping the description quite >terse. Much more detail and discussion is at the link above, as well as >the >assumptions that need to hold for Bitcoin-United. > >The high bit is that, with a few modest assumptions, it is possible to >create a cohesive coin in the aftermath of a fork, even if the core >devs >are split, and even if one of the forks is (in the worst case) >completely >non-cooperative. Bitcoin-United is a trick to create a cohesive coin >even >when there is no consensus at the lowest level. > >Bitcoin-United opens up a lot of new, mostly game-theoretic questions: >what >happens to native clients who prefer A or B? What will happen to the >value >of native-A or native-B coins? And so on. > >We're actively working on these questions and more, but we wanted to >share >the Bitcoin-United idea, mainly to receive feedback, and partly to >provide >some hope about future consensus to the community. It turns out that it >is >possible to craft consensus at the network level even when there isn't >one >at the developer level. > >Happy New Year, and may 2016 be united, >- egs & ittay > > >------------------------------------------------------------------------ > >_______________________________________________ >bitcoin-dev mailing list >bitcoin-dev@lists.linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev - -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -----BEGIN PGP SIGNATURE----- iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJWhDuA AAoJEMCF8hzn9Lncz4MIAIObFNbRRJ5g52H8yprqAjX76Lt7vw+cwCnICNzHra5h iuTWxgbwED5fki2Q96ZzYAyUf7ju7rI45qBl8YuuVUlyxJgE6oV6h2oJoxGQNGz0 WvrOjWMkmARNs0FM4GMsKQWcmIMgZxWnWTMOXv0EDBLySsm8WFRu9H4drGBB+Fmb wFRyi0XVDiXxsVUoNj6pCdcpekdnuq+V87IoweoxigfqgWIM31Vb9QK8Y/7vWO2b 0lu0CvVdqvw5Npx55LWLF1tY8jbw6BYvgXwZGtUazKO+x8i3Qt6+tRm07+UXvkoR 3erxzhnoZa3F66ufz+ImY7l0E/AyRE5ox+1W68hO6sk= =d0+L -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] How to preserve the value of coins after a fork. 2015-12-30 20:16 ` Peter Todd @ 2015-12-30 20:22 ` Emin Gün Sirer 2015-12-30 20:32 ` Peter Todd 0 siblings, 1 reply; 5+ messages in thread From: Emin Gün Sirer @ 2015-12-30 20:22 UTC (permalink / raw) To: Peter Todd; +Cc: Emin Gün Sirer via bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1201 bytes --] On Wed, Dec 30, 2015 at 3:16 PM, Peter Todd <pete@petertodd.org> wrote: > Note how transaction malleability can quickly sabotage naive notions of > this idea. > Bitcoin-United relies on a notion of transaction equivalence that doesn't involve the transaction hash at all, so it should be immune to malleability issues and compatible with segwit. From the post, two transactions are equal if they "consume the same inputs and result in the same outputs, not counting the miner fee. Simple pay-to-pubkey-hash and pay-to-script-hash transactions are straightforward. Multikey transactions are evaluated for equivalency by their inputs and outputs, so it is allowable for a 2-out-of-3 payment to be signed by one set of two keys on Dum and another set of two keys on Dee, as long as the transaction consumes the same coins and produces the same outputs. Not that we'll ever encounter such a case, but making this point helps pedagogically with getting across the notion of transaction equivalence. What counts are the consumed inputs and the destination and amounts of the outputs." But you're right, if a naive implementation were to just use the transaction hash, the result would be a mess. - egs [-- Attachment #2: Type: text/html, Size: 1731 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] How to preserve the value of coins after a fork. 2015-12-30 20:22 ` Emin Gün Sirer @ 2015-12-30 20:32 ` Peter Todd 2015-12-30 23:13 ` Nick ODell 0 siblings, 1 reply; 5+ messages in thread From: Peter Todd @ 2015-12-30 20:32 UTC (permalink / raw) To: Emin Gün Sirer; +Cc: Emin Gün Sirer via bitcoin-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 30 December 2015 12:22:43 GMT-08:00, "Emin Gün Sirer" <el33th4x0r@gmail.com> wrote: >On Wed, Dec 30, 2015 at 3:16 PM, Peter Todd <pete@petertodd.org> wrote: > >> Note how transaction malleability can quickly sabotage naive notions >of >> this idea. >> > >Bitcoin-United relies on a notion of transaction equivalence that >doesn't >involve the transaction hash at all, so it should be immune to >malleability >issues and compatible with segwit. > From the post, two transactions are equal if they "consume the same >inputs >and result in the same outputs, not counting the miner fee. Simple >pay-to-pubkey-hash and pay-to-script-hash transactions are >straightforward. >Multikey transactions are evaluated for equivalency by their inputs and >outputs, so it is allowable for a 2-out-of-3 payment to be signed by >one >set of two keys on Dum and another set of two keys on Dee, as long as >the >transaction consumes the same coins and produces the same outputs. Not >that >we'll ever encounter such a case, but making this point helps >pedagogically >with getting across the notion of transaction equivalence. What counts >are >the consumed inputs and the destination and amounts of the outputs." You seem to not be familiar with how multisig transactions on Bitcoin work - 99.9% of the time theyre hidden behind p2sh and there is no way to know what keys are involved. Equally, multisig is just one of many complex scripts possible. Look into what a segwit transaction hashes - that's a better notion of non-malleable transaction. But even then lots of transactions are malleable, and its easy to trigger those cases intentionally by third parties. Most likely any Bitcoin United scheme would quickly diverge and fail; much simpler and more predictable to achieve convincing consensus, e.g. via proof of stake voting, or Adam Bank's extension blocks suggestions. (or of course, not trying to force controversial forks in the first place) -----BEGIN PGP SIGNATURE----- iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJWhD9N AAoJEMCF8hzn9Lncz4MH/0JPGVc2JLtD5q0I2w0vqmBqsoSzSueCtnKa2K1Ea10g w9I4uhK7+cgfCLbofJznVHMChXu0uCxtWwqSj++uJx238TEupcu951gUhFfuPOeH Egye8jmDkDFiB1P40kUSVk9N64Zt3kWLk4xSsfjawVHz/WWpM24Fn8k/bmI7JiLl nmVwoBdRsTKffM/1dr8ix4U8YPSmJ7W+jAByNHUpSgc1R73YylqNT95pF8QD35df dQwSK9DIc+2N4CKnp22xLvYeCivFjeS2Fm4kbcKQwMjcqlJ1mWghP/c8q/lzhaGN Ac15/pgeHp8dPP8c81zkN9ps14rrnXoHnrzjiY+TwKY= =FfK1 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] How to preserve the value of coins after a fork. 2015-12-30 20:32 ` Peter Todd @ 2015-12-30 23:13 ` Nick ODell 0 siblings, 0 replies; 5+ messages in thread From: Nick ODell @ 2015-12-30 23:13 UTC (permalink / raw) To: bitcoin-dev Emin, I have two technical criticisms of your proposal, and one economic criticism. >Unified miners would make sure that they mine transactions on Dum first, then on Dee. Recall that Dee miners can always just take Dum transactions and stick them in their blocks. This seems to contradict a later section that says that users can use Dee natively, without paying fees necessary to get a transaction into Dum. You can't have this both ways - either you can get a transaction into Dee without getting it into Dum first, or you can't. >Such an attack would be quite visible, and it would leave Dum vulnerable. Unified clients could counter this launching a 51% counterattack on Dum. What if some other group that wants to hurt both Dum and Dee were to make a false-flag attack against Dee? Mutually assured destruction doesn't work if you can't accurately attribute attacks. >This would create some gentle pressure to explicitly unify the two chains (by merging Dee and Dum at some compromise and doing away with Unified) I don't think a compromise would be reachable at that point - suppose one had a market cap of 1.2 billion, and the other had a market cap of 0.8 billion. How would the coins on the unified chain be distributed? You could give each chain an equal number of coins, but that's not fair to the people holding the more valuable coins. You could give each chain a number of coins proportional to the market cap, but that invites price manipulation. In any case, if you had a way of reaching compromise, why not use it instead of creating two chains? Overall, I think this proposal is a bad idea. >You seem to not be familiar with how multisig transactions on Bitcoin work - 99.9% of the time theyre hidden behind p2sh and there is no way to know what keys are involved. Equally, multisig is just one of many complex scripts possible. That doesn't end up mattering, though, as I understand his proposal. The unified client would just see that both validly spend an output with a scriptPubKey of OP_HASH160 0xabcdef... OP_EQUAL. On Wed, Dec 30, 2015 at 1:32 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > > On 30 December 2015 12:22:43 GMT-08:00, "Emin Gün Sirer" <el33th4x0r@gmail.com> wrote: >>On Wed, Dec 30, 2015 at 3:16 PM, Peter Todd <pete@petertodd.org> wrote: >> >>> Note how transaction malleability can quickly sabotage naive notions >>of >>> this idea. >>> >> >>Bitcoin-United relies on a notion of transaction equivalence that >>doesn't >>involve the transaction hash at all, so it should be immune to >>malleability >>issues and compatible with segwit. >> > >From the post, two transactions are equal if they "consume the same >>inputs >>and result in the same outputs, not counting the miner fee. Simple >>pay-to-pubkey-hash and pay-to-script-hash transactions are >>straightforward. >>Multikey transactions are evaluated for equivalency by their inputs and >>outputs, so it is allowable for a 2-out-of-3 payment to be signed by >>one >>set of two keys on Dum and another set of two keys on Dee, as long as >>the >>transaction consumes the same coins and produces the same outputs. Not >>that >>we'll ever encounter such a case, but making this point helps >>pedagogically >>with getting across the notion of transaction equivalence. What counts >>are >>the consumed inputs and the destination and amounts of the outputs." > > You seem to not be familiar with how multisig transactions on Bitcoin work - 99.9% of the time theyre hidden behind p2sh and there is no way to know what keys are involved. Equally, multisig is just one of many complex scripts possible. > > Look into what a segwit transaction hashes - that's a better notion of non-malleable transaction. But even then lots of transactions are malleable, and its easy to trigger those cases intentionally by third parties. > > Most likely any Bitcoin United scheme would quickly diverge and fail; much simpler and more predictable to achieve convincing consensus, e.g. via proof of stake voting, or Adam Bank's extension blocks suggestions. (or of course, not trying to force controversial forks in the first place) > > -----BEGIN PGP SIGNATURE----- > > iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJWhD9N > AAoJEMCF8hzn9Lncz4MH/0JPGVc2JLtD5q0I2w0vqmBqsoSzSueCtnKa2K1Ea10g > w9I4uhK7+cgfCLbofJznVHMChXu0uCxtWwqSj++uJx238TEupcu951gUhFfuPOeH > Egye8jmDkDFiB1P40kUSVk9N64Zt3kWLk4xSsfjawVHz/WWpM24Fn8k/bmI7JiLl > nmVwoBdRsTKffM/1dr8ix4U8YPSmJ7W+jAByNHUpSgc1R73YylqNT95pF8QD35df > dQwSK9DIc+2N4CKnp22xLvYeCivFjeS2Fm4kbcKQwMjcqlJ1mWghP/c8q/lzhaGN > Ac15/pgeHp8dPP8c81zkN9ps14rrnXoHnrzjiY+TwKY= > =FfK1 > -----END PGP SIGNATURE----- > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-12-30 23:13 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-12-30 20:08 [bitcoin-dev] How to preserve the value of coins after a fork Emin Gün Sirer 2015-12-30 20:16 ` Peter Todd 2015-12-30 20:22 ` Emin Gün Sirer 2015-12-30 20:32 ` Peter Todd 2015-12-30 23:13 ` Nick ODell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox