public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Johnson Lau <jl2012@xbt•hk>
To: Tom Harding <tomh@thinlink•com>,
	bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Anti-transaction replay in a hardfork
Date: Wed, 25 Jan 2017 12:03:40 +0800	[thread overview]
Message-ID: <3F2FDFFC-A73B-4C0F-A7B2-8449332BE70E@xbt.hk> (raw)
In-Reply-To: <efad941b-ce3e-1c98-ca5b-51da66badc6c@thinlink.com>

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 <tomh@thinlink•com> 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.
> 
> 




  reply	other threads:[~2017-01-25  4:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-24 14:33 Johnson Lau
2017-01-24 18:52 ` Tom Harding
2017-01-25  4:03   ` Johnson Lau [this message]
2017-01-25 19:32     ` Tom Harding
2017-01-27 20:47       ` Johnson Lau
2017-01-27 22:11         ` Tom Harding
2017-01-25  1:22 ` Natanael
2017-01-25  7:05   ` Johnson Lau
2017-01-25  7:15     ` Natanael
2017-01-25  7:21       ` Johnson Lau
2017-01-25  7:29         ` Natanael
2017-01-25  7:42           ` Johnson Lau
2017-01-26  3:29 ` Matt Corallo
2017-01-26  7:03   ` Chris Priest
2017-01-26  7:14     ` Johnson Lau
2017-01-26  8:59       ` Chris Priest
2017-01-26  9:20         ` Johnson Lau
2017-01-26 10:55           ` Edmund Edgar
2017-01-26 15:58           ` Tom Harding
2017-01-26 17:21   ` Gavin Andresen
2017-01-26 17:41     ` Matt Corallo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F2FDFFC-A73B-4C0F-A7B2-8449332BE70E@xbt.hk \
    --to=jl2012@xbt$(echo .)hk \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=tomh@thinlink$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox