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
106
107
108
109
110
111
112
113
114
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5D3D69B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 14 Oct 2015 18:57:13 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9219490
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 14 Oct 2015 18:57:12 +0000 (UTC)
Received: from [IPv6:2607:fb90:211c:96f5:60f0:e645:d51e:beb7] (unknown
[172.56.31.102])
by mail.bluematt.me (Postfix) with ESMTPSA id A1B6859028;
Wed, 14 Oct 2015 18:57:10 +0000 (UTC)
In-Reply-To: <CABT1wW=xqShMGU0+eDiNyNkr-77fQ_HnyKL87C6iGL-xq8BYVw@mail.gmail.com>
References: <CAPkFh0viwmkUvjo4Qj50TNnkA5kG3z-3dLGExjkmDacE4E49Ow@mail.gmail.com>
<CABaSBaxWAsEG71FTy4SrVu94BXokeozmJ80tjsNU8ERpTfFaFA@mail.gmail.com>
<CABT1wW=xqShMGU0+eDiNyNkr-77fQ_HnyKL87C6iGL-xq8BYVw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----YMPFIUJBG0EG12QR5WNRD59SW98WRT"
Content-Transfer-Encoding: 8bit
From: Matt Corallo <lf-lists@mattcorallo.com>
Date: Wed, 14 Oct 2015 18:57:08 +0000
To: Ittay <ittay.eyal@cornell.edu>,
Ittay via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
Bryan Bishop <kanzure@gmail.com>
Message-ID: <28CC699B-4DA8-4472-A795-9505418C688A@mattcorallo.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
Ittay Eyal <ittay.eyal@cornell.edu>
Subject: Re: [bitcoin-dev] Bitcoin-NG whitepaper.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Wed, 14 Oct 2015 18:57:13 -0000
------YMPFIUJBG0EG12QR5WNRD59SW98WRT
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
charset=UTF-8
That conversation missed a second issue. Namely that there is no way to punish people if there is a double spend in a micro block that happens in key block which reorg'd away the first transaction. eg one miner mines a transaction in a micro block, another miner (either by not having seen the first yet, or being malicious - potentially the same miner) mines a key block which reorgs away the first micro block and then, in their first micro block, mines a double spend. This can happen at any time, so you end up having to fall back to regular full blocks for confirmation times :(.
Also, Greg Slepak brought up a good point on twitter at https://twitter.com/taoeffect/status/654358023138209792. Noting that this model means users could no longer pick transactions in a mining pool which was set up in such a way (it could be tweaked to do so with separate rewards and pubkeys, but now the user can commit fraud at a much lower cost - their own pool reward, not the block's total reward).
On October 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop <kanzure@gmail.com>
>wrote:
>
>> On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > while the whitepaper has all the nitty gritty details:
>> > http://arxiv.org/abs/1510.02037
>>
>> Taking reward compensation back by fraud proofs is not enough to fix
>> the problems associated with double spending (such as, everyone has
>to
>> wait for the "real" confirmations instead of the "possibly
>> double-spend" confirmations). Some of this was discussed in -wizards
>> recently:
>> http://gnusha.org/bitcoin-wizards/2015-09-19.log
>
>
>Fraud proof removes all the attacker's revenue. It's like the attacker
>sacrifices an entire block for double spending in the current system. I
>think Luke-Jr got it right at that discussion.
>
>Best,
>Ittay
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
------YMPFIUJBG0EG12QR5WNRD59SW98WRT
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: 8bit
<html><head></head><body>That conversation missed a second issue. Namely that there is no way to punish people if there is a double spend in a micro block that happens in key block which reorg'd away the first transaction. eg one miner mines a transaction in a micro block, another miner (either by not having seen the first yet, or being malicious - potentially the same miner) mines a key block which reorgs away the first micro block and then, in their first micro block, mines a double spend. This can happen at any time, so you end up having to fall back to regular full blocks for confirmation times :(.<br>
<br>
Also, Greg Slepak brought up a good point on twitter at <a href="https://twitter.com/taoeffect/status/654358023138209792">https://twitter.com/taoeffect/status/654358023138209792</a>. Noting that this model means users could no longer pick transactions in a mining pool which was set up in such a way (it could be tweaked to do so with separate rewards and pubkeys, but now the user can commit fraud at a much lower cost - their own pool reward, not the block's total reward).<br><br><div class="gmail_quote">On October 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr"><div class="gmail_extra"><br /><div class="gmail_quote">On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop <span dir="ltr"><<a href="mailto:kanzure@gmail.com" target="_blank">kanzure@gmail.com</a>></span> wrote:<br /><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer<br />
<<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br />
> while the whitepaper has all the nitty gritty details:<br />
> <a href="http://arxiv.org/abs/1510.02037" rel="noreferrer" target="_blank">http://arxiv.org/abs/1510.02037</a><br />
<br />
</span>Taking reward compensation back by fraud proofs is not enough to fix<br />
the problems associated with double spending (such as, everyone has to<br />
wait for the "real" confirmations instead of the "possibly<br />
double-spend" confirmations). Some of this was discussed in -wizards<br />
recently:<br />
<a href="http://gnusha.org/bitcoin-wizards/2015-09-19.log" rel="noreferrer" target="_blank">http://gnusha.org/bitcoin-wizards/2015-09-19.log</a></blockquote><div><br /></div><div>Fraud proof removes all the attacker's revenue. It's like the attacker sacrifices an entire block for double spending in the current system. I think Luke-Jr got it right at that discussion. </div><div><br /></div><div>Best, </div></div></div><div class="gmail_extra">Ittay </div><div class="gmail_extra"><br /></div></div>
<p style="margin-top: 2.5em; margin-bottom: 1em; border-bottom: 1px solid #000"></p><pre class="k9mail"><hr /><br />bitcoin-dev mailing list<br />bitcoin-dev@lists.linuxfoundation.org<br /><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br /></pre></blockquote></div></body></html>
------YMPFIUJBG0EG12QR5WNRD59SW98WRT--
|
