Johnson Lau [ARCHIVE] on Nostr: đź“… Original date posted:2017-01-26 đź“ť Original message:BIP50 was an accident, and ...
đź“… Original date posted:2017-01-26
📝 Original message:BIP50 was an accident, and my proposal is just for a planned hardfork. You can’t anti-replay if you don’t 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’t 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 <cp368202 at ohiou.edu> wrote:
>
>> If there is a split, it becomes 2 incompatible ledgers.
>
> 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...
>
> On 1/25/17, Johnson Lau <jl2012 at xbt.hk> wrote:
>> I don’t 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’t 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’s happening in the old chain.
>>
>>> On 26 Jan 2017, at 15:03, Chris Priest <cp368202 at ohiou.edu> wrote:
>>>
>>> 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".
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> On 1/25/17, Matt Corallo via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>> "A. For users on both existing and new fork, anti-replay is an option,
>>>> not mandatory"
>>>>
>>>> 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?
>>>>
>>>> Matt
>>>>
>>>> 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
>>>>>
>>>>> Motivation:
>>>>>
>>>>> 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 (“DAO
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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:
>>>>>
>>>>> A. For users on both existing and new fork, anti-replay is an option,
>>>>> not mandatory.
>>>>>
>>>>> 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.
>>>>>
>>>>> C. It doesn’t require any consensus changes in the existing network to
>>>>> avoid unnecessary debate.
>>>>>
>>>>> D. As a beneficial side effect, the O(n^2) signature checking bug could
>>>>> be fixed for non-segregated witness inputs, optionally.
>>>>>
>>>>> Definitions:
>>>>>
>>>>> “Network characteristic byte” 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.
>>>>>
>>>>> “Masked version” is the transaction nVersion with the network
>>>>> characteristic byte masked.
>>>>>
>>>>> “Existing network” is the Bitcoin network with existing rules, before a
>>>>> hardfork. “New network” 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)
>>>>>
>>>>> “Existing network characteristic bit” is the lowest bit of network
>>>>> characteristic byte
>>>>>
>>>>> “New network characteristic bit” is the second lowest bit of network
>>>>> characteristic byte
>>>>>
>>>>> Rules in new network:
>>>>>
>>>>> 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)
>>>>>
>>>>> 2. If the network characteristic byte is zero, go to 4
>>>>>
>>>>> 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.
>>>>>
>>>>> 4. If the masked version is 2 or below, the new network must verify the
>>>>> transaction with the existing script rules. (no change)
>>>>>
>>>>> 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.
>>>>>
>>>>> Rules in the existing network:
>>>>>
>>>>> 6. No consensus rule changes is made in the existing network.
>>>>>
>>>>> 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)
>>>>>
>>>>> 8. If the network characteristic byte is zero, no change
>>>>>
>>>>> 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)
>>>>>
>>>>> 10. Wallet may provide an option for setting the existing network
>>>>> characteristic bit.
>>>>>
>>>>>
>>>>> Rationales (by rule number):
>>>>>
>>>>> 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)
>>>>>
>>>>> 2+4. This makes sure time-locked transactions made before this
>>>>> proposals
>>>>> are valid in the new network (objective B)
>>>>>
>>>>> 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)
>>>>>
>>>>> 3. This is to prepare for the next hardfork from the new network
>>>>> (objective A)
>>>>>
>>>>> 6, 7, 8. These minimise the change to the existing network (objective
>>>>> C)
>>>>>
>>>>> 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)
>>>>>
>>>>>
>>>>> Limitations:
>>>>>
>>>>> * 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.
>>>>>
>>>>> * 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
>>>>>
>>>>> * 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.
>>>>>
>>>>>
>>>>> Reference implementation:
>>>>>
>>>>> A demo is available in my forcenet2
>>>>> branch:
>>>>> https://github.com/jl2012/bitcoin/commit/7c2593946c4f3e210683110782d82f55473c682a
>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>
>>
>>
📝 Original message:BIP50 was an accident, and my proposal is just for a planned hardfork. You can’t anti-replay if you don’t 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’t 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 <cp368202 at ohiou.edu> wrote:
>
>> If there is a split, it becomes 2 incompatible ledgers.
>
> 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...
>
> On 1/25/17, Johnson Lau <jl2012 at xbt.hk> wrote:
>> I don’t 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’t 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’s happening in the old chain.
>>
>>> On 26 Jan 2017, at 15:03, Chris Priest <cp368202 at ohiou.edu> wrote:
>>>
>>> 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".
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> On 1/25/17, Matt Corallo via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>> "A. For users on both existing and new fork, anti-replay is an option,
>>>> not mandatory"
>>>>
>>>> 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?
>>>>
>>>> Matt
>>>>
>>>> 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
>>>>>
>>>>> Motivation:
>>>>>
>>>>> 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 (“DAO
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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:
>>>>>
>>>>> A. For users on both existing and new fork, anti-replay is an option,
>>>>> not mandatory.
>>>>>
>>>>> 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.
>>>>>
>>>>> C. It doesn’t require any consensus changes in the existing network to
>>>>> avoid unnecessary debate.
>>>>>
>>>>> D. As a beneficial side effect, the O(n^2) signature checking bug could
>>>>> be fixed for non-segregated witness inputs, optionally.
>>>>>
>>>>> Definitions:
>>>>>
>>>>> “Network characteristic byte” 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.
>>>>>
>>>>> “Masked version” is the transaction nVersion with the network
>>>>> characteristic byte masked.
>>>>>
>>>>> “Existing network” is the Bitcoin network with existing rules, before a
>>>>> hardfork. “New network” 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)
>>>>>
>>>>> “Existing network characteristic bit” is the lowest bit of network
>>>>> characteristic byte
>>>>>
>>>>> “New network characteristic bit” is the second lowest bit of network
>>>>> characteristic byte
>>>>>
>>>>> Rules in new network:
>>>>>
>>>>> 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)
>>>>>
>>>>> 2. If the network characteristic byte is zero, go to 4
>>>>>
>>>>> 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.
>>>>>
>>>>> 4. If the masked version is 2 or below, the new network must verify the
>>>>> transaction with the existing script rules. (no change)
>>>>>
>>>>> 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.
>>>>>
>>>>> Rules in the existing network:
>>>>>
>>>>> 6. No consensus rule changes is made in the existing network.
>>>>>
>>>>> 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)
>>>>>
>>>>> 8. If the network characteristic byte is zero, no change
>>>>>
>>>>> 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)
>>>>>
>>>>> 10. Wallet may provide an option for setting the existing network
>>>>> characteristic bit.
>>>>>
>>>>>
>>>>> Rationales (by rule number):
>>>>>
>>>>> 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)
>>>>>
>>>>> 2+4. This makes sure time-locked transactions made before this
>>>>> proposals
>>>>> are valid in the new network (objective B)
>>>>>
>>>>> 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)
>>>>>
>>>>> 3. This is to prepare for the next hardfork from the new network
>>>>> (objective A)
>>>>>
>>>>> 6, 7, 8. These minimise the change to the existing network (objective
>>>>> C)
>>>>>
>>>>> 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)
>>>>>
>>>>>
>>>>> Limitations:
>>>>>
>>>>> * 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.
>>>>>
>>>>> * 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
>>>>>
>>>>> * 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.
>>>>>
>>>>>
>>>>> Reference implementation:
>>>>>
>>>>> A demo is available in my forcenet2
>>>>> branch:
>>>>> https://github.com/jl2012/bitcoin/commit/7c2593946c4f3e210683110782d82f55473c682a
>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>
>>
>>