summaryrefslogtreecommitdiff
path: root/12/697f246765759bb8b7e6f100fb6d1feeef51fd
blob: 9d4cd2f38edcdd8fd5c5dd1bc3fc2d17183f5cab (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5E2CE955
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  6 Jun 2017 23:09:30 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 01FAA15F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  6 Jun 2017 23:09:29 +0000 (UTC)
Received: from ishibashi.localnet (unknown
	[IPv6:2001:470:5:265:a45d:823b:2d27:961c])
	(Authenticated sender: luke-jr)
	by zinan.dashjr.org (Postfix) with ESMTPSA id B4B2338A0087;
	Tue,  6 Jun 2017 23:08:13 +0000 (UTC)
X-Hashcash: 1:25:170606:bitcoin-dev@lists.linuxfoundation.org::dGTl7Yf7jrP2pNkc:eaXvL
X-Hashcash: 1:25:170606:contact@taoeffect.com::aHqO+JJSiMM8k0cW:cEKC7
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org, Tao Effect <contact@taoeffect.com>
Date: Tue, 6 Jun 2017 23:08:11 +0000
User-Agent: KMail/1.13.7 (Linux/4.9.16-gentoo; KDE/4.14.29; x86_64; ; )
References: <31833011-7179-49D1-A07E-8FD9556C4534@taoeffect.com>
In-Reply-To: <31833011-7179-49D1-A07E-8FD9556C4534@taoeffect.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201706062308.12531.luke@dashjr.org>
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jun 2017 23:09:30 -0000

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