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
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
|
Return-Path: <truthcoin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9F488B2B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 May 2017 14:22:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com
[209.85.218.54])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 15E82134
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 May 2017 14:22:46 +0000 (UTC)
Received: by mail-oi0-f54.google.com with SMTP id h4so203089954oib.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 May 2017 07:22:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=subject:to:references:cc:from:message-id:date:user-agent
:mime-version:in-reply-to:content-transfer-encoding;
bh=Pfw4IlOu+iAc2zYW5iMBtMHb/C4ZpYn+jIGUS/uEo8A=;
b=Y3L53FSFq0CZBh0FadnfTVrCBTjIq9hrnE37ThPy9hgcYQGOFJ2nU4ZvDq+yo5Z3gr
oOHvv5dAlYu600lkxwECja/ziswm4EOY2AYwsG/jh+HnYADMa8zZ1w2wzQobYN0gtJoY
76y1LYaAJUWwoYFGzIieejhWWGSLigsDb/wsyVpcV0YayPLAfaZRm9WEB1JdWaJsqEb5
t+Pf/cEfCst5K4xklAHh5rl8aWgTsjgD8pIMSRpRR7iVNJIg/v9T1mc9HDwhXXwyf2/i
JGJ6gVHbYzzpvip3gOnW/AASViXIwwneR4Oel8/beFk9DYZtlCoTKSWPSKhoSWsDNGJ3
Z1uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:cc:from:message-id:date
:user-agent:mime-version:in-reply-to:content-transfer-encoding;
bh=Pfw4IlOu+iAc2zYW5iMBtMHb/C4ZpYn+jIGUS/uEo8A=;
b=bvoFuOqKMM+Rd16OSFm0GWuiCmkzfI/Kt+5r/6sqaFrtJdG71c2lsSFrpPiH1UEeLD
128kixdKuet5CeXhRC+Dy5SsQ12hwXJbDX9acSqv2Z+4rULlfxR8Bo/4awLSavDil4gw
rm6pEr4U3J3hsAl+FSUWtNGHgfCGdhvUdO6uQNRYi8I+8bCidALCfKUs7h/lsphCRFo8
kf/rI/7xt4tZ9DzBlGoWR0cHCCOX1BwlIOS0glLsZ0/lTu78bcCGdqL1tYU15eHCuQXM
kCIhHMhcRTbdVOlaxVNbOg3OyVrzpSXU8e5noqW//fU79AH/qcMdMowvwFAP/H8WN02Z
j3lQ==
X-Gm-Message-State: AODbwcC5AvdAlZ7VWBHua2AGF1iqFsvV2tVpyIFtpgEu59J4Kec5TdLe
oI6drtxfo3baZXFV1/o=
X-Received: by 10.157.28.130 with SMTP id l2mr1729922ota.256.1495549364971;
Tue, 23 May 2017 07:22:44 -0700 (PDT)
Received: from [192.168.44.223] ([172.56.28.28])
by smtp.googlemail.com with ESMTPSA id
n187sm314937oia.33.2017.05.23.07.22.42
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 23 May 2017 07:22:44 -0700 (PDT)
To: Tier Nolan <tier.nolan@gmail.com>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
<dhstGQudLBiwjDlaRrmMfy-ixwvXcwMr1CzCkPKh285RLICGZixkbdwpTDc2Sgz8eYIqSem8lwxW6QeJCD7aFfwQjLDnZ2NmOw0Zzd-KgSs=@protonmail.com>
<CA+XQW1jZpJ9wnEg47fouyywL09=_vU8dMP3owkkuNqRvzTZUDg@mail.gmail.com>
<CAE-z3OUYuAXE2+h60A=r4UyGU4CSQuF98oFgHnD7iaj-=Z=yOw@mail.gmail.com>
<CA+XQW1hRhcxJBoOJ57YG0t5y5j1Qm3RO4wr2eXV5V-UzDaiPPw@mail.gmail.com>
<CAE-z3OVWXN58X-+nAFTm61G1=v_1xrniyrBy8x=VRG4N149aXQ@mail.gmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
Message-ID: <141a0cd1-9d4f-c137-a349-17248f9cafd4@gmail.com>
Date: Tue, 23 May 2017 10:22:43 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAE-z3OVWXN58X-+nAFTm61G1=v_1xrniyrBy8x=VRG4N149aXQ@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no 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>
Subject: Re: [bitcoin-dev] Drivechain -- Request for Discussion
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, 23 May 2017 14:22:46 -0000
On 5/23/2017 5:51 AM, Tier Nolan via bitcoin-dev wrote:
> On Mon, May 22, 2017 at 9:00 PM, Paul Sztorc <truthcoin@gmail.com
> <mailto:truthcoin@gmail.com>> wrote:
>
> I would replace "Bitcoins you manage to steal" with "Bitcoins you
> manage to double-spend". Then, it still seems the same to me.
>
>
> With double spending, you can only get ownership of coins that you owned
> at some point in the past. Coins that are owned by someone else from
> coinbase to their current owners cannot be stolen by a re-org (though
> they can be moved around).
I'm not sure it makes much of a difference. First of all, in point of
fact, the miners themselves own the coins from the coinbase. But more
importantly, even if miners did not explicitly own the coins, they might
profit by being bribed -- these bribes would come from people who did
own the coins.
The principle is that value "v' has been taken from A and given to B.
This is effectively coercive activity, and therefore itself has value
proportional to 'v'.
>
> With BMM, you can take the entire reserve. Creating a group of double
> spenders can help increase the reward.
>
>
>
> It may destroy great value if it shakes confidence in the sidechain
> infrastructure. Thus, the value of the stolen BTC may decrease, in
> addition to the lost future tx fee revenues of the attacked chain.
>
> http://www.truthcoin.info/blog/drivechain/#drivechains-security
> <http://www.truthcoin.info/blog/drivechain/#drivechains-security>
>
>
> That is a fair point. If sidechains are how Bitcoin is scaled, then
> shaking confidence in a side-chain would shake confidence in Bitcoin's
> future.
Yes. The more value _on_ the sidechain, the more abhorrent the malfeasance.
>
> I wasn't thinking of a direct miner 51% attack. It is enough to assume
> that a majority of the miners go with the highest bidder each time.
What do you think of my argument, that we already labor under such an
assumption? An attacker could pay fees today equal to greater than
sum(blockreward_(last N block)). According to you this would force a
reorg, even on mainchain (pre-sidechain) Bitcoin. Yet this has never
happened.
It seems that this argument fully reduces to the "what will happen when
the block subsidy falls to zero" question.
>
> If (average fees) * (timeout) is less than the total reserves, then it
> is worth it for a 3rd party to just bid for his theft fork. Miners
> don't have to be assumed to be coordinating, they just have to be
> assumed to take the highest bid.
>
> Again, I don't really think it is that different. One could
> interchange "recent txns" (those which could be double-spent within
> 2-3 weeks) with "sidechain deposit tnxs".
>
>
> It is not "recent txns", it is recent txns that you (or your group) have
> the key for. No coordination is required to steal the entire reserve
> from the sidechain.
See above (?) for why I still feel they are comparable, if not identical.
>
> Recent txns and money on the sidechain have the property that they are
> riskier than money deep on the main chain. This is the inherent point
> about sidechains, so maybe not that big a deal.
Yes. Sidechains have newer, more interesting features, and
simultaneously more risk.
>
> My concern is that you could have a situation where an attack is
> possible and only need to assume that the miners are indifferent.
Again, I think that we _already_ need to eliminate any assumption of
"charitable miners".
>
> If the first attacker who tries it fails (say after creating a fork that
> is 90% of the length required, so losing a lot of money), then it would
> discourage others. If he succeeds, then it weakens sidechains as a
> concept and that creates the incentive for miners to see that he fails.
>
> I wonder how the incentives work out. If a group had 25% of the money
> on the sidechain, they could try to outbid the attacker.
Yes, we may see interesting behavior where people buy up these
liabilities using the LN. In my original post, I mention that miners
themselves may purchase these liabilities (at competitive rates, even if
these arent the idealized 1:1). At this point, miners would be paying
themselves and there would be no agency problem.
>
> In fact, since the attacker, by definition, creates an illegal fork, the
> effect is that he reduces the block rate for the side chain (possibly to
> zero, if he wins every auction). This means that there are more
> transactions per block, if there is space, or more fees per transaction,
> if the blocks are full.
>
> In both cases, this pushes up the total fees per block, so he has to pay
> more per block, weakening his attack. This is similar to where
> transaction spam on Bitcoin is self-correcting by increasing the fees
> required to keep the spam going.
>
> Is there a description of the actual implementation you decided to go
> with, other than the code?
If you haven't seen http://www.truthcoin.info/blog/drivechain/ , that is
probably the most human-readable description.
Cheers,
Paul
|
