Re: [bitcoin-dev] Anti-transaction replay in a hardfork

Johnson, It's actually clear from your original post - you treat "all zeros" in a special way - as the equivalent of all ones. The semantics match the impression I got originally. Sorry we got sidetracked. ___ bitcoin-dev mailing list

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

> On 26 Jan 2017, at 03:32, Tom Harding wrote: > > On 1/24/2017 8:03 PM, Johnson Lau wrote: >> it seems they are not the same: yours is opt-out, while mine is opt-in. > > I missed this. So in fact you propose a self-defeating requirement on the > new network, which would

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

Excuse me, yes, for previously-signed transactions this is required. We might consider some limits on UTXO-chain-from-before-the-fork-length and likely something like move towards only allowing one transaction per block from the old mode over time. I highly disagree that compatibility with

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

Even more to the point, new post- fork coins are fork-specific. The longer both forks persist, the more transactions become unavoidably fork-specific through the mixing in of these coins. Any attempt to maximize replay will become less effective with time. The rationality of actors in this

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

On 26 January 2017 at 18:20, Johnson Lau via bitcoin-dev wrote: >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. I agree

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

> 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

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

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

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

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

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

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

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

"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

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

> On 25 Jan 2017, at 15:29, Natanael wrote: > > > Den 25 jan. 2017 08:22 skrev "Johnson Lau" >: > Assuming Alice is paying Bob with an old style time-locked tx. Under your > proposal, after the hardfork, Bob is still able to

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

Den 25 jan. 2017 08:22 skrev "Johnson Lau" : Assuming Alice is paying Bob with an old style time-locked tx. Under your proposal, after the hardfork, Bob is still able to confirm the time-locked tx on both networks. To fulfil your new rules he just needs to send the outputs to

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

Assuming Alice is paying Bob with an old style time-locked tx. Under your proposal, after the hardfork, Bob is still able to confirm the time-locked tx on both networks. To fulfil your new rules he just needs to send the outputs to himself again (with different tx format). But as Bob gets all

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

Den 25 jan. 2017 08:06 skrev "Johnson Lau" : What you describe is not a fix of replay attack. By confirming the same tx in both network, the tx has been already replayed. Their child txs do not matter. Read it again. The validation algorithm would be extended so that the

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

What you describe is not a fix of replay attack. By confirming the same tx in both network, the tx has been already replayed. Their child txs do not matter. > On 25 Jan 2017, at 09:22, Natanael wrote: > > > > Den 24 jan. 2017 15:33 skrev "Johnson Lau via bitcoin-dev" >

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

Yes, it’s similar. I’ll quote your design if/when I formalise my BIP. But it seems they are not the same: yours is opt-out, while mine is opt-in. However, my proposal in nowhere depends on standardness for the protection. It depends on the new network enforcing a new SignatureHash for txs with

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

On 1/24/2017 6:33 AM, Johnson Lau via bitcoin-dev wrote: > 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) Johnson, Your proposal