Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 60DFA93E for ; Thu, 26 Jan 2017 09:21:12 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4C212133 for ; Thu, 26 Jan 2017 09:21:07 +0000 (UTC) Received: from [10.7.56.158] (ip-123-255-103-183.wlan.cuhk.edu.hk [123.255.103.183]) by mx.zohomail.com with SMTPS id 1485422459040831.6625385854138; Thu, 26 Jan 2017 01:20:59 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Johnson Lau In-Reply-To: Date: Thu, 26 Jan 2017 17:20:54 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7AF0AA6D-C144-4D0C-B5FC-0BC2C79C0D26@xbt.hk> References: <93ac7433-470c-d59e-e085-29f0f1613676@mattcorallo.com> To: Chris Priest X-Mailer: Apple Mail (2.3259) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev Subject: Re: [bitcoin-dev] Anti-transaction replay in a hardfork X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 09:21:12 -0000 BIP50 was an accident, and my proposal is just for a planned hardfork. = You can=E2=80=99t anti-replay if you don=E2=80=99t even know a hardfork = might happen. And I think your hypothesis (replay reduces the incentive = of split) is not supported by the ETC/ETH split. Aside the philosophical argument, your proposal is not technically = feasible. In my understanding, you require the new chain to replay all = the txs in the old chain. But this is not possible because there could = be orphaning in the old chain, and different miners of the new chain may = see a different history of the old chain. Not to mention that mining is = a random process, and the hashing power is going up and down. Just by = chance, 10 blocks might be generated in the old chain while no block is = generated in the new chain. This is also unfair to the new chain miners, = as they may not satisfied with the fees paid while they are forced to = include those txs from the old chain (remember that people may just pay = the old chain miners out of band, and pay no fee in the transaction) I don=E2=80=99t think these technical issues are solvable when both = forks are decentralised mining. If time machines, for example, are not = technically feasible, there is not much point to talk about the benefits = of time machines. > On 26 Jan 2017, at 16:59, Chris Priest wrote: >=20 >> If there is a split, it becomes 2 incompatible ledgers. >=20 > Not necessarily. When the BIP50 hard fork happened, it didn't create > two incompatible ledgers. It *could* have, but it didn't. If every > single transaction mined during that time has been "double spent" on > the other chain, then it would have created a very bad situation. When > one side of the fork gets abandoned, actual users would have lost > money. Since only one person was able to perform this double spend, > only the miners and that one double spender lost money when the one > side was abandoned. If there had been a significant number of users > who had value only on the chain that was eventually abandoned, that > chain would have incentive to not be abandoned and that *would* have > resulted in a permanent incompatible split. It was essentially the > replay *effect* (not "attack") that allowed bitcoin to survive that > hard fork. BIP50 was written before the term "replay attack" or > "replay effect" has been coined, so it doesn't say much about how > transactions replayed... >=20 > On 1/25/17, Johnson Lau wrote: >> I don=E2=80=99t think this is how the blockchain consensus works. If = there is a >> split, it becomes 2 incompatible ledgers. Bitcoin is not a trademark, = and >> you don=E2=80=99t need a permission to hardfork it. And what you = suggest is also >> technically infeasible, as the miners on the new chain may not have a >> consensus only what=E2=80=99s happening in the old chain. >>=20 >>> On 26 Jan 2017, at 15:03, Chris Priest wrote: >>>=20 >>> I don't think the solution should be to "fix the replay attack", but >>> rather to "force the replay effect". The fact that transactions can = be >>> relayed should be seen as a good thing, and not something that = should >>> be fixed, or even called an "attack". >>>=20 >>> The solution should be to create a "bridge" that replays all >>> transactions from one network over to the other, and vice-versa. A >>> fork should be transparent to the end-user. Forcing the user to = choose >>> which network to use is bad, because 99% of people that use bitcoin >>> don't care about developer drama, and will only be confused by the >>> choice. When a user moves coins mined before the fork date, both >>> blockchains should record that transaction. Also a rule should be >>> introduced that prevents users "tainting" their prefork-mined coins >>> with coins mined after the fork. All pre-fork mined coins should >>> "belong" to the network with hashpower majority. No other networks >>> should be able to claim pre-forked coins as being part of their >>> issuance (and therefore part of market cap). Market cap may be >>> bullshit, but it is used a lot in the cryptosphere to compare coins = to >>> each other. >>>=20 >>> The advantage of pre-fork coins being recorded on both forks is that >>> if one fork goes extinct, no one loses any money. This setup >>> encourages the minority chain to die,and unity returned. If pre-fork >>> coins change hands on either fork (and not on the other), then = holders >>> have an incentive to not let their chain die, and the networks will = be >>> irreversibly split forever. The goal should be unity not permanent >>> division. >>>=20 >>> On 1/25/17, Matt Corallo via bitcoin-dev >>> wrote: >>>> "A. For users on both existing and new fork, anti-replay is an = option, >>>> not mandatory" >>>>=20 >>>> To maximize fork divergence, it might make sense to require this. = Any >>>> sensible proposal for a hard fork would include a change to the = sighash >>>> anyway, so might as well make it required, no? >>>>=20 >>>> Matt >>>>=20 >>>> On 01/24/17 14:33, Johnson Lau via bitcoin-dev wrote: >>>>> This is a pre-BIP. Just need some formatting to make it a formal = BIP >>>>>=20 >>>>> Motivation: >>>>>=20 >>>>> In general, hardforks are consensus rule changes that make = currently >>>>> invalid transactions / blocks valid. It requires a very high = degree of >>>>> consensus and all economic active users migrate to the new rules = at the >>>>> same time. If a significant amount of users refuse to follow, a >>>>> permanent ledger split may happen, as demonstrated by Ethereum = (=E2=80=9CDAO >>>>> hardfork"). In the design of DAO hardfork, a permanent split was = not >>>>> anticipated and no precaution has been taken to protect against >>>>> transaction replay attack, which led to significant financial loss = for >>>>> some users. >>>>>=20 >>>>> A replay attack is an attempt to replay a transaction of one = network on >>>>> another network. It is normally impossible, for example between = Bitcoin >>>>> and Litecoin, as different networks have completely different = ledgers. >>>>> The txid as SHA256 hash guarantees that replay across network is >>>>> impossible. In a blockchain split, however, since both forks share = the >>>>> same historical ledger, replay attack would be possible, unless = some >>>>> precautions are taken. >>>>>=20 >>>>> Unfortunately, fixing problems in bitcoin is like repairing a = flying >>>>> plane. Preventing replay attack is constrained by the requirement = of >>>>> backward compatibility. This proposal has the following = objectives: >>>>>=20 >>>>> A. For users on both existing and new fork, anti-replay is an = option, >>>>> not mandatory. >>>>>=20 >>>>> B. For transactions created before this proposal is made, they are = not >>>>> protected from anti-replay. The new fork has to accept these >>>>> transactions, as there is no guarantee that the existing fork = would >>>>> survive nor maintain any value. People made time-locked = transactions in >>>>> anticipation that they would be accepted later. In order to = maximise >>>>> the >>>>> value of such transactions, the only way is to make them accepted = by >>>>> any >>>>> potential hardforks. >>>>>=20 >>>>> C. It doesn=E2=80=99t require any consensus changes in the = existing network to >>>>> avoid unnecessary debate. >>>>>=20 >>>>> D. As a beneficial side effect, the O(n^2) signature checking bug = could >>>>> be fixed for non-segregated witness inputs, optionally. >>>>>=20 >>>>> Definitions: >>>>>=20 >>>>> =E2=80=9CNetwork characteristic byte=E2=80=9D is the most = significant byte of the >>>>> nVersion field of a transaction. It is interpreted as a bit = vector, and >>>>> denotes up to 8 networks sharing a common history. >>>>>=20 >>>>> =E2=80=9CMasked version=E2=80=9D is the transaction nVersion with = the network >>>>> characteristic byte masked. >>>>>=20 >>>>> =E2=80=9CExisting network=E2=80=9D is the Bitcoin network with = existing rules, before a >>>>> hardfork. =E2=80=9CNew network=E2=80=9D is the Bitcoin network = with hardfork rules. (In >>>>> the case of DAO hardfork, Ethereum Classic is the existing = network, and >>>>> the now called Ethereum is the new network) >>>>>=20 >>>>> =E2=80=9CExisting network characteristic bit=E2=80=9D is the = lowest bit of network >>>>> characteristic byte >>>>>=20 >>>>> =E2=80=9CNew network characteristic bit=E2=80=9D is the second = lowest bit of network >>>>> characteristic byte >>>>>=20 >>>>> Rules in new network: >>>>>=20 >>>>> 1. If the network characteristic byte is non-zero, and the new = network >>>>> characteristic bit is not set, this transaction is invalid in the = new >>>>> network. (softfork) >>>>>=20 >>>>> 2. If the network characteristic byte is zero, go to 4 >>>>>=20 >>>>> 3. If the network characteristic byte is non-zero, and the new = network >>>>> characteristic bit is set, go to 4, regardless of the status of = the >>>>> other bits. >>>>>=20 >>>>> 4. If the masked version is 2 or below, the new network must = verify the >>>>> transaction with the existing script rules. (no change) >>>>>=20 >>>>> 5. If the masked version is 3 or above, the new network must = verify the >>>>> signatures with a new SignatureHash algorithm (hardfork). Segwit = and >>>>> non-segwit txs will use the same algorithm. It is same as BIP143, >>>>> except >>>>> that 0x2000000 is added to the nHashType before the hash is = calculated. >>>>>=20 >>>>> Rules in the existing network: >>>>>=20 >>>>> 6. No consensus rule changes is made in the existing network. >>>>>=20 >>>>> 7. If the network characteristic byte is non-zero, and the = existing >>>>> network characteristic bit is not set, this transaction is not = relayed >>>>> nor mined by default (no change) >>>>>=20 >>>>> 8. If the network characteristic byte is zero, no change >>>>>=20 >>>>> 9. If the network characteristic byte is non-zero, and the = existing >>>>> network characteristic bit is set, the masked version is used to >>>>> determine whether a transaction should be mined or relayed (policy >>>>> change) >>>>>=20 >>>>> 10. Wallet may provide an option for setting the existing network >>>>> characteristic bit. >>>>>=20 >>>>>=20 >>>>> Rationales (by rule number): >>>>>=20 >>>>> 1. This makes sure transactions with only existing network >>>>> characteristic bit set is invalid in the new network (opt-in >>>>> anti-replay >>>>> for existing network transactions on the new network, objective A) >>>>>=20 >>>>> 2+4. This makes sure time-locked transactions made before this >>>>> proposals >>>>> are valid in the new network (objective B) >>>>>=20 >>>>> 2+5. This makes sure transactions made specifically for the new = network >>>>> are invalid in the existing network (anti-replay for new network >>>>> transactions on the old network); also fixing the O(n^2) bug >>>>> (objectives >>>>> A and D) >>>>>=20 >>>>> 3. This is to prepare for the next hardfork from the new network >>>>> (objective A) >>>>>=20 >>>>> 6, 7, 8. These minimise the change to the existing network = (objective >>>>> C) >>>>>=20 >>>>> 9, 10. These are not strictly needed until a hardfork is really >>>>> anticipated. Without a significant portion of the network and = miners >>>>> implement this policy, however, no one should create such = transactions. >>>>> (objective A) >>>>>=20 >>>>>=20 >>>>> Limitations: >>>>>=20 >>>>> * It is not possible to protect transactions made before the = proposal. >>>>> To avoid a replay of such transactions, users should first spend = at >>>>> least a relevant UTXO on the new network so the replay transaction >>>>> would >>>>> be invalidated. >>>>>=20 >>>>> * It is up to the designer of a hardfork to decide whether this >>>>> proposal >>>>> is respected. As the DAO hardfork has shown how harmful replay = attack >>>>> could be, all hardfork proposals (except trivial and totally >>>>> uncontroversial ones) should take this into account >>>>>=20 >>>>> * The size of network characteristic byte is limited to 8 bits. >>>>> However, >>>>> if we are sure that some of the networks are completely abandoned, = the >>>>> bits might be reused. >>>>>=20 >>>>>=20 >>>>> Reference implementation: >>>>>=20 >>>>> A demo is available in my forcenet2 >>>>> branch: >>>>> = https://github.com/jl2012/bitcoin/commit/7c2593946c4f3e210683110782d82f554= 73c682a >>>>> = https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/01347= 2.html >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> bitcoin-dev mailing list >>>>> bitcoin-dev@lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>>=20 >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>=20 >>=20 >>=20 >>=20