From: Kekcoin <kekcoin@protonmail•com>
To: Tao Effect <contact@taoeffect•com>
Cc: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>,
Anthony Towns <aj@erisian•com.au>
Subject: Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable
Date: Tue, 06 Jun 2017 20:46:23 -0400 [thread overview]
Message-ID: <5pQR2BlehmKHRoZspUwV_R7BiRyANGsyJF4SKer5QoMzZIuO7pQtYGXuxevt2tIwGTqHTxZIbgHEG10HrSl19_MURgOZxoGcuJiK30l1agc=@protonmail.com> (raw)
In-Reply-To: <530153E9-1F86-4B21-A43D-72325EF1F811@taoeffect.com>
[-- Attachment #1: Type: text/plain, Size: 3345 bytes --]
I was merely describing that the only failure mode of using "post-split coinbases from the legacy chain" as seedcoins for cointainting purposes would be a resolution of the coinsplit, thereby rendering the cointainting redundant, therefore this would be an entirely safe approach to cointainting, as the only way coins could become untainted (and therefore subject to the threat of replay attacks) would coincide with a disappearance of the situation that gave rise to such replay attacks in the first place. This should sufficiently answer your concerns regarding lack of replay protection in case of medium-to-long-term chainsplits in general. If you fail to grok, please read again until you don't.
Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------- Original Message --------
Subject: Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable
Local Time: June 7, 2017 3:38 AM
UTC Time: June 7, 2017 12:38 AM
From: contact@taoeffect•com
To: Kekcoin <kekcoin@protonmail•com>
Anthony Towns <aj@erisian•com.au>, bitcoin-dev@lists•linuxfoundation.org <bitcoin-dev@lists•linuxfoundation.org>
Please read my email more carefully; the replay threat would be moot because there would be no alternative chain to replay the TX on,
In order to *get to that point*, you need >51%.
Not only that, but, if you started out with <51%, then you need >>51% in order to *catch up* and replace the large number of blocks added to the legacy chain in the mean time.
So, since >51% is _required_ for BIP148 to succeed (and likely >>51%)... you might as well do as SegWit did originally, or lower the threshold to 80% or something (as BIP91 does).
Without replay protection at the outset, BIP148, as far as I can tell, isn't a threat to miners.
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
On Jun 6, 2017, at 5:29 PM, Kekcoin <kekcoin@protonmail•com> wrote:
Please read my email more carefully; the replay threat would be moot because there would be no alternative chain to replay the TX on, as the non-148 chain would have been reorganized into oblivion.
Sent with [ProtonMail](https://protonmail.com/) Secure Email.
-------- Original Message --------
Subject: Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable
Local Time: June 7, 2017 3:26 AM
UTC Time: June 7, 2017 12:26 AM
From: contact@taoeffect•com
To: Kekcoin <kekcoin@protonmail•com>
Anthony Towns <aj@erisian•com.au>, bitcoin-dev@lists•linuxfoundation.org <bitcoin-dev@lists•linuxfoundation.org>
I don't know what you mean by "render the replay threat moot."
If you don't have replay protection, replay is always a threat. A very serious one.
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
On Jun 6, 2017, at 5:19 PM, Kekcoin <kekcoin@protonmail•com> wrote:
Hmm, that's not the difference I was talking about. I was referring to the fact that using "post-chainsplit coinbases from the non-148 chain" to unilaterally (ie. can be done without action on the 148-chain) taint coins is more secure in extreme-adverserial cases such as secret-mining reorg attacks (as unfeasibly expensive they may be); the only large-scale (>100 block) reorganization the non-148 chain faces should be a resolution of the chainsplit and therefore render the replay threat moot.
[-- Attachment #2: Type: text/html, Size: 6851 bytes --]
next prev parent reply other threads:[~2017-06-07 0:46 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
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 [this message]
-- 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='5pQR2BlehmKHRoZspUwV_R7BiRyANGsyJF4SKer5QoMzZIuO7pQtYGXuxevt2tIwGTqHTxZIbgHEG10HrSl19_MURgOZxoGcuJiK30l1agc=@protonmail.com' \
--to=kekcoin@protonmail$(echo .)com \
--cc=aj@erisian$(echo .)com.au \
--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