From: Luke Dashjr <luke@dashjr•org>
To: bitcoin-dev@lists•linuxfoundation.org,
Tao Effect <contact@taoeffect•com>
Subject: Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable
Date: Tue, 6 Jun 2017 23:08:11 +0000 [thread overview]
Message-ID: <201706062308.12531.luke@dashjr.org> (raw)
In-Reply-To: <31833011-7179-49D1-A07E-8FD9556C4534@taoeffect.com>
On Tuesday 06 June 2017 10:39:28 PM Tao Effect via bitcoin-dev wrote:
> I believe the severity of replay attacks is going unvoiced and is not
> understood within the bitcoin community because of their lack of
> experience with them.
Replay is a solved problem. It can be improved on and made simpler, but at
this point, replay only occurs when the sender is either negligent or
intending it.
> Both of the coin-splitting techniques given so far by the proponents BIP148
> are also untenable:
>
> - Double-spending to self with nLockTime txns is insanely complicated,
> risky, not guaranteed to work, extremely time consuming, and would likely
> result in a massive increase in backlogged transactions and increased
> fees.
This is nothing but unfounded FUD. It is very simple to implement and
guaranteed to work eventually. It may be time consuming, but that is the only
truth here. The only risk is that of a long reorg, the same as double spend
attacks.
> - Mixing with 148 coinbase txns destroys fungibility.
What kind of "fungibility" does this FUD claim it destroys? Destroying cross-
chain fungibility is the very *intent* of replay protection. And it does not
destroy same-chain fungibility any more than any other miner spending.
> Without a coin, there is no real threat from BIP148.
Lack of replay protection does not mean there is no coin. Replay protection is
equally a concern for the main (BIP148) chain and any legacy chains malicious
miners might choose to split off. And none of this changes the fact that such
miners will be unable to sell their legacycoins at Bitcoin market prices,
because whether other transactions are replayed or not, *their* coins won't be
valid on the main chain.
Luke
next prev parent reply other threads:[~2017-06-06 23:09 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-06 22:39 Tao Effect
2017-06-06 23:02 ` Gregory Maxwell
2017-06-06 23:12 ` Tao Effect
2017-06-07 13:25 ` Nick Johnson
2017-06-07 16:27 ` Tao Effect
2017-06-07 17:35 ` Nick Johnson
2017-06-08 5:44 ` Conner Fromknecht
2017-06-08 6:38 ` Nick Johnson
2017-06-06 23:08 ` Luke Dashjr [this message]
2017-06-06 23:19 ` Tao Effect
2017-06-06 23:20 ` Anthony Towns
2017-06-06 23:27 ` Tao Effect
2017-06-06 23:31 ` Tao Effect
2017-06-06 23:59 ` Kekcoin
2017-06-07 0:04 ` Tao Effect
2017-06-07 0:19 ` Kekcoin
2017-06-07 0:26 ` Tao Effect
2017-06-07 0:29 ` Kekcoin
2017-06-07 0:38 ` Tao Effect
2017-06-07 0:46 ` Kekcoin
-- strict thread matches above, loose matches on Subject: below --
2017-06-06 20:43 Tao Effect
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=201706062308.12531.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=contact@taoeffect$(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