From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id AFADDE94 for ; Mon, 1 Feb 2016 19:46:32 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 250DF170 for ; Mon, 1 Feb 2016 19:46:32 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 431D738A916A; Mon, 1 Feb 2016 19:46:25 +0000 (UTC) X-Hashcash: 1:25:160201:lists@coryfields.com::l0r6iW4F6XSUUQTh:qVuB X-Hashcash: 1:25:160201:bitcoin-dev@lists.linuxfoundation.org::daFsmnh44NPxzKav:Q=Kc From: Luke Dashjr To: Cory Fields Date: Mon, 1 Feb 2016 19:46:23 +0000 User-Agent: KMail/1.13.7 (Linux/4.1.13-gentoo; KDE/4.14.8; x86_64; ; ) References: <201601301850.03469.luke@dashjr.org> In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201602011946.24405.luke@dashjr.org> X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,RCVD_IN_SBL, RP_MATCHES_RCVD 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 19:46:32 -0000 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. > 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. > 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. > [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. Luke