Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EEB29907 for ; Sat, 27 Jan 2018 08:45:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f176.google.com (mail-qt0-f176.google.com [209.85.216.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 70C1AE7 for ; Sat, 27 Jan 2018 08:45:12 +0000 (UTC) Received: by mail-qt0-f176.google.com with SMTP id g14so7084952qti.2 for ; Sat, 27 Jan 2018 00:45:12 -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=5PTBLzgLRd7xswiQ97gclEPTxJBfxW0eL3MAj9scpks=; b=JdSw3rUGU97wz+jUoB+ct+V4sNKUB5FNAp+RA7U+yXVaWCo6UzeS8Xgn5K4jSQ+9Cy b6tVh189ZHqn1x+LXoEn86Zn7mVvyOtSxEDfonhlWbD6cti6U5/BgMFcdLP6FuByoR6j kKxFPZ7Sq1pyQF3mj6P4PFGfqM0Eb7HsH6qPST65JfB1lRAzBqWmaiDp/6HPkpsJMdtn 9SaShWyRXAspyWM+BSnC/RMWVqImZzyQLgtjxC9WclPsGVyyN1dytHt9z0awklaekucZ v2k2xo/+x6RiSYMtiqJ27TRDg7NhWyqSDFa86eSF06uSj+hpb+Ct30wDlezzNKdfJ8PZ ZCBw== 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=5PTBLzgLRd7xswiQ97gclEPTxJBfxW0eL3MAj9scpks=; b=lbv22/wRhRT6C1QAhrlXUkVXpWv2sI94aVZ/SoyYeDzBC2m3BsCE0w4td0LiyQgzGn 6H0HbfadMuQJZOf44IbazHKMX1oXQAnDk+2sXWAjxVWstJoGZGURZzSEnTuk0BmdMJxh CbtCjwCLCI7dwekrpun1GhsPg7GMjjLGQaHpejTHQHuGPH/t5tjaKToasp5GX29gKi+a dDnfKMySadhBnU6b9nIA9I9/oqsCbIU8QkhTYnB/L8A2AXCmClmSiYO+7I7jPEKEnuQs cbczun2OjTmWSE7uMRUx1NADZwfHrIa8LiptQCkazYU3zTQNTg+xfYWQpAxPX9OBwpUp 9ENA== X-Gm-Message-State: AKwxytdkOqOvdMgpTHILyoXmPIRlq+pAJ8uCEyLtVMxtviXU7Umlx2Ri vgdrCTLqIf/yoGbpXdN/nOU9w6zGAFsO4dB80ZgYNg== X-Google-Smtp-Source: AH8x225v3/MDiQ3zkdahBMFF5wrwSBlEeb+Dbe1JE7Jrlzs0EMKOBz08EGVU/T/nzX+86nL81KsYWeqh3GglmR32b+s= X-Received: by 10.237.48.106 with SMTP id 97mr27836028qte.48.1517042711364; Sat, 27 Jan 2018 00:45:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.36.185 with HTTP; Sat, 27 Jan 2018 00:45:10 -0800 (PST) From: Nathan Parker Date: Sat, 27 Jan 2018 09:45:10 +0100 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="94eb2c0cabe8eb89de0563be07af" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 27 Jan 2018 18:54:04 +0000 Subject: [bitcoin-dev] Proposal: rewarding fees to next block miner 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: Sat, 27 Jan 2018 08:45:13 -0000 --94eb2c0cabe8eb89de0563be07af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Miners can fill their blocks with transactions paying very high fees at no cost because they get the fees back to themselves. They can do this for different purposes, like trying to increase the recommended fee. Here I propose a backwards-compatible solution to this problem. The solution would be to reward the fees of the current block to the miner of the next block (or X blocks after the current one). That way, if a miner floods its own block with very high fee transactions, those fees are no longer given back to itself, but to the miner of future blocks which could potentially be anyone. Flooding blocks with fake txs is now discouraged. However, filling blocks with real transactions paying real fees is still encouraged because you could be the one to mine the block that would claim this reward. The way to implement this in a backwards-compatible fashion would be to enforce miners to set an anyone-can-spend output in the coinbase transaction of the block (by adding this as a rule for verifying new blocks). The miner of 100 blocks after the current one can add a secondary transaction spending this block's anyone-can-spend coinbase transaction (due to the coinbase needing 100 blocks to mature) and thus claiming the funds. This way, the block reward of a block X is always transferred to the miner of block X+100. Implementing this would require a soft-fork. Since that secondary transaction needs no signature whatsoever, the overhead caused by that extra transaction is negligible. Possible Downside: When the fork is activated, the miners won=E2=80=99t get= any reward for mining blocks for a period of 100 blocks. They could choose to power off the mining equipment for maintenance or to save power over that period, so the hashrate could drop temporarily. However, if the hashrate drops too much, blocks would take much longer to mine, and miners wouldn=E2= =80=99t want that either since they want to go through those 100 reward-less blocks as soon as possible so they can start getting rewards from mining again. --94eb2c0cabe8eb89de0563be07af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Miners can fill their blocks with transactions paying very high fees at no=20 cost because they get the fees back to themselves. They can do this for=20 different purposes, like trying to increase the recommended fee. Here I propose a backwards-compatible solution to this problem.

The solution would be t= o reward the fees of the current block to the miner of the next block (or X blocks after the current one). T= hat way, if a miner floods its own block with very high fee transactions, those fees are no longer given back to itself, but to the miner of future blocks which could potentially be anyone. Flooding blocks with fake txs is now dis= couraged. However, filling blocks with real transactions paying real fees is still encouraged because you could be the one to mine the block that would claim = this reward.

The way to implement th= is in a backwards-compatible fashion would be to enforce miners to set an anyone-can-spend output in the coinbas= e transaction of the block (by adding this as a rule for verifying new blocks= ). The miner of 100 blocks after the current one can add a secondary transaction spending this block's anyone-can-spend coinbase transaction (due to the= coinbase needing 100 blocks to mature) and thus claiming the funds. This way, the bl= ock reward of a block X is always transferred to the miner of block X+100.

Implementing this would= require a soft-fork. Since that secondary transaction needs no signature whatsoever, the overhead caused by that extra transaction is negligible.

Possible Downside: When= the fork is activated, the miners won=E2=80=99t get any reward for mining blocks for a period of 100 blocks. They could choose to power of= f the mining equipment for maintenance or to save power over that period, so = the hashrate could drop temporarily. However, if the hashrate drops too much, b= locks would take much longer to mine, and miners wouldn=E2=80=99t want that either sinc= e they want to go through those 100 reward-less blocks as soon as possible so they can = start getting rewards from mining again.


--94eb2c0cabe8eb89de0563be07af--