Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: just_a_user on March 11, 2017, 10:46:20 PM



Title: Let users vote with their transaction fee for soft-forks
Post by: just_a_user on March 11, 2017, 10:46:20 PM
Not sure if this has ever been discussed, but I as a user would like to vote with my transaction fee for a soft-fork.

Example:
If my transaction is included in a SegWit-ready block, the miner get's the transaction fee. Else the fee is zero.

This would naturally result in that only miners who support SegWit would pick my transaction. Other miners would have no benefit in picking my transaction to be included in the next block. But it would give me as a user at least some voting power on the further development/progression of the Bitcoin network.


Title: Re: Let users vote with their transaction fee for soft-forks
Post by: achow101 on March 12, 2017, 12:30:05 AM
That's not how transaction fees work. The transaction fee is the difference between the value of the inputs and the value of the outputs. There is no way to control who gets the transaction fee as it is implied, not explicit.


Title: Re: Let users vote with their transaction fee for soft-forks
Post by: just_a_user on March 12, 2017, 01:06:14 AM
It might require a protocol change (another soft-fork?):

1. The new "user voting transaction" could specify the transaction fee differently than it is done today. To be backwards compatible, such a transaction would have a difference of zero (0) between the values of the inputs and outputs. Therefore, old (current) miners would not very likely pick such a transaction (as they get no fee if they do so). Old nodes might not even propagate such a transaction.

2. The new "user voting transaction" could specify the miner fee as a P2SH output that has a dependency on the block it is included in, with certain conditions (e.g. SegWit ready). Only the miner who mined the block can redeem/spend that output if the mined block matches the "conditions" the user requested.
However, this requires a few additional/new script operations that allow nodes to validate the transaction against the block characteristics it is included in.

Not sure if this is possible at all, just a rough idea. But it would allow for a market/cooperation between users and miners - in contrast to today, where miners have the only voting possibility.


Title: Re: Let users vote with their transaction fee for soft-forks
Post by: DannyHamilton on March 12, 2017, 04:32:46 AM
This is actually possible if the mining pools want to implement it.

The idea would be that you could use RBF transactions.

First you would broadcast a RBF transaction with the fee you want for all the "other" miners.

Then you would immediately create a RBF transaction with a higher fee that you would provide directly to the mining pools you agree with instead of broadcasting on the network.  If those mining pools were to agree not to broadcast your transaction until it was included in a block they solved, then you could be sure that they would typically get the higher fee transaction.  The only time one of the "other" pools might get the increased fee would be if the block containing your transaction is orphaned.  In that case, the RBF transaction would be public and could be included in some other block.

It wouldn't be too difficult to automate this process into existing wallet software (MultiBit, Electrum, Core, Unlimited, Knots, etc), and wouldn't require a hard or soft fork. It would only require that the miners (pools) which you agree with provide a port or API to receive RBF transactions that they agree not to share on the network until broadcasting it in a solved block.


Title: Re: Let users vote with their transaction fee for soft-forks
Post by: Carlton Banks on March 12, 2017, 09:17:17 AM
This could never work

1. It depends entirely on the capacity of the network (which is highly ironic given the circumstances). The so-called "votes" would be in competition with other transactions for the limited blockspace. This creates distorted incentives to "vote", and a poorly representative poll as a result

2. There is no algorithmic mechanism to enforce the majority preference, the miners or pools who accept these votes could simply take the money and implement nothing.