To: Gregory Maxwell <greg@xiph.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Nathan Parker <icesby24@gmail.com>
References: <CAPzrG5bFTbRERHQsmyFeZwiuakgSW5UCC8EtYfAm4j9EDtcLeg@mail.gmail.com>
	<CAAS2fgSzx_beEQqPOdoRJRVMSk0JNT6LGk0fHTktVSCU7sH1cA@mail.gmail.com>
From: Eric Voskuil <eric@voskuil.org>
Message-ID: <65742e8e-ee27-40b9-f8ad-37f22916002d@voskuil.org>
Date: Sat, 27 Jan 2018 15:48:10 -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: <CAAS2fgSzx_beEQqPOdoRJRVMSk0JNT6LGk0fHTktVSCU7sH1cA@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="fiqWjqOvRd381ocrCc3u6cqi6DEzeZt0W"
Subject: Re: [bitcoin-dev] Proposal: rewarding fees to next block miner
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--fiqWjqOvRd381ocrCc3u6cqi6DEzeZt0W
Content-Type: multipart/mixed; boundary="rsndbNS3Bhsv5UUjZbwcYWxbnMmM0TXr9";
 protected-headers="v1"
From: Eric Voskuil <eric@voskuil.org>
To: Gregory Maxwell <greg@xiph.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Nathan Parker <icesby24@gmail.com>
Message-ID: <65742e8e-ee27-40b9-f8ad-37f22916002d@voskuil.org>
Subject: Re: [bitcoin-dev] Proposal: rewarding fees to next block miner
References: <CAPzrG5bFTbRERHQsmyFeZwiuakgSW5UCC8EtYfAm4j9EDtcLeg@mail.gmail.com>
 <CAAS2fgSzx_beEQqPOdoRJRVMSk0JNT6LGk0fHTktVSCU7sH1cA@mail.gmail.com>
In-Reply-To: <CAAS2fgSzx_beEQqPOdoRJRVMSk0JNT6LGk0fHTktVSCU7sH1cA@mail.gmail.com>

--rsndbNS3Bhsv5UUjZbwcYWxbnMmM0TXr9
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

The OP premise is flawed:

https://github.com/libbitcoin/libbitcoin/wiki/Fee-Recovery-Fallacy

as is the idea that side fees are incentive incompatible:

https://github.com/libbitcoin/libbitcoin/wiki/Side-Fee-Fallacy

e

On 01/27/2018 11:06 AM, Gregory Maxwell via bitcoin-dev wrote:
> Not incentive compatible. Miners would prefer to include transactions
> paying fees via alternative mechanisms (anyone can spend outputs,
> direct pay to miner outputs, or completely out of band), if they even
> paid attention to internal fees at all they would give a lot more
> weight to direct payment fees. Users would accordingly pay much lower
> fees if they used these alternatives instead of directly, so the
> equlibrium state is almost everyone bypassing.   Bypass fee mechenisms
> have been supported by miners since 2011 too, so it isn't just
> conjecture.
>=20
> On Sat, Jan 27, 2018 at 8:45 AM, Nathan Parker via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Miners can fill their blocks with transactions paying very high fees a=
t no
>> cost because they get the fees back to themselves. They can do this fo=
r
>> 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 m=
iner
>> 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 n=
o
>> longer given back to itself, but to the miner of future blocks which c=
ould
>> potentially be anyone. Flooding blocks with fake txs is now discourage=
d.
>> However, filling blocks with real transactions paying real fees is sti=
ll
>> encouraged because you could be the one to mine the block that would c=
laim
>> this reward.
>>
>> The way to implement this in a backwards-compatible fashion would be t=
o
>> enforce miners to set an anyone-can-spend output in the coinbase trans=
action
>> 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 sp=
ending
>> this block's anyone-can-spend coinbase transaction (due to the coinbas=
e
>> needing 100 blocks to mature) and thus claiming the funds. This way, t=
he
>> 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=99=
t 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 t=
hat
>> period, so the hashrate could drop temporarily. However, if the hashra=
te
>> drops too much, blocks would take much longer to mine, and miners woul=
dn=E2=80=99t
>> want that either since they want to go through those 100 reward-less b=
locks
>> as soon as possible so they can start getting rewards from mining agai=
n.
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20


--rsndbNS3Bhsv5UUjZbwcYWxbnMmM0TXr9--

--fiqWjqOvRd381ocrCc3u6cqi6DEzeZt0W
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)

iQEcBAEBAgAGBQJabQ+6AAoJEDzYwH8LXOFO0iIH/3vXCstKi2fFG57zQtnkM+3b
qmFnDthoSEZNa2d4OqjPCsBbVVJDJfcWqvxnbwOORAJ7znKBFJNF2P/IoX9mUxQp
iba7CJL5E7DfYL/bsrfMetjQEi79acEFCYOwEu9X3kLbfdzcRKq68TVScEeLEKX8
MyQpQ4+F4uKRiJvNLjKozt7ovz88weU4OFtB0u5QTLhX9dNHdLsXZn/NdK+lBMA/
bp1xVdfucxjwme9AApGeut9Nt8840iVAWo10S+e7Nka5+YulCFIE2/RS91Ewyrp+
tLjEm1SJKPr88Algq6chtOe8dw4oiTtkLL1dXv0V0JcBeTqzXfw90jEsvjEyj8A=
=hHzi
-----END PGP SIGNATURE-----

--fiqWjqOvRd381ocrCc3u6cqi6DEzeZt0W--