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 97A5486D for ; Wed, 6 Jun 2018 01:26:38 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f177.google.com (mail-qt0-f177.google.com [209.85.216.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 137FD2D5 for ; Wed, 6 Jun 2018 01:26:38 +0000 (UTC) Received: by mail-qt0-f177.google.com with SMTP id p23-v6so4724288qtn.6 for ; Tue, 05 Jun 2018 18:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=zgMxyO++qXBC3Hy+O5Qu2vW0hgiKk6YwnUXVizVTqRY=; b=WGXj2yMGN2QyzSoQ03VG24/0htORKx0c3eLpfkh/XDgG8KMohMQQT5jebaqfP4Mu4P +1gYioLhVRqqMybGrBcRrJ4PQnNPniezGfb6MFUiUrZbf0A4PR0O8V8a8r75TunjK8MN Ezsa76KLuJJQCLEYgeUg+omvU8r1vZ3HHdJMepZpCyLYkl5NrYcjF87JuNJv3QDPRCSV lY8bgrWTJHDz4FHHOnUn9fq7hM88jKg16N8xEcPJpzLRH2dFY0E5sWAkXgTv+EmOAqUC E9tAcrIWjLAjGxxB/0tzVWPgpsrN2Ez3TnUeC8TC7jnSml32XabP9ZB2AmpRvOe2wUik 3W1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=zgMxyO++qXBC3Hy+O5Qu2vW0hgiKk6YwnUXVizVTqRY=; b=EZzEB39A9bSTqNKX4VUT7ogZN3VrTudcR1AGMhl0cKm0qykOeNWKVD2wCkBkmD6G7v 8j4O+9hlRhc+9K1PQIhrE8/qEzY+sIwz81g75rAs7LVYjBN2A3YlDRxzOwCvqscsHUWP T4bjBYZJX1/6i9n6NUyI67R3hYKJIQTPuz1p6AgYWM2EDds0z9fQYaxIu5zvAGgWRLrt GK4Ci/HnnW8Wak6M8G88+sqK+A72u7cgG8WcPGKTxio4azmMpoALrgliI/UziAkMbEx7 wOXgssfxLIsrmqEiCDdjxdBBEeWeAfqbfNN/UscD6HftIX8zo/DgX5Sj77gOLjGPGFYO /bSA== X-Gm-Message-State: APt69E2FPldT3CgK6Rnw5jkVax4NbGXnWpGBL7fUzA9wi7iOpDR/puUk wICwdRrfw29SWSGI+eMsGSUACdAC X-Google-Smtp-Source: ADUXVKJk+kl+9TMwDKx45/QeCH2iWUeF5qZl7l3mW3HnBZE70/WinFr8vKVxBgWcHpBEbJZughHSxA== X-Received: by 2002:ac8:2ce3:: with SMTP id 32-v6mr956886qtx.236.1528248396884; Tue, 05 Jun 2018 18:26:36 -0700 (PDT) Received: from ?IPv6:2601:18d:8a01:1110:14e8:31fd:2dfc:6393? ([2601:18d:8a01:1110:14e8:31fd:2dfc:6393]) by smtp.gmail.com with ESMTPSA id b71-v6sm26220244qkj.89.2018.06.05.18.26.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jun 2018 18:26:36 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: <92215b88-75a4-6be7-dec6-89c567a74a9a@mattcorallo.com> From: Chris Pacia Message-ID: <039bd3d3-c71c-8d40-7456-bc78fc0c7123@gmail.com> Date: Tue, 5 Jun 2018 21:26:35 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <92215b88-75a4-6be7-dec6-89c567a74a9a@mattcorallo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] [BIP Proposal] BetterHash Mining Protocol Replacements X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 01:26:38 -0000 Really like that you're moving forward with this. A few months ago I was working on something similar as it seemed like nobody else was interested. In regards to the specific proposal, would it make sense to offer a tx subscription endpoint in addition to TRANSACTION_DATA_REQUEST? Such an endpoint could respond to the subscription with the current full list of transactions and then push the diff every time a new template is pushed. A client that wants to inspect and modify the transactions would use quite a bit less data than polling the request endpoint. On 06/05/2018 02:44 PM, Matt Corallo via bitcoin-dev wrote: > Been working on this one for a while, so its already been through a few > rounds of feeback (thanks to all those who already have provided feedback)! > > At a high level, this meets a few goals: > > 1) Replace getblocktemplate with something that is both more performant > (no JSON encoding, no full transactions sent over the wire to update a > job, hence we can keep the same CTransactionRef in Bitcoin Core making > lots of validation things way faster), more robust for consensus changes > (no need to add protocol changes to add commitments ala SegWit in the > future), and moves more block-switching logic inside of the work > provider (allowing Bitcoin Core to better optimize work switching as it > knows more than an outside pool server, specifically we can play more > games with how we do mempool eviction, empty block mining, and not > mining fresh transactions more easily by moving to a more "push" model > from the normal "pull" getblocktemplate implementation). > > 2) Replace Stratum with something more secure (sign messages when > applicable, without adding too much overhead to the pool), simpler to > implement (not JSON-wrapped-hex, no 32-byte-swapped-per-4-byte-byteorder > insanity), and better-defined (a clearly written spec, encompassing the > various things shoved backwards into stratum like suggested difficulty > in the password field and device identification by setting user to > "user.device") with VENDOR_MESSAGEs provided for extensibility instead > of conflicting specifications from various different vendors. > > 3) Provide the ability for a pool to accept work which the users of the > pool selected the transactions for, providing strong decentralization > pressure by removing the network-level centralization attacks pools can > do (or be compromised and used to perform) while still allowing them > full control of payout management and variance reduction. > > While (1) and (2) stand on their own, making it all one set of protocols > to provide (3) provides at least the opportunity for drastically better > decentralization in Bitcoin mining in the future. > > The latest version of the full BIP draft can be found at > https://github.com/TheBlueMatt/bips/blob/betterhash/bip-XXXX.mediawiki > and implementations of the work-generation part at > https://github.com/TheBlueMatt/bitcoin/commits/2018-02-miningserver and > pool/proxy parts at https://github.com/TheBlueMatt/mining-proxy (though > note that both implementations are currently on a slightly out-of-date > version of the protocol, I hope to get them brought up to date in the > coming day or two and make them much more full-featured. The whole stack > has managed to mine numerous testnet blocks on several different types > of hardware). > > Matt > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >