From: Tao Effect <contact@taoeffect•com>
To: Luke Dashjr <luke@dashjr•org>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable
Date: Tue, 6 Jun 2017 16:19:39 -0700 [thread overview]
Message-ID: <3F598630-86AA-4ACC-AD71-BB594767276C@taoeffect.com> (raw)
In-Reply-To: <201706062308.12531.luke@dashjr.org>
[-- Attachment #1.1: Type: text/plain, Size: 3764 bytes --]
> Replay is a solved problem.
Point to this solved problem?
Your "solution" here is not a solution:
https://www.reddit.com/r/Bitcoin/comments/6f1urd/i_think_its_time_we_have_an_educated_discussion/diey21t/?context=3 <https://www.reddit.com/r/Bitcoin/comments/6f1urd/i_think_its_time_we_have_an_educated_discussion/diey21t/?context=3>
> 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.
Let's assume you invented a simple way to double-spend txns to self (which you haven't, fyi), then that is an issue in of itself as the point of bitcoin is to *prevent* double-spending to self.
There would need to be much more time for the community to discuss the implications of wallets have a "double-spend to self" button in them.
> 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.
Yes it does destroy same-chain fungibility, as discussed on twitter [1], you're making miner coins special on both chains.
> Lack of replay protection does not mean there is no coin.
It effectively does. If people want to proceed blindly, ignoring replay, they're welcome to read about the consequences [2].
[1] https://twitter.com/taoeffect/status/872226556571131905 <https://twitter.com/taoeffect/status/872226556571131905>
[2] http://gist.github.com/taoeffect/c910ebb16d9f6d248e9f1f3c6e10b1b8 <http://gist.github.com/taoeffect/c910ebb16d9f6d248e9f1f3c6e10b1b8>
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jun 6, 2017, at 4:08 PM, Luke Dashjr <luke@dashjr•org <mailto:luke@dashjr•org>> wrote:
>
> 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
[-- Attachment #1.2: Type: text/html, Size: 7723 bytes --]
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2017-06-06 23:19 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
2017-06-06 23:19 ` Tao Effect [this message]
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=3F598630-86AA-4ACC-AD71-BB594767276C@taoeffect.com \
--to=contact@taoeffect$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)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