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
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
|
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 C99D697
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 28 Oct 2015 02:08:55 +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 0B80D137
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 28 Oct 2015 02:08:55 +0000 (UTC)
Received: from [172.17.0.1] (gw.vpn.bluematt.me [162.243.132.6])
by mail.bluematt.me (Postfix) with ESMTPSA id 6213859694;
Wed, 28 Oct 2015 02:08:53 +0000 (UTC)
From: Matt Corallo <lf-lists@mattcorallo.com>
To: Ittay <ittay.eyal@cornell.edu>
References: <CAPkFh0viwmkUvjo4Qj50TNnkA5kG3z-3dLGExjkmDacE4E49Ow@mail.gmail.com>
<CABaSBaxWAsEG71FTy4SrVu94BXokeozmJ80tjsNU8ERpTfFaFA@mail.gmail.com>
<CABT1wW=xqShMGU0+eDiNyNkr-77fQ_HnyKL87C6iGL-xq8BYVw@mail.gmail.com>
<28CC699B-4DA8-4472-A795-9505418C688A@mattcorallo.com>
<CABT1wWm0QXjGAXgrBMT7w+25kcsEJnP8JZ5RSpuk3aefX45+wQ@mail.gmail.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <56302E34.7070906@mattcorallo.com>
Date: Wed, 28 Oct 2015 02:08:52 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CABT1wWm0QXjGAXgrBMT7w+25kcsEJnP8JZ5RSpuk3aefX45+wQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 28 Oct 2015 04:09:52 +0000
Cc: Ittay via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
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, 28 Oct 2015 02:08:56 -0000
Oops, just realized I never responded to this...
On 10/15/15 15:09, Ittay wrote:
> Thanks, Matt. Response inline.
>
> On Wed, Oct 14, 2015 at 2:57 PM, Matt Corallo <lf-lists@mattcorallo.com
> <mailto:lf-lists@mattcorallo.com>> wrote:
>
> 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 :(.
>
>
> If NG is to be used efficiently, microblocks are going to be very
> frequent, and so such forks should occur at almost every key-block
> publication. Short reorgs as you described are the norm. A user should
> wait before accepting a transaction to make sure there was no key-block
> she missed. The wait time is chosen according to the network propagation
> delay (+as much slack as the user feels necessary). This is similar to
> the situation in Bitcoin when you receive a block. To be confident that
> you have one confirmation you should wait for the propagation time of
> the network to make sure there is no branch you missed.
I think you're overstating how short the wait times can be. They need to
be much longer than the network propagation delay.
> As for the malicious case: the attacker has to win the key-block, have
> the to-be-inverted transaction in the previous epoch, and withhold his
> key-block for a while. That being said, indeed our fraud proof scheme
> doesn't catch such an event, as it is indistinguishable from benign
> behavior.
The attacker does not need to withold their keyblock at all. All the
attacker does is, for every transaction they ever send, after it is
included in a microblock, set their hashpower to start mining a keyblock
immediately prior to this microblock. When they find a keyblock, they
immediately announce it and start creating microblocks, the first of
which double-spends the previous transaction. If they dont win the key
block, oh well, their payment went through normally and they couldn't
double-spend.
In chatting with Glenn about this, we roughly agreed that the
confirmation time for microblocks possibly doesn't need to be a full
key-block, but it needs to be a reasonable period after which such an
attacker would lose more in fees than the value of their double-spend
(ie because the key-block afterwards gets 20% more in fees than the
key-block before hand). In any case, the game theory here starts to get
rather complicated and it doesn't make me want to suggest accepting
microblocks as confirmations is safe.
> 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).
>
>
> Agreed x3: This is a good point, it is correct, and the tweak is dangerous.
> Do you perceive this as a significant practical issue?
It is not a practical issue today because no one does it, but it is a
massive issue in that the splitting of pool rewards and transaction
selection is one of the few easy wins we have left in the fight against
mining centralization. Mining centralization today is absolutely awful,
and closing off our only big win would be tragic.
> On October 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>
> On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop <kanzure@gmail.com
> <mailto:kanzure@gmail.com>> wrote:
>
> On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto: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
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
|
