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 97573F8A for ; Mon, 29 Jan 2018 00:46:52 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f50.google.com (mail-pg0-f50.google.com [74.125.83.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 130A5108 for ; Mon, 29 Jan 2018 00:46:52 +0000 (UTC) Received: by mail-pg0-f50.google.com with SMTP id r19so3124397pgn.1 for ; Sun, 28 Jan 2018 16:46:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=2BaMecMLHwH59nYBu8zMxZoNDIxmf26mDZ3FhoMqN/Y=; b=RxjNxA+SaAref6dlXpgIXuE2Ry/d0U8xAb8je2N1cG7sdwwGsn6S7achpMq5SjbOWP VJpEWFsNsNHD9ndEi4GzKj8DuxBJIkITCXHGOC4BkGj5dD09sxs/Yv8UDuifgo0nsaLn F7IG2MhHXv25Ou2/x6Sk74WnW+ii05+LhKGTNIVAS6S7im5qlO1R+vWtbRFt5cCfr7g0 PY58LdQzoKNHvt6sbf5Tv9BeGUb3zoUwBYNQ00vnjP642l8Ig+K90o9qCCYgqZkLFaah aLbqE/zYBpUtK5xAKGK2EycKymRoCCOBAIst4sNtFeXfiKD8eUQHmCCC55ysL9TUy6GM 01VQ== 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; bh=2BaMecMLHwH59nYBu8zMxZoNDIxmf26mDZ3FhoMqN/Y=; b=fMNE9lBnTcD3CwH+0dP74FCKTsWT65rkgeiBbgl44DcCGVgf12kygEmtjgdUJAGHdH p48PpM9XGv4LCC1PnOecrYHE21ESqa55wp6+41cluC9fFZnvx/i2Czrt50xu95Ude0h2 Y2ZFcPnnz1jBogjfkUlKV9nKZRDos/NpJl5znNpiYa/sY96hzP8QdgIGIypta80knnjK LYjGCPtLaEgVOjVH3qIBSZLq/7ru+Ck5OscATE1pXv+3j+ggHTnzj5lG0nl3UvnsEYGt t4Dtix9cn3e4PwnTPD5coaNVTds9r/q76dVVaKH/RIjGw6WgPpkzoWFhj5i78nKIezcq NQXQ== X-Gm-Message-State: AKwxytdWnStCpK3EERl8sieokYai517f4hCHx4pEnkweWgIT8ijrT9j3 7aIqBMIxDW2+fchQq1JPzqJYpiE5 X-Google-Smtp-Source: AH8x227Aw2mUWm/Ozo6RvLM924D9dcW97cWPwUW8sK5tEHbJQ5oJgLBvlCJwZl+2PB1nQ4bD6xR/+w== X-Received: by 10.101.75.193 with SMTP id p1mr3491599pgr.63.1517186811517; Sun, 28 Jan 2018 16:46:51 -0800 (PST) Received: from ?IPv6:2601:600:a080:16bb:f947:5006:f7cc:113e? ([2601:600:a080:16bb:f947:5006:f7cc:113e]) by smtp.gmail.com with ESMTPSA id b68sm24820827pfg.159.2018.01.28.16.46.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Jan 2018 16:46:50 -0800 (PST) To: Lucas Clemente Vella , Bitcoin Protocol Discussion , Nathan Parker References: From: Eric Voskuil Message-ID: <807a2661-b83e-1fc7-3db0-35ee120745bd@voskuil.org> Date: Sun, 28 Jan 2018 16:46:51 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nlOhHaQaIAx3ERUjxEHs5df9ukLH5unD1" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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: Mon, 29 Jan 2018 00:54:50 +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 00:46:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nlOhHaQaIAx3ERUjxEHs5df9ukLH5unD1 Content-Type: multipart/mixed; boundary="5Ssgj5mPhwKCbjwzPVSu2fbXZxNiEfGGY"; protected-headers="v1" From: Eric Voskuil To: Lucas Clemente Vella , Bitcoin Protocol Discussion , Nathan Parker Message-ID: <807a2661-b83e-1fc7-3db0-35ee120745bd@voskuil.org> Subject: Re: [bitcoin-dev] Proposal: rewarding fees to next block miner References: In-Reply-To: --5Ssgj5mPhwKCbjwzPVSu2fbXZxNiEfGGY Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Miners accept less than the optimal (i.e. highest net fee) set of transactions all the time. The reason is that it takes too much time to compute the optimal set. All other things being equal, the miner who is more efficient at computing a set is more profitable. Intentionally not accepting the most optimal set possible is a cost, not a source of increased returns. Miners can raise the historical fee level by paying this real cost, just as can any other person (by submitting a competitive-fee transaction). They cannot "recover" this cost. They have no place of advantage in terms of competing for block space. Finally, historical prices do not determine future prices. Current competition for block space determines future prices. e On 01/28/2018 08:54 AM, Lucas Clemente Vella via bitcoin-dev 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 > >: >=20 > Miners can fill their blocks with transactions paying very high fee= s > at no cost because they get the fees back to themselves. They can d= o > this for different purposes, like trying to increase the recommende= d > fee. Here I propose a backwards-compatible solution to this problem= =2E >=20 > The solution would be to reward the fees of the current block to th= e > 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 thi= s > reward. >=20 > The way to implement this in a backwards-compatible fashion would b= e > 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 ne= w > 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. >=20 > Implementing this would require a soft-fork. Since that secondary > transaction needs no signature whatsoever, the overhead caused by > that extra transaction is negligible. >=20 > 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. >=20 >=20 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >=20 >=20 >=20 >=20 > --=20 > Lucas Clemente Vella > lvella@gmail.com >=20 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >=20 --5Ssgj5mPhwKCbjwzPVSu2fbXZxNiEfGGY-- --nlOhHaQaIAx3ERUjxEHs5df9ukLH5unD1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJabm77AAoJEDzYwH8LXOFOd3UH/RvS7XbH58gMGzz2qN4SUicN YaiNqcVOVo6a3jjhKFqhvMawEzh5jNwY0nDglm1JsZicGyByr349NYjuiD7IslOn VWv/ExpF9THheMfWO1hOFXK5sKPpCFsYggjtZm/JPWEdYWUY0d6L6AHRcAoGm0WM +yHH17HC6Jg3Y5laD4aYHrHrZdIJsU9ty1uDqW69MaY+7Bq5ydUb3BbZrBMMDuwI exqBZlRjPR2QcaAFPiLaZiaXRTw2t1PoIxdD0fuHNIfyNuErKL4iarUKEdkkVWxc L0iv6vmBv4lZXtoDQ0udAZmmm94GyLQYlONtZmTRTyItyAa58nKZLBbUNBUZvpI= =2xab -----END PGP SIGNATURE----- --nlOhHaQaIAx3ERUjxEHs5df9ukLH5unD1--