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.
next prev 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 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$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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