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 6444E955 for ; Tue, 24 Jan 2017 18:58:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f178.google.com (mail-qt0-f178.google.com [209.85.216.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D75A6127 for ; Tue, 24 Jan 2017 18:58:20 +0000 (UTC) Received: by mail-qt0-f178.google.com with SMTP id v23so198997496qtb.0 for ; Tue, 24 Jan 2017 10:58:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=AIuxluI/EMpD6dqbSlwxb9zYc7MX23uqPO30uFthcWE=; b=LCj8yrjdqalzsOmSEUoJTYY3g4G/gPkqkZcctXws7tAp0c+xa/66WwWKXZuL4kSsgP RQd+7lLQyuf4qOguqpqaPILf3pU7aE4UriTjyAtK2lQx6oWKoH1qlf69ru2E1y4ShRtI cvRV/46U/0Kbe3A7Z1+IxhAAS2FxigQDgGB7Pl8m5jPW8i7Tjs61SZtDKezBQJuMe3d/ gEdKDrEkYDLBBzhA026VGDIzkAq7hbZ9se3XYevKkdmRkzB/f+TyNz9g8Q2vS+x/k8Vm tTMkCpNm/WSMgNbCKmX2fCvXkWfa3Bm6gFXFHGVgtoJOqHTyRWPH+GUoVVA5qQRiMS7P 8qMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=AIuxluI/EMpD6dqbSlwxb9zYc7MX23uqPO30uFthcWE=; b=JwnhSF+JYOxYLBlM2JVQac2sFebnPAQXLJvGdYAnXGRHd5cF2ttoLkElGMeNyVlKRw 3BdJ0gRlH8wxOQeJ2jgAuQ2CKvlLI0ZntkdqmzqZaow91ZFCoKH5ioFv/3cKvrAQqbWm f8hlMDvLVjJzY54ceRpAFGUSyaoh944U/+alMIlAO0VFxdtnl6v5yC1K3o5tMA96i+Jg CFh1GwGXY4ZEDzjgdDhmEcgM/kqURCyEqbke6wTZg/PL9W9W+uLyMqXb3TxFSANbz1lD YpiSeg4vFohBOILPyoeHOHzWZHJQORIZifoVqoYhjjEdRKIY3FnuCH9JKGRV0HKMKHdL hFZA== X-Gm-Message-State: AIkVDXIc5IC94jUruElwBkaga9XHkOsy2aSmE6KKHGQe1WkxBNYukpu/vuiJjKzTXOZSoFF1KagEHEfe0mSGsg== X-Received: by 10.55.4.138 with SMTP id 132mr30716927qke.190.1485284299883; Tue, 24 Jan 2017 10:58:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.50 with HTTP; Tue, 24 Jan 2017 10:57:59 -0800 (PST) From: "Rune K. Svendsen" Date: Tue, 24 Jan 2017 19:57:59 +0100 Message-ID: To: Bitcoin Content-Type: multipart/alternative; boundary=001a114c8cda15ce9d0546dbb30e X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM 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: Tue, 24 Jan 2017 20:06:41 +0000 Subject: [bitcoin-dev] Separating mining from tx verification by enabling paying to valid POW header 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: Tue, 24 Jan 2017 18:58:21 -0000 --001a114c8cda15ce9d0546dbb30e Content-Type: text/plain; charset=UTF-8 As mining works now, miners have to verify all Bitcoin transactions in the blocks they mine, because they would otherwise risk producing an invalid block. This is problematic because many miners are Chinese, and thus have poor Internet connectivity, so it would be preferable to separate the task of creating valid proof-of-work from the task of collecting valid transactions. This could be made possible by adding an opcode that checks whether the top-most stack item is a valid block header, we could call it OP_VALID_HEADER(VERIFY), thus allowing miners to be paid for a valid block header through a regular Bitcoin transaction, rather than through the coinbase transaction only. This allows a different group to simply act as collectors of transactions, and create OP_VALID_HEADER-transactions that pay to block headers with a merkle root that includes all the highest-fee transactions. So, these collectors would accumulate as many connections as possible within the Bitcoin P2P network, and collect all the highest fee transactions they can find. Then construct a block which includes all these transactions, and a coinbase tx that pays the block reward plus fees to the collector. With this block the collector would then create a Bitcoin transaction, with a OP_VALID_HEADER-output that can be redeemed by supplying the block header in the script but with a modified nonce/timestamp such that the proof-of-work+timestamp is valid. Miners would then only have to look for these Bitcoin transactions from the collectors, and mine on whichever header pays them the most, without having to care about whether the block in question includes invalid transactions, because the miner is paid for just a valid proof-of-work hash. When the miner finds a solution, it publishes the transaction, the collector see this transaction, gets it valid header, and publishes the block. A side bonus of this is that botnet miners can now participate on basically equal footing with traditional miners: they just listen to the P2P network for the transaction from the collector who pays them the most, which will include as many transactions as possible to earn the most in fees, thus verifying transactions without having to do the work. /Rune --001a114c8cda15ce9d0546dbb30e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As mining works now, miners have to verify all Bitcoin tra= nsactions in the blocks they mine, because they would otherwise risk produc= ing an invalid block. This is problematic because many miners are Chinese, = and thus have poor Internet connectivity, so it would be preferable to sepa= rate the task of creating valid proof-of-work from the task of collecting v= alid transactions.=C2=A0

This could be made possible by = adding an opcode that checks whether the top-most stack item is a valid blo= ck header, we could call it OP_VALID_HEADER(VERIFY), thus allowing miners t= o be paid for a valid block header through a regular Bitcoin transaction, r= ather than through the coinbase transaction only. This allows a different g= roup to simply act as collectors of transactions, and create OP_VALID_HEADE= R-transactions that pay to block headers with a merkle root that includes a= ll the highest-fee transactions.

So, these collect= ors would accumulate as many connections as possible within the Bitcoin P2P= network, and collect all the highest fee transactions they can find. Then = construct a block which includes all these transactions, and a coinbase tx = that pays the block reward plus fees=C2=A0to the collector.=C2=A0

With this block the collector would then create a Bitcoin t= ransaction, with a OP_VALID_HEADER-output that can be redeemed by supplying= the block header in the script but with a modified nonce/timestamp such th= at the proof-of-work+timestamp is valid. Miners would then only have to loo= k for these Bitcoin transactions from the collectors, and mine on whichever= header pays them the most, without having to care about whether the block = in question includes invalid transactions, because the miner is paid for ju= st a valid proof-of-work hash. When the miner finds a solution, it publishe= s the transaction, the collector see this transaction, gets it valid header= , and publishes the block.

A side bonus of this is= that botnet miners can now participate on basically equal footing with tra= ditional miners: they just listen to the P2P network for the transaction fr= om the collector who pays them the most, which will include as many transac= tions as possible to earn the most in fees, thus verifying transactions wit= hout having to do the work.




=C2=A0 =C2=A0 =C2=A0 /Rune
--001a114c8cda15ce9d0546dbb30e--