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
|
Return-Path: <cory@atlastechnologiesinc.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 42D43E32
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 2 Feb 2016 01:40:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com
[209.85.220.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5A032159
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 2 Feb 2016 01:40:50 +0000 (UTC)
Received: by mail-qk0-f177.google.com with SMTP id o6so60014006qkc.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 01 Feb 2016 17:40:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=coryfields-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=iyPrToAYa5FjmgcrJqk/5lLGMFcfabBwgv4USdVgzDs=;
b=WbPZ65Sy8pTHSfJ9eANZlsTfk5Q7I+YVt1nvTAatowwn4mXykahoYi72YRjwSt49Tl
MSxPEsTybIctVqGTZP5O88si51FerA9OTEDOoPHHBkU3rskFAyh7E1F7FF/WLlsuKgZf
jZup9rwS7LrtvosWQr0Uqj0ctKAIbxRF9Bek2ihyVMGhw6MFfQY2xUcOfvvbp5LzluMk
PvYX727WWWPV/m64w2RqCNB2gB0lXgRIqdgReGQgiThk/8ZTtSUbShgpDyIF3dnBK6nY
HXN0SAI29egLfZxPIWeZ5EhsGds9kuuU67HmuorplyVfXEAijV12eK18BQiB2DcpIU26
basA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=iyPrToAYa5FjmgcrJqk/5lLGMFcfabBwgv4USdVgzDs=;
b=QGMUfJj3ap/pI8zCIGPtohbjhpbL7h3QYuUXfFAQAF5yx2tZOB28gCC4n6tNgwq2/A
BFQ9Ny8WAeK4/j7yVCQVVZSRHtyR3IQ8RXKnFaW5LSeIkOblDr2SZ6E748iCAYsjLxRL
tt5MppWnxTSXuXTuiDrwwBnq7Ce7Aeho7mxWOAru25Yg4Hu2RTqUMDuModjH8gyTmbhc
vNL4O3wIxJS4/UQA24rIf5a9LAmtCDTkDLQdI+R+VB9l8f9RTZPtEJzzemvg3LUg72TF
xHD3oDoHA1Lp/ud6Cyy1d5gWybbmuqNncbpp/9quOjWHxr95PrZ2uAU8KO5ioCmnrFHA
njfw==
X-Gm-Message-State: AG10YOR1sW4RkJBHAEjbM84nQhjjLDS3PXu6q/Q/is0y9HmDz1LMuboudh9zL7hv0NFPabIRfVv/WwY2b2/RiQ==
MIME-Version: 1.0
X-Received: by 10.55.42.227 with SMTP id q96mr32145231qkq.101.1454377249378;
Mon, 01 Feb 2016 17:40:49 -0800 (PST)
Received: by 10.55.48.197 with HTTP; Mon, 1 Feb 2016 17:40:49 -0800 (PST)
In-Reply-To: <201602012308.35215.luke@dashjr.org>
References: <201601301850.03469.luke@dashjr.org>
<201602011946.24405.luke@dashjr.org>
<CAApLimgF2D97rAL8A9G36ULBE5tqKoXHFawYi35a0JiuQRu4Zg@mail.gmail.com>
<201602012308.35215.luke@dashjr.org>
Date: Mon, 1 Feb 2016 20:40:49 -0500
Message-ID: <CAApLimiefAkDaDShfq4b6T-6heqYyB5dqZDh58+Stwf7VqDWkg@mail.gmail.com>
From: Cory Fields <lists@coryfields.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,RCVD_IN_DNSWL_LOW,URIBL_SBL 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: Tue, 02 Feb 2016 01:44:34 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] SegWit GBT updates
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: Tue, 02 Feb 2016 01:40:51 -0000
On Mon, Feb 1, 2016 at 6:08 PM, Luke Dashjr <luke@dashjr.org> wrote:
> On Monday, February 01, 2016 9:43:33 PM Cory Fields wrote:
>> On Mon, Feb 1, 2016 at 2:46 PM, Luke Dashjr <luke@dashjr.org> wrote:
>> > Allowing for simpler cases both encourages the lazy case, and enables
>> > pools to require miners use it. It also complicates the server-side
>> > implementation somewhat, and could in some cases make it more vulnerable
>> > to DoS attacks. Keep in mind that GBT is not merely a bitcoind protocol,
>> > but is used between pool<->miner as well... For now, it makes sense to
>> > leave
>> > "default_witness_commitment" as a bitcoind-specific extension to
>> > encourage adoption, but it seems better to leave it out of the standard
>> > protocol. Let me know if this makes sense or if I'm overlooking
>> > something.
>>
>> I think that's a bit of a loaded answer. What's to keep a pool from
>> building its own commitment and requiring miners to use that? I don't
>> see how providing the known-working commitment for the
>> passed-in-hashes allows the pool/miner to do anything they couldn't
>> already, with the exception of skipping some complexity. Please don't
>> confuse encouraging with enabling.
>
> Making it simpler to do a centralised implementation than a decentralised one,
> is both enabling and encouraging. GBT has always been designed to make it
> difficult to do in a centralised manner.
>
But your suggestion is "use libblkmaker" which will build the trees
for me. By that logic, isn't libblkmaker making a centralized
implementation easier? Shouldn't that usage be discouraged as well?
And along those lines, shouldn't the fact that it's used as a pool <->
miner protocol be discouraged rather than touted as a feature?
I don't wish to sound hostile, I'm just trying follow the logic. I
can't rationalize why GBT shouldn't expose the commitment that it
knows to be correct (when paired with the transactions it provides),
purely to make things difficult.
>> What's the DoS vector here?
>
> It's more work for the pool to provide it, similar to the "midstate" field was
> with getwork. Someone performing a DoS needs to do less work to force the pool
> to do complex calculations (unless the same transaction tree / commitment is
> used for all miners, which would be an unfortunate limitation).
It's being provided to them. And if they're using a modified set of
tx's, they'll need to re-calculate it in order to verify the result
anyway. I suspect I'm not understanding this argument.
>
>> >> The issue in particular here is that a non-trivial burden is thrust
>> >> upon mining software, increasing the odds of bugs in the process.
>> >
>> > It can always use libblkmaker to handle the "heavy lifting"... In any
>> > case, the calculation for the commitment isn't significantly more than
>> > what it must already do for the stripped merkle tree.
>>
>> Agreed. However for the sake of initial adoption, it's much easier to
>> have a known-correct value to use. Even if it's just for the sake of
>> checking against.
>
> Sure, I'm not suggesting we remove this from bitcoind (probably the only place
> that makes initial adoption easier).
>
How about exposing it as a feature/capability, then? That way pools
can expect it from bitcoind, but won't be required to expose it
downstream.
>> >> [4]:
>> >> https://github.com/theuni/ckpool/commit/7d84b1d76b39591cc1c1ef495ebec513
>> >> cb 19a08e
>> >
>> > I'm pretty sure this commit is actually /introducing/ a bug in working
>> > (albeit ugly) code. The height, while always positive, is serialised as
>> > a signed number, so 0x80 needs to be two bytes: 80 00.
>>
>> You're right, thanks. The current code breaks on heights of (for ex)
>> 16513. I'll fix up my changes to take the sign bit into account.
>
> I'm curious what bug it was fixing? Was it overwriting data beyond the number?
Using 16513 as an example:
serialized by bitcoind: 0x028140
serialized by ckpool: 0x03814000
ckpool works because blocks after 32768 end up looking the same, but
it will break again at 2113664.
>
> Luke
|
