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 1486EF72 for ; Tue, 2 Feb 2016 02:31: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 65C9E181 for ; Tue, 2 Feb 2016 02:31:31 +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 A36D538A99F7; Tue, 2 Feb 2016 02:30:57 +0000 (UTC) X-Hashcash: 1:25:160202:lists@coryfields.com::YWSbUYZlQtzKNiDA:Oqzc X-Hashcash: 1:25:160202:bitcoin-dev@lists.linuxfoundation.org::LBY3qBcj/F1Qqkuz:dUI+p From: Luke Dashjr To: Cory Fields Date: Tue, 2 Feb 2016 02:30:55 +0000 User-Agent: KMail/1.13.7 (Linux/4.1.13-gentoo; KDE/4.14.8; x86_64; ; ) References: <201601301850.03469.luke@dashjr.org> <201602012308.35215.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: <201602020230.56760.luke@dashjr.org> X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,RCVD_IN_SBL, RP_MATCHES_RCVD,URIBL_SBL 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: Tue, 02 Feb 2016 02:31:32 -0000 On Tuesday, February 02, 2016 1:40:49 AM Cory Fields wrote: > On Mon, Feb 1, 2016 at 6:08 PM, Luke Dashjr wrote: > > On Monday, February 01, 2016 9:43:33 PM Cory Fields wrote: > >> On Mon, Feb 1, 2016 at 2:46 PM, Luke Dashjr 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? libblkmaker is miner-side; right now it implies the miner using the templates as-is (perhaps after verifying the transactions meet some criteria), but it is the miner who is making that decision, not the pool. > 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? ??? > >> 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 DoS is against the pool, not the miner. You'd attack by pretending to be 100000 new miners per second, and the pool then needs to calculate a witness commitment for each one. It's a lot cheaper to just serialise and send the transaction list. > >> >> 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. Implementation-specific things aren't standards. And besides, they really *shouldn't* expect it from bitcoind; it's simply a reasonable compromise to provide it encourage adoption of SegWit. Once SegWit is live, there is no more value to doing so. Luke