Re: [bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool)

[Luke Dashjr <luke@dashjr.org>]

On Thursday, March 30, 2017 9:34:31 AM Natanael via bitcoin-dev wrote:
> You want to really make sure your transaction gets processed quickly?
> Transactions could have a second fee type, a specially labeled
> anyone-can-spend output with an op_return value defining a "best-before"
> block number and some function describing the decline of the fee value for
> every future block, such that before block N the miners can claim the full
> expedience fee + the standard fee (if any), between block N+1 and N+X the
> miner can claim a reduced expedience fee + standard fee, afterwards only
> the standard fee.

Minor detail: OP_RETURN doesn't work like that. You'd need OP_DROP.

> When a transaction is processed late such that not the full expedience fee
> can be claimed, the remainder of the expedience fee output is returned to
> the specified address among the inputs/outputs (could be something like
> in#3 for the address used by the 3rd UTXO input). This would have to be
> done for all remaining expedience fees within the last transaction in the
> block, inserted there by the miner.

Inputs don't have addresses, and addresses should only ever be used once.
You might be able to fix this by increasing the value of the change, though.
It would require a new signature-check opcode at the very least.

I don't see a purpose to this proposal. Miners always mine as if it's their 
*only* chance to get the fee, because if they don't, another miner will. Ie, 
after 1 block, the fee effectively drops to 0 already.

> ---
> 
> Fee pool. Softfork compatible.

The standard problem with these is that miners are incentivised to publish 
their own "out of band fee" address so they get all the fee directly.

Luke