94d9aed3be3de728d2f4dc9abc5e9dd11b5a70
1 Return-Path: <lf-lists@mattcorallo.com> 2 Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org 3 [172.17.192.35]) 4 by mail.linuxfoundation.org (Postfix) with ESMTPS id 754D1D2A 5 for <bitcoin-dev@lists.linuxfoundation.org>; 6 Wed, 6 Jun 2018 19:16:18 +0000 (UTC) 7 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 8 Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) 9 by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C4F6F5E2 10 for <bitcoin-dev@lists.linuxfoundation.org>; 11 Wed, 6 Jun 2018 19:16:17 +0000 (UTC) 12 Received: from [172.17.0.2] (gw.vpn.bluematt.me [144.217.106.88]) 13 by mail.bluematt.me (Postfix) with ESMTPSA id 44CF31A6EEB; 14 Wed, 6 Jun 2018 19:16:11 +0000 (UTC) 15 To: Chris Pacia <ctpacia@gmail.com>, 16 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> 17 References: <92215b88-75a4-6be7-dec6-89c567a74a9a@mattcorallo.com> 18 <039bd3d3-c71c-8d40-7456-bc78fc0c7123@gmail.com> 19 From: Matt Corallo <lf-lists@mattcorallo.com> 20 Message-ID: <6051657f-7cef-be18-06a5-0f5a7b073ef2@mattcorallo.com> 21 Date: Wed, 6 Jun 2018 15:16:09 -0400 22 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 23 Thunderbird/52.8.0 24 MIME-Version: 1.0 25 In-Reply-To: <039bd3d3-c71c-8d40-7456-bc78fc0c7123@gmail.com> 26 Content-Type: text/plain; charset=utf-8 27 Content-Language: en-US 28 Content-Transfer-Encoding: 7bit 29 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 30 version=3.3.1 31 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on 32 smtp1.linux-foundation.org 33 Subject: Re: [bitcoin-dev] [BIP Proposal] BetterHash Mining Protocol 34 Replacements 35 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org 36 X-Mailman-Version: 2.1.12 37 Precedence: list 38 List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> 39 List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 40 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> 41 List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> 42 List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> 43 List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> 44 List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 45 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> 46 X-List-Received-Date: Wed, 06 Jun 2018 19:16:18 -0000 47 48 Clients "inspecting and modifying the transactions" is explicitly *not* 49 supported. There should be more than enough features for clients to get 50 bitcoind to generate the exact block they want already available via 51 Bitcoin Core. The only reason transactions are exposed over the work 52 protocol at all, really, is so that clients can generate weak blocks to 53 be sent to the pool for efficient client -> pool block relay, not sure 54 that's worth bothering to add a whole new endpoint for, sounds 55 needlessly complicated (and the spec is already more than complicated 56 enough, sadly). 57 58 Matt 59 60 On 06/05/18 21:26, Chris Pacia via bitcoin-dev wrote: 61 > Really like that you're moving forward with this. A few months ago I was 62 > working on something similar as it seemed like nobody else was interested. 63 > 64 > In regards to the specific proposal, would it make sense to offer a tx 65 > subscription endpoint in addition to TRANSACTION_DATA_REQUEST? Such an 66 > endpoint could respond to the subscription with the current full list of 67 > transactions and then push the diff every time a new template is pushed. 68 > A client that wants to inspect and modify the transactions would use 69 > quite a bit less data than polling the request endpoint. 70 > 71 > 72 > On 06/05/2018 02:44 PM, Matt Corallo via bitcoin-dev wrote: 73 >> Been working on this one for a while, so its already been through a few 74 >> rounds of feeback (thanks to all those who already have provided 75 >> feedback)! 76 >> 77 >> At a high level, this meets a few goals: 78 >> 79 >> 1) Replace getblocktemplate with something that is both more performant 80 >> (no JSON encoding, no full transactions sent over the wire to update a 81 >> job, hence we can keep the same CTransactionRef in Bitcoin Core making 82 >> lots of validation things way faster), more robust for consensus changes 83 >> (no need to add protocol changes to add commitments ala SegWit in the 84 >> future), and moves more block-switching logic inside of the work 85 >> provider (allowing Bitcoin Core to better optimize work switching as it 86 >> knows more than an outside pool server, specifically we can play more 87 >> games with how we do mempool eviction, empty block mining, and not 88 >> mining fresh transactions more easily by moving to a more "push" model 89 >> from the normal "pull" getblocktemplate implementation). 90 >> 91 >> 2) Replace Stratum with something more secure (sign messages when 92 >> applicable, without adding too much overhead to the pool), simpler to 93 >> implement (not JSON-wrapped-hex, no 32-byte-swapped-per-4-byte-byteorder 94 >> insanity), and better-defined (a clearly written spec, encompassing the 95 >> various things shoved backwards into stratum like suggested difficulty 96 >> in the password field and device identification by setting user to 97 >> "user.device") with VENDOR_MESSAGEs provided for extensibility instead 98 >> of conflicting specifications from various different vendors. 99 >> 100 >> 3) Provide the ability for a pool to accept work which the users of the 101 >> pool selected the transactions for, providing strong decentralization 102 >> pressure by removing the network-level centralization attacks pools can 103 >> do (or be compromised and used to perform) while still allowing them 104 >> full control of payout management and variance reduction. 105 >> 106 >> While (1) and (2) stand on their own, making it all one set of protocols 107 >> to provide (3) provides at least the opportunity for drastically better 108 >> decentralization in Bitcoin mining in the future. 109 >> 110 >> The latest version of the full BIP draft can be found at 111 >> https://github.com/TheBlueMatt/bips/blob/betterhash/bip-XXXX.mediawiki 112 >> and implementations of the work-generation part at 113 >> https://github.com/TheBlueMatt/bitcoin/commits/2018-02-miningserver and 114 >> pool/proxy parts at https://github.com/TheBlueMatt/mining-proxy (though 115 >> note that both implementations are currently on a slightly out-of-date 116 >> version of the protocol, I hope to get them brought up to date in the 117 >> coming day or two and make them much more full-featured. The whole stack 118 >> has managed to mine numerous testnet blocks on several different types 119 >> of hardware). 120 >> 121 >> Matt 122 >> _______________________________________________ 123 >> bitcoin-dev mailing list 124 >> bitcoin-dev@lists.linuxfoundation.org 125 >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 126 >> 127 > 128 > _______________________________________________ 129 > bitcoin-dev mailing list 130 > bitcoin-dev@lists.linuxfoundation.org 131 > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 132