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

2017-01-24 Thread Johnson Lau via bitcoin-dev
> 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

2017-01-24 Thread Natanael via bitcoin-dev
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

2017-01-24 Thread Johnson Lau via bitcoin-dev
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

2017-01-24 Thread Natanael via bitcoin-dev
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

2017-01-24 Thread Johnson Lau via bitcoin-dev
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

2017-01-24 Thread Johnson Lau via bitcoin-dev
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

[bitcoin-dev] Separating mining from tx verification by enabling paying to valid POW header

2017-01-24 Thread Rune K. Svendsen via bitcoin-dev
As mining works now, miners have to verify all Bitcoin transactions in the blocks they mine, because they would otherwise risk producing an invalid block. This is problematic because many miners are Chinese, and thus have poor Internet connectivity, so it would be preferable to separate the task

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

2017-01-24 Thread Tom Harding via bitcoin-dev
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