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
|
