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

[Tom Harding via bitcoin-dev]

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
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Johnson Lau via bitcoin-dev]

> 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 force unmodified yet otherwise compatible systems to 
> change to support the new network at all. This is unlikely to be included in 
> new network designs.
> 
> I suggest that the opt-out bits proposal comes from a more realistic position 
> that would actually make sense for everyone.
> 

I think there are some misunderstanding. You’d better read my source code if my 
explanation is not clear.

From my understanding our proposals are the same, just with a bitwise not (~) 
before the network characteristic byte. So you set a bit to opt-out a network, 
while I set a bit to opt-in a network (and opt-out any other)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Matt Corallo via bitcoin-dev]

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 existing transaction signing software 
should be considered (but for hardware which cannot be upgraded easily we do 
need to consider it). Wallets which can upgrade should, as much as possible, 
upgrade to a new form to maximize chain divergence and are going to end up 
having to upgrade to know a new header format anyway, so am extra few lines of 
code to change a transaction version should be trivial.

On January 26, 2017 12:21:37 PM EST, Gavin Andresen  
wrote:
>On Wed, Jan 25, 2017 at 10:29 PM, Matt Corallo via bitcoin-dev <
>bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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?
>>
>
>Compatibility with existing transaction-signing software and hardware
>should be considered.
>
>I think any hard fork proposal should support a reasonable number of
>reasonable-size old-sighash transactions, to allow a smooth transaction
>of
>wallet software and hardware and to support anybody who might have a
>hardware wallet locked away in a safe deposit box for years.
>
>-- 
>--
>Gavin Andresen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Tom Harding via bitcoin-dev]

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 situation essentially defines the 
limited solution that is possible.  Upgraded software can create 
transactions guaranteed not to execute to one fork or the other, or that 
is not prevented from execution on either fork.  I see no downside to 
this, and the advantage is that markets can be much less chaotic.  In 
fact exchanges will be much better off if they require that post-fork 
trading, deposits and withdrawals are exclusively chain-specific, which 
will also result in well determined prices for the two currencies.


None of this precludes the possibility of further forks on either side, 
and the difficulty consideration alone suggests a likely counter-fork by 
(part of) the existing network.



On 1/26/2017 1:20 AM, Johnson Lau via bitcoin-dev wrote:

Not to mention that mining is a random process, and the hashing power is going 
up and down.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Edmund Edgar via bitcoin-dev]

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 with the general point you're making, but you *could*
anti-replay without knowing about the fork, at least from a few dozen
blocks into it. For example you could allow transactions to specify a
recent block hash (or some of the bytes thereof) and declare that they
want to be invalid if that block isn't in the parent chain.

This would potentially have benefits beyond economic hard-fork
situations: As a general principle, if the network that you're
transacting with doesn't look like the one you think you're
transacting with, you're going to have a bad day.

-- 
-- 
Edmund Edgar
Founder, Social Minds Inc (KK)
Twitter: @edmundedgar
Linked In: edmundedgar
Skype: edmundedgar
http://www.socialminds.jp

Reality Keys
@realitykeys
e...@realitykeys.com
https://www.realitykeys.com
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Chris Priest via bitcoin-dev]

> 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  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  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
>>  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 

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

[Chris Priest via bitcoin-dev]

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
 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 

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

[Johnson Lau via bitcoin-dev]

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  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  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  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
>>>  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, 

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

[Johnson Lau via bitcoin-dev]

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  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
>  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
>>> 

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

[Matt Corallo via bitcoin-dev]

"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 0x200 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)
> 
> 

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

[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 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 the money on 
> both forks, it is already a successful replay
> 
> Why would Alice be sitting on an old-style signed transaction with UTXO:s 
> none of which she controls (paying somebody else), with NO ability to 
> substitute the transaction for one where she DOES control an output, leaving 
> her unable to be the one spending the replay protecting child transaction? 

If Alice still has full control, she is already protected by my proposal, which 
does not require any protecting child transaction.

But in many cases she may not have full control. Make it clearer, consider 
that’s actually a 2-of-2 multisig of Alice and Bob, and the time locked tx is 
sending to Bob. If the time locked tx is unprotected in the first place, Bob 
will get all the money from both forks anyway, as there is no reason for him to 
renegotiate with Alice.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[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 himself again (with different tx format). But as Bob gets all
the money on both forks, it is already a successful replay


Why would Alice be sitting on an old-style signed transaction with UTXO:s
none of which she controls (paying somebody else), with NO ability to
substitute the transaction for one where she DOES control an output,
leaving her unable to be the one spending the replay protecting child
transaction?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[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 the money on both 
forks, it is already a successful replay


> On 25 Jan 2017, at 15:15, Natanael  wrote:
> 
> 
> 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 transaction can't be 
> replayed, because replaying it in the other network REQUIRES a child 
> transaction in the same block that is valid, a child transaction the is 
> unique to the network. By doing this policy change simultaneously in both 
> networks, old pre-signed transactions *can not be replayed by anybody but the 
> owner* of the coins (as he must spend them immediately in the child 
> transaction). 
> 
> It means that as soon as spent, the UTXO sets immediately and irrevocably 
> diverges across the two networks. Which is the entire point, isn't it? 

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[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 transaction can't be
replayed, because replaying it in the other network REQUIRES a child
transaction in the same block that is valid, a child transaction the is
unique to the network. By doing this policy change simultaneously in both
networks, old pre-signed transactions *can not be replayed by anybody but
the owner* of the coins (as he must spend them immediately in the child
transaction).

It means that as soon as spent, the UTXO sets immediately and irrevocably
diverges across the two networks. Which is the entire point, isn't it?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[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" 
>  >:
> 
> 
> 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.
> 
> This can be fixed. 
> 
> Make old-format transactions valid *only when paired with a fork-only 
> follow-up transaction* which is spending at least one (or all) of the outputs 
> of the old-format transaction. 
> 
> (Yes, I know this introduces new statefulness into the block validation 
> logic. Unfortunately it is necessary for maximal fork safety. It can be 
> disabled at a later time if ever deemed no longer necessary.)
> 
> Meanwhile, the old network SHOULD soft-fork in an identical rule with a 
> follow-up transaction format incompatible with the fork. 
> 
> This means that old transactions can not be replayed across forks/networks, 
> because they're not valid when stand-alone. It also means that all wallet 
> clients either needs to be updated OR paired with software that intercepts 
> generated transactions, and automatically generates the correct follow-up 
> transaction for it (old network only). 
> 
> The rules should be that old-format transactions can't reference new-format 
> transactions, even if only a softfork change differ between the formats. This 
> prevents an unnecessary amount of transactions pairs generated by old 
> wallets. Thus they can spend old outputs, but not spend new ones. 
> 
> 

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[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 an 
nVersion not used in the existing network. This itself is a hardfork and the 
existing network would never accept such txs.

This is to avoid requiring any consensus changes to the existing network, as 
there is no guarantee that such softfork would be accepted by the existing 
network. If the new network wants to protect their users, it’d be trivial for 
them to include a SignatureHash hardfork like this, along with other other 
hardfork changes. Further hardforks will only require changing the network 
characteristic bit, but not the SignatureHash.

If the hardfork designers don’t like the fix of BIP143, there are many other 
options. The simplest one would be a trivial change to Satoshi’s SignatureHash, 
such as adding an extra value at the end of the algorithm. I just don’t see any 
technical reasons not to fix the O(n^2) problem altogether, if it is trivial 
(but not that trivial if the hardfork is not based on segwit)


> On 25 Jan 2017, at 02:52, Tom Harding  wrote:
> 
> 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 supports 8 opt-out bits compatible with may earlier
> description:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-July/012917.html.
> 
> If the existing network really wants to play along, it should execute a
> soft fork as soon as possible to support its own hard-fork opt-out bit
> ("network characteristic bit").  It is totally inadequate for a new
> network to rely on non-standardness in the existing network to prevent
> replay there.  Instead, in the absence of a supported opt-out bit in the
> existing network, a responsible new network would allow something that
> is invalid in the existing network, for transactions where replay to the
> existing network is undesirable.
> 
> It is an overreach for your BIP to suggest specific changes to be
> included in the new network, such as the specific O(n^2) fix you
> suggest.  This is a matter for the new network itself.
> 
> 


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[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 supports 8 opt-out bits compatible with may earlier
description:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-July/012917.html.

If the existing network really wants to play along, it should execute a
soft fork as soon as possible to support its own hard-fork opt-out bit
("network characteristic bit").  It is totally inadequate for a new
network to rely on non-standardness in the existing network to prevent
replay there.  Instead, in the absence of a supported opt-out bit in the
existing network, a responsible new network would allow something that
is invalid in the existing network, for transactions where replay to the
existing network is undesirable.

It is an overreach for your BIP to suggest specific changes to be
included in the new network, such as the specific O(n^2) fix you
suggest.  This is a matter for the new network itself.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev