Bitcoin Forum
May 30, 2024, 09:22:36 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Is this a viable solution to the Tragedy of the Commons problem?  (Read 610 times)
TheKing01 (OP)
Newbie
*
Offline Offline

Activity: 12
Merit: 0


View Profile
May 12, 2016, 08:06:08 PM
 #1

Tragedy of the Commons (https://en.bitcoin.it/wiki/Tragedy_of_the_Commons) is a problem that bitcoin will face as miner fees decline. Since including a transaction in a block is negligible, miners will accept all transactions with positive fees (no matter how low). Then, users will set their fees to the minimum possible. This in turn leads to less bitcoins going to fees, and less network security (since the cost of 51% attack = cost of mining = revenue of mining = fees at this point).

Many solutions have been proposed, but I don't like any of them (since most of them involve hard coding constants). I have a solution that requires no hard coding of constants!

How it works is that each block specifies a fee percentage (say p), and all transactions are based on that percentage.

If a transaction comes with a fee that is more than p, additional money is refunded back to the user so that it is exactly p.

If a transaction comes with a fee that is less than p, that transaction can't be included in that block.

This means that if a miner selects too low of a p, they will get less money (since all transactions are lowered to that amount), but if they they choose to high of a p, they will get less money (because there will be some transactions they can't include). They have to choose the correct p, which won't approach 0! Users in turn have to include enough fees to get accepted into blocks. In actuality, if there are a bunch of low fee transactions, someone will eventually include them with a low p, since there are so many. So your fee determines basically how soon your transaction gets confirmed.

What do you think?
danda
Full Member
***
Offline Offline

Activity: 201
Merit: 157


View Profile WWW
May 12, 2016, 11:11:21 PM
 #2

It seems to me that this problem can only occur if there is little or no competition for getting included into blocks.

So long as block space is limited and there is significant competition to be included, then transaction fees should be sufficient to support mining at a sustainable level.




mybitprices.info - wallet auditing   |  hd-wallet-derive - derive keys locally |  hd-wallet-addrs - find used addrs
lightning-nodes - list of LN nodes  |  coinparams - params for 300+ alts  |  jsonrpc-cli - cli jsonrpc client
subaddress-derive-xmr - monero offline wallet tool
TheKing01 (OP)
Newbie
*
Offline Offline

Activity: 12
Merit: 0


View Profile
May 13, 2016, 01:41:00 AM
 #3

Quote
It seems to me that this problem can only occur if there is little or no competition for getting included into blocks.

That is correct. The problem is, limited block space is bad. It limits the throughput of bitcoin.
botany
Legendary
*
Offline Offline

Activity: 1582
Merit: 1064


View Profile
May 13, 2016, 01:45:09 AM
 #4

This problem should occur only in the distant future.
Currently, miners get most of their money through the block reward. Fees account for a negligible portion.
Even with the reward halving, (expected) appreciation of bitcoin would result in this remaining the same.
TheKing01 (OP)
Newbie
*
Offline Offline

Activity: 12
Merit: 0


View Profile
May 13, 2016, 02:50:42 AM
 #5

Well sure it will be in the future, but bitcoin is supposed to be futuristic technology. Planning ahead is a good thing.
odolvlobo
Legendary
*
Offline Offline

Activity: 4326
Merit: 3247



View Profile
May 13, 2016, 08:49:15 AM
 #6

How it works is that each block specifies a fee percentage (say p), and all transactions are based on that percentage.
If a transaction comes with a fee that is more than p, additional money is refunded back to the user so that it is exactly p.
If a transaction comes with a fee that is less than p, that transaction can't be included in that block.

How is p determined and what is it a percentage of?

Join an anti-signature campaign: Click ignore on the members of signature campaigns.
PGP Fingerprint: 6B6BC26599EC24EF7E29A405EAF050539D0B2925 Signing address: 13GAVJo8YaAuenj6keiEykwxWUZ7jMoSLt
TheKing01 (OP)
Newbie
*
Offline Offline

Activity: 12
Merit: 0


View Profile
May 13, 2016, 09:34:20 AM
 #7

p is a number from 0% to 100% choosen each block by the miner. It is the percentage of each transaction that are sent as fees. This way, within a single block, everyone pays the same rate.
odolvlobo
Legendary
*
Offline Offline

Activity: 4326
Merit: 3247



View Profile
May 13, 2016, 08:06:07 PM
Last edit: May 13, 2016, 08:25:37 PM by odolvlobo
 #8

p is a number from 0% to 100% choosen each block by the miner. It is the percentage of each transaction that are sent as fees. This way, within a single block, everyone pays the same rate.


The problem with low fees is that miners are willing to include transactions with low fees because rejecting them is throwing away free money -- the marginal cost of including a transaction is very low. Plus, even if one miner excludes low fee transactions, other miners will include them. As a result, users are not motivated to pay more unless they need the transaction in the next block.

So, now that we understand the problem...

If miners can choose 0% (or even 1%), then how does a percentage fix the problem of accepting low fees? Miners already pick transactions based on fee (along with other criteria). I don't see how you proposal changes anything.

Finally, transaction value has no effect on the cost of including a transaction, so it doesn't sense for miners to base the minimum fee on the value of the transaction. However, users do care about the fee relative to the amount of the transaction. A user sending $0.01 won't want pay a $0.05 fee. The result of this conflict in priorities will be the inevitable formation of two or more systems differentiated by transaction value. High value transactions will use Bitcoin and low value transactions will use something more appropriate for micropayments.


Join an anti-signature campaign: Click ignore on the members of signature campaigns.
PGP Fingerprint: 6B6BC26599EC24EF7E29A405EAF050539D0B2925 Signing address: 13GAVJo8YaAuenj6keiEykwxWUZ7jMoSLt
TheKing01 (OP)
Newbie
*
Offline Offline

Activity: 12
Merit: 0


View Profile
May 14, 2016, 12:47:15 AM
 #9

If they pick 0%, *all* of the fees drop the 0%. If a fee is more than p, the miner only gets p of every transaction.

I chose for it to be relative to the transaction because including transactions should be negligible, and the amount of benefit a user gets in proportional to the value of their transactions.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!