public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tom Harding <tomh@thinlink.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Anti-transaction replay in a hardfork
Date: Thu, 26 Jan 2017 07:58:23 -0800	[thread overview]
Message-ID: <369b781f-065f-9a1d-a3d7-e98a6fe7f4f6@thinlink.com> (raw)
In-Reply-To: <7AF0AA6D-C144-4D0C-B5FC-0BC2C79C0D26@xbt.hk>

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.



  parent reply	other threads:[~2017-01-26 15:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-24 14:33 [bitcoin-dev] Anti-transaction replay in a hardfork Johnson Lau
2017-01-24 18:52 ` Tom Harding
2017-01-25  4:03   ` Johnson Lau
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 [this message]
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=369b781f-065f-9a1d-a3d7-e98a6fe7f4f6@thinlink.com \
    --to=tomh@thinlink.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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