summaryrefslogtreecommitdiff
path: root/d4/b5c886856d4508517d1e38f9b43a600207fa0c
blob: 630c3c02ce5eeca32d42172891b2de154559ecf7 (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
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
Return-Path: <tomz@freedommail.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 41701A8C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 24 Sep 2016 09:37:58 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mx-out02.mykolab.com (mx.kolabnow.com [95.128.36.1])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E582C1BE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 24 Sep 2016 09:37:56 +0000 (UTC)
X-Virus-Scanned: amavisd-new at kolabnow.com
X-Spam-Score: -2.9
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
Received: from mx04.mykolab.com (mx04.mykolab.com [10.20.7.102])
	by mx-out02.mykolab.com (Postfix) with ESMTPS id ADFFA636C8;
	Sat, 24 Sep 2016 11:37:53 +0200 (CEST)
From: Tom <tomz@freedommail.ch>
To: Luke Dashjr <luke@dashjr.org>
Date: Sat, 24 Sep 2016 11:37:52 +0200
Message-ID: <4508352.RUQdqZv42T@kiwi>
In-Reply-To: <201609232234.43689.luke@dashjr.org>
References: <201609230957.03138.luke@dashjr.org> <2403444.9CSRyRIcH2@garp>
	<201609232234.43689.luke@dashjr.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 24 Sep 2016 13:44:16 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT
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: Sat, 24 Sep 2016 09:37:58 -0000

Thank you Luke, this makes it clearer.

It doesn't change that this scenario is an attack that doesn't give the 
attacker any benefit and the attacked doesn't loose anything either (as 
Dave pointed out).

This is a completely academical problem that assumes so many stupid 
mistakes from software and from people that its very unlikely. On top of 
that it assumes a rather lengthy 51% attack in concert with this already 
extremely unlikely usecase.

In the scenario you assume stupid people and then you solve it by requiring 
the victim to suddenly be super smart and use a solution specifically 
designed for this super unlikely usecase that probably will never actually 
happen...

I don't buy it.

On Friday, 23 September 2016 22:34:41 CEST Luke Dashjr wrote:
> Joe sends Alice 5 BTC (UTXO 0).
> Fred sends Alice 4 BTC (UTXO 1).
> Alice sends Bob 4 BTC using UTXO 1 (creating UTXO 2).
> Fred double-spends UTXO 1 with UTXO 1-B. This invalidates Alice's
> transfer to Bob.
> Alice has UTXO 0 which she can send to Bob (UTXO 3), but if she does so,
> it is possible that UTXO 0 could be mined, and then both UTXO 2 and UTXO
> 3 which would result in her giving Bob a total of 8 BTC rather than
> merely 4 BTC. Even if Alice waits until Fred's UTXO 1-B confirms 10
> blocks deep, it is not impossible for a reorganization to reverse those
> 10 blocks and confirm UTXO 1 again.
> Using OP_CHECKBLOCKATHEIGHT, however, Alice can create UTXO 3 such that
> it is valid only in the blockchain where Fred's UTXO 1-B has confirmed.
> This way, if that block is reorganized out, UTXO 3 is invalid, and
> either Bob receives only the original UTXO 2, or Alice can create a UTXO
> 3-B which is valid in the reorganized blockchain if it again confirms
> the UTXO 1-B double-spend.
> 
> Luke
> 
> On Friday, September 23, 2016 2:37:39 PM Tom via bitcoin-dev wrote:
> > On Friday 23 Sep 2016 09:57:01 Luke Dashjr via bitcoin-dev wrote:
> > > This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the
> > > Bitcoin
> > > scripting system to address reissuing bitcoin transactions when the
> > > coins they spend have been conflicted/double-spent.
> > > 
> > > https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki
> > 
> > Can you walk us through a real live usecase which this solves?  I read
> > it and I think I understand it, but I can't see the attack every
> > giving the attacker any benefit (or the attacked losing anything).
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev