Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 95B90104C for ; Mon, 1 Feb 2016 18:41:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DC627137 for ; Mon, 1 Feb 2016 18:41:07 +0000 (UTC) Received: by mail-qg0-f41.google.com with SMTP id b35so125701373qge.0 for ; Mon, 01 Feb 2016 10:41:07 -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=eTAcgTWoYzwyaFE9qxld59DJuLgGectAXoWmQzqcefw=; b=eku6WunWos5Rj6z9drq3W9M7K0ptqCftv4j7B0rmlGD4VIuBUK8p4d2e0dG2ij/z8V tHBI4Pfn5iNr4eVmI7NLNZh02hk7zEL49wzJw5ioQaGEikY4SRRF9+z9ZoEG7AeAd0Jj WgVixMTk0n72D4VL6Q+EKK7DaG3mIjYX2bv00HDQ4NJwqtzRYQz4NkShBCnxXRUHvZCM /dWixo1ZgOhlvR+TNLoqL35/5ApYJ8bzOjHtAFTr8iw6I0HHHYCTBzgpWGOA5n3tZbgy VYEGWqVujS1L6yH6nCvOWXpGcwCnu/dMz7brK6MRZQRZm6tZm0y2xK0kmQ348yKvXSyu LWBg== 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=eTAcgTWoYzwyaFE9qxld59DJuLgGectAXoWmQzqcefw=; b=OoVHC+ZR/fsGiUEfLPdrfTTgkDNeuJ/Ku3yneKpojtQSzVoXyHnfwXvxc1XSQApaAz mi+YSzQWjGbw8FyKQE3pSIQgOr4sbWhvPb51CLdIniUd6A14mQXOTkCC+yOxGgR0DsQB o657FEOkpRIgQexNrntKE9BntK5lMEIbhdcdGk829jOZpTOfiaiMfljXJ6CCqV5gPa49 4ZEBc2HgRnlGW37hWG636eGcI4Iq+1XociR5hYQFMFSQ2EDCLNrg/BUzgK2hogfMURxr UY3eYkRSyms7mtIYfVzYrdQQ3VPRIZOj0VLwvM4b5uzKbXImD2Ro8oYof/Y5/yD7jcZR lXlw== X-Gm-Message-State: AG10YORk5TuV+gefyl51/7DcnBlzcM27igJBUC9NqiEwrv5sH6CkA+TfZgb6BRUNXe1cT8pxmrrcrYHxNI7/6A== MIME-Version: 1.0 X-Received: by 10.140.28.161 with SMTP id 30mr29677056qgz.36.1454352066995; Mon, 01 Feb 2016 10:41:06 -0800 (PST) Received: by 10.55.48.197 with HTTP; Mon, 1 Feb 2016 10:41:06 -0800 (PST) In-Reply-To: <201601301850.03469.luke@dashjr.org> References: <201601301850.03469.luke@dashjr.org> Date: Mon, 1 Feb 2016 13:41:06 -0500 Message-ID: From: Cory Fields To: Luke Dashjr Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW 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 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 18:41:08 -0000 Thanks for getting this started, Luke. 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. The issue in particular here is that a non-trivial burden is thrust upon mining software, increasing the odds of bugs in the process. 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]. Asking them to handle more serialization and calculation of complex structures needlessly increases the complexity for zero benefit in the case where the tx's are to be used as-is. I'll PR this change to the BIP, as I can't really come up with an argument against. At worst, it can simply be ignored. [0]: https://github.com/sipa/bitcoin/blob/segwit/src/rpcmining.cpp#L590 [1]: https://github.com/bitcoin/libblkmaker/commit/22f6e42844aa14ed0037ebf12a734f07e63533d7 [2]: https://github.com/bitcoin/libblkmaker/commit/15e2c35bf69c997488e37147cf062dfa925b4912 [3]: https://github.com/bitcoin/libblkmaker/commit/9a5799891e0f3590779b8e5a993a7b306088e2fa [4]: https://github.com/theuni/ckpool/commit/7d84b1d76b39591cc1c1ef495ebec513cb19a08e Regards, Cory On Sat, Jan 30, 2016 at 1:50 PM, Luke Dashjr via bitcoin-dev wrote: > I've completed an initial draft of a BIP for updating getblocktemplate for > segregated witness here: > https://github.com/luke-jr/bips/blob/segwit_gbt/bip-segwit-gbt.mediawiki > > Please review and comment (especially with regard to the changes in the > sigoplimits handling). > > (Note: libblkmaker's reference implementation is at this time incompatible > with the "last output" rule in this BIP.) > > Thanks, > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev