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
|
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 17C30C4C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Feb 2016 21:43:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com
[209.85.192.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5051B13C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Feb 2016 21:43:34 +0000 (UTC)
Received: by mail-qg0-f47.google.com with SMTP id e32so132224548qgf.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 01 Feb 2016 13:43:34 -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=Q+U9n8e4AByL/onhZmRyb/LvvXzR2AWnCvGDRiANBVQ=;
b=AVwhuMuSAL1kdyWhPlAuwSp/F0KhKFOQE5FFgEi4mh4OFoePCKdvL1f9uDp/zxbskX
BrUM+jvrujISKeL2s6I2yueq3VDP2n+cEqMPWHG3P+NZToWxViN17mjXGZHpZ5+ZXrVY
PF4aRX/feCXw8VXzxo5Z7mQm1H94M+scivXS20KC1y0HWC3bHQnVxZsHRquF+l30q75j
XbRfoe7NsxddQENDaQdkFLANllppGNgwE4/0mSELd3J1BnAPWZxViuNQBpshEL/HYih5
NQWTDlEwLl4wopph0eEJL3dn3cM8IWGGl/yue0jeavD2ZjJgS1NXI883PDVwlhO+kex9
ZK/A==
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=Q+U9n8e4AByL/onhZmRyb/LvvXzR2AWnCvGDRiANBVQ=;
b=BomAdCWiKj5CZyP+/oZPcSWZ+IOPea7lUaGYrKz1u+YJVTuSTMpmXuAuu6A37omox2
FiFz5UC1qlfahKPo7zAZAuVLQe9o38fP0Jbf1eMUgfWsafX+QtC4rqzAGHXlnfw5odVh
hItWz0mMPOY52KRQb1WjY+3tRuQjf622Y/yPyMhZlDfpD+uofHmndOosxvUsbDNxiYOy
UK04DpHaXg0xpzENE+Or7e46ezL/hyC6xn4ke3u4393lRiZ3GxwxX5NyZAavUz8OgmMK
6SB0fdkcONlIWkr5frhZajAvMzt8h2QJVJwIBs9LPFCpPZpz4S33iwx1bwRlgrrN+lEp
erXg==
X-Gm-Message-State: AG10YORkgkE3i3MVOCr3VO3zd36k7klQtFUy69G/E0i/DYA8JdtiAq/2ML1mQQ3riJ+vMGN34AYpkbJxAF1riw==
MIME-Version: 1.0
X-Received: by 10.140.250.213 with SMTP id v204mr7161243qhc.9.1454363013427;
Mon, 01 Feb 2016 13:43:33 -0800 (PST)
Received: by 10.55.48.197 with HTTP; Mon, 1 Feb 2016 13:43:33 -0800 (PST)
In-Reply-To: <201602011946.24405.luke@dashjr.org>
References: <201601301850.03469.luke@dashjr.org>
<CAApLimg+65PTn+=V_Es029j-Z-GJRCeMvO0aGdMrgTYFzJStvA@mail.gmail.com>
<201602011946.24405.luke@dashjr.org>
Date: Mon, 1 Feb 2016 16:43:33 -0500
Message-ID: <CAApLimgF2D97rAL8A9G36ULBE5tqKoXHFawYi35a0JiuQRu4Zg@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: Mon, 01 Feb 2016 21:57:09 +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: Mon, 01 Feb 2016 21:43:35 -0000
On Mon, Feb 1, 2016 at 2:46 PM, Luke Dashjr <luke@dashjr.org> wrote:
> On Monday, February 01, 2016 6:41:06 PM Cory Fields wrote:
>> Noticeably absent here is the "default_witness_commitment" key, as
>> added by the current reference implementation[0].
>>
>> I assume (please correct me if I'm wrong) that this has been omitted
>> for the sake of having clients create the commitment themselves as
>> opposed to having it provided to them.
>>
>> I don't think that the two approaches (providing the default
>> commitment for the complete tx set as well as the ability to create it
>> from chosen transactions) are at odds with each-other, rather it
>> merely allows for a simpler approach for those who are taking tx's
>> as-is from bitcoind. It's obviously important for the clients to be
>> able to chose tx's and create commitments as they desire, but it's
>> equally important to allow for simpler use-cases.
>
> 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.
What's the DoS vector here?
>> 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.
>
>> I'd like to point out that this is not a theoretical argument. I've
>> already fixed a handful of bugs relating to serialization or
>> commitment creation in the mining/pool software that I've worked on
>> for segwit [1][2][3][4].
>
> That's not really fair IMO. I wrote the libblkmaker branch prior to even
> reading the SegWit BIPs or code, and without a way to test it. It's only to be
> expected there are bugs that get fixed in first-try testing.
I didn't mean this as an insult/attack, quite the opposite actually.
Thanks for doing the integration :)
I was merely pointing out how easy it is to introduce subtle bugs here.
>
>> [4]:
>> https://github.com/theuni/ckpool/commit/7d84b1d76b39591cc1c1ef495ebec513cb
>> 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.
Heh, that only reinforces my point above about introducing bugs :p
>
> Luke
|
