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 AC183FA1 for ; Sun, 28 Jan 2018 16:54:58 +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 CE2AF32F for ; Sun, 28 Jan 2018 16:54:57 +0000 (UTC) Received: by mail-wm0-f43.google.com with SMTP id g1so9777713wmg.2 for ; Sun, 28 Jan 2018 08:54:57 -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=US/kLuJ7FsfZuIJSLTM65omxE6KwUdaTrpPvGNd0Ag0=; b=By2zKIK8X9BTt4BZ7VZsuLPUdxjLJiGaOftEDi7hTnyxDh37ambzho8kIq0L4hos99 NPRqDEyeGddJKtZMOhCJJ0kqZ9cYZTJ30dernh8U1QcCUUxEScfVGS5t8VpLUIN6fqJ3 fAyUtpuzRw9R2mQOw7/GZozR5JPvchGWviP2ZhdzAskEucP5xyx8+xPwDV3VXqrHP9wE k+JdARqj14JF/h+VqtXZONzWD5inC77wvFtzaxGjspH8aBh57WwgBUuBu6yx7Z9xJ90u RppaZHH7E2rL4H4xb4qfbJ8ODTV4JuaNIy4JsQ9KHQr3P1NkSub5qEivYF9xfMFVma8Y y0jw== 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=US/kLuJ7FsfZuIJSLTM65omxE6KwUdaTrpPvGNd0Ag0=; b=uRdDQg/KYkFnDMyoXtpmRZcddEOXTMU3co4Ekrz7gAc3WBSxbn0TTTvhCKZC6G6rMt 71kOIlr2RgoYz5CnxjR4sOVZUkgd5lmHgU3Kx06JWbc86eF46b1pkNRyo8coxxtBD0M+ 7MchgaazuNeO0097yKoxq/H12HPms35dhCevsiEv2CarOBF0ksK2Q8H/WHUbDvIUt4tT 4OgYcfgqQpYqqiw36kwd03pmCNrVYpsyDZ5svx2OgECj/v3kNqAuAhjf+o0O1tRG/Ud4 rs7Tr0C3MdS/A0nCQqpJKk1ePxwZ3ueiIS7i+wnJ70V4Zbi3i4KnmirLZqH/9aDSXKRn GLCA== X-Gm-Message-State: AKwxyteuSH1kPuqFoC+qYWoXa1TtJrVbMa3Ep6QyHZd7jrosdVKG2UJk +CI5HJzR1otupLqMNmV9de3v0zDhwO7IF3p2344= X-Google-Smtp-Source: AH8x2242wwQoJcVynAPyQFRiLKMuhn7NIHPkKBncvgb9yQ+CtzIZ7jREONXW1pGRem9qpUASYKKOnQA+elTewZNZZEc= X-Received: by 10.28.54.157 with SMTP id y29mr17043908wmh.36.1517158496396; Sun, 28 Jan 2018 08:54:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.210.198 with HTTP; Sun, 28 Jan 2018 08:54:36 -0800 (PST) In-Reply-To: References: From: Lucas Clemente Vella Date: Sun, 28 Jan 2018 14:54:36 -0200 Message-ID: To: Nathan Parker , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="001a114364243eec330563d8fd94" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, 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 X-Mailman-Approved-At: Sun, 28 Jan 2018 17:01:08 +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: Sun, 28 Jan 2018 16:54:58 -0000 --001a114364243eec330563d8fd94 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 n= o > 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 mine= r > of the next block (or X blocks after the current one). That way, if a min= er > 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 coul= d > 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 clai= m > 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 secondar= y > 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 t= he > 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 g= et 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 bloc= ks > 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 > > --=20 Lucas Clemente Vella lvella@gmail.com --001a114364243eec330563d8fd94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If the miner wants to force fees up, why would he fill up = a block with placeholder high fee transactions, instead of simply cutting o= ff transactions paying less fee than he is willing to take? Is there any ev= idence 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.linu= xfoundation.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




--
Lucas Clemente Vella
lvella@gmail.com
--001a114364243eec330563d8fd94--