Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EBD67EC9 for ; Mon, 29 Jan 2018 01:44:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0182C108 for ; Mon, 29 Jan 2018 01:44:09 +0000 (UTC) Received: by mail-wm0-f43.google.com with SMTP id f71so11129853wmf.0 for ; Sun, 28 Jan 2018 17:44:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=iKuQEbRJh+Ali+7bCNjvJpCwQjit/K2p6ftgnxBWWJU=; b=SSce7MVE2KiXvDVvg6ifMemRto31p4SrS81ClUtOrodGzFuydL7tBZqSHkRCF8vriF ZQOcRNbqEPMNCv+0UyXbYgJrHlmC10F1qZGgzduzwNg86XTyaYFbvZDH3yr2F7GydBXg 1iaDZkaxR48rPV6mI9swKH2v58heInAum0/sAT3I1Z+VULYApnlRlD469PvHP/AacvX6 PJ7SNKhfI0rSVDPJw36zId6dyNaew+8sxtvPTRLaPL+Nlfw7CJMM8x0Q3AQlfIN0qX9l i1CKi36ixNpQQ59FnjyagobWU9R+icjsYOnxymjId1aluDynINHQ1G5vVxQ9FBnBSYPJ AF9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=iKuQEbRJh+Ali+7bCNjvJpCwQjit/K2p6ftgnxBWWJU=; b=YAJl2V6JrqlJ9OMJW2gKCofbLy+JTeN2eq6MP/M0IOeLyHih7IelN5OfukJfOYq5yC OSeDqo1qD9HUg6IMaDLnWyOnGlvVIkuVyzaFhdqn358R8pe7jpu5XjeyCT3t77yAROnd f90RUqkInuEXvBC5rMFhoXlgCgmqiXkiLlFa2uNxM+Afl/iteReAPnIplH353C0nv00Q xYx5qj1KK4EQ3/B++lrJ7GErXJQTxIugswrWhvhf+wcOzU2ghRpzMMX3DK/Ib9ASL0g1 J4GwGwP4SPLBPqgig3r29ofsXeUX42dgwOWmHb0KEMzYk6qUSeu2GAnOsD93ci7nKIba +BEA== X-Gm-Message-State: AKwxytfmbMrWV0ct6ZP2so9WJm+JA2EwYBgTaxz1d9pu6+SyJxwbusuq kaIQmB3SaMIA9F3cA8yt6AXohgtLYdy811G2LhI= X-Google-Smtp-Source: AH8x226DZWPeIWA+9G5QQ7lU/6O2RSmSsiBYomWud6cn0lDbxT9z3JeulOHh+7QabQe/+/CWXrB+OEwB9QFmYAW1noQ= X-Received: by 10.80.215.222 with SMTP id m30mr44686307edj.296.1517190248546; Sun, 28 Jan 2018 17:44:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.157.13 with HTTP; Sun, 28 Jan 2018 17:44:08 -0800 (PST) In-Reply-To: References: From: George Balch Date: Sun, 28 Jan 2018 17:44:08 -0800 Message-ID: To: Lucas Clemente Vella , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="94eb2c1aed76d246fc0563e06162" X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, FREEMAIL_REPLY, 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: Mon, 29 Jan 2018 02:17:46 +0000 Subject: Re: [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: Mon, 29 Jan 2018 01:44:11 -0000 --94eb2c1aed76d246fc0563e06162 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If miners leave transactions out of a block they do pay a cost by not being rewarded those fees. If they include their own spam transactions to get back the fee they gain nothing. Since blocks can have fees resulting in hundreds of thousands of dollars, it would seem unlikely that miners incur a huge cost for not including transactions. On Sun, Jan 28, 2018 at 8:54 AM, Lucas Clemente Vella via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > If the miner wants to force fees up, why would he fill up a block with > placeholder high fee transactions, instead of simply cutting off > transactions paying less fee than he is willing to take? Is there any > evidence someone is doing such a thing for whatever reason? > > 2018-01-27 6:45 GMT-02:00 Nathan Parker via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org>: > >> 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 f= or >> 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, i= f a >> miner floods its own block with very high fee transactions, those fees a= re >> 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 seconda= ry >> 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 t= o >> power off the mining equipment for maintenance or to save power over tha= t >> 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 blo= cks >> as soon as possible so they can start getting rewards from mining again. >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > > -- > Lucas Clemente Vella > lvella@gmail.com > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --94eb2c1aed76d246fc0563e06162 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If miners leave transactions out of a block they do pay a = cost by not being rewarded those fees.=C2=A0 If they include their own spam= transactions to get back the fee they gain nothing.=C2=A0 Since blocks can= have fees resulting in hundreds of thousands of dollars, it would seem unl= ikely that miners incur a huge cost for not including transactions.

On Sun, Jan 28,= 2018 at 8:54 AM, Lucas Clemente Vella via bitcoin-dev &l= t;bitcoin-dev@lists.linuxfoundation.org> wrote:
If the miner wants to force fees up, = why would he fill up a block with placeholder high fee transactions, instea= d of simply cutting off transactions paying less fee than he is willing to = take? Is there any evidence someone is doing such a thing for whatever reas= on?

2018= -01-27 6:45 GMT-02:00 Nathan Parker via bitcoin-dev <<= a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b= itcoin-dev@lists.linuxfoundation.org>:

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.



_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


<= br clear=3D"all">
--
Lucas Clemente Vella
lvella@gmail.com

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--94eb2c1aed76d246fc0563e06162--