Bitcoin Forum
December 07, 2016, 10:21:58 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Transaction fees  (Read 4078 times)
Gavin Andresen
Legendary
*
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
July 26, 2012, 04:57:37 PM
 #1

I just sent this email to the biggest mining pool operators; I think creating a real market between users and miners to set transaction fees is a very high priority.

After a lot of thinking, trying a few different implementations, and a couple days of testing I'm finally happy with a new scheme for selecting which transactions to include in created blocks.

Patch for version 0.6.3:
https://github.com/gavinandresen/bitcoin-git/commit/ed0531d8242c75c8c055ec5b4d134d42ea380158.patch

This is pull request #1590 and will very likely be part of the upcoming 0.7 release.

Backported patch for version 0.3.24 if you're stuck on an old version of bitcoind:
https://github.com/gavinandresen/bitcoin-git/commit/57df05e2cd48716ad2fa2e7379d61b980c65aade.patch

These add new command-line / bitcoin.conf options:
Code:
 -blockmaxsize=250000
  -blockminsize=0
  -blockprioritysize=27000
  -mintxfee=0.0005

The above settings are the default, and match the current default behavior. If you are using a stock bitcoind to create your blocks and apply the patch, the only difference you will see is a higher block reward, because the new code prefers transactions with higher fees to transactions with lower fees.

The new options let you control your transaction acceptance policy without recompiling; here is what they do and how to use them:

-blockmaxsize controls the maximum size of blocks created, in bytes. I know some pools are limiting the size of the blocks they create because they think larger blocks are more likely to be orphaned; this setting lets you do that easily. Reasonable values are between 50,000 and 250,000 bytes.

-blockminsize lets you fill up any 'extra' space in blocks with free transactions, until the block is -blockminsize bytes big. You can use this to implement a policy of "Fill up the block with fee-paying transactions first, but if there aren't enough then include free transactions."  Reasonable values are 0 to blockmaxsize.

-blockprioritysize is the primary way to support free transactions. This many bytes at the beginning of the block are set aside for the highest priority transactions, regardless of whether or not they pay a fee. Reasonable values are 0 to blockmaxsize.

-mintxfee is the minimum fee, measured in bitcoins-per-1,000-bytes, for a transaction to be considered 'paid' instead of 'free.' It should ideally be a little larger than your real-world cost to process a transaction. Reasonable values are 0.0001 to 0.01  (setting this too low is dangerous; a transaction spammer can fill up your blocks with very-low-but-non-zero-fee transactions)


So, putting it all together, here are some possible fee policies you might want to follow:

CREATE SMALLER BLOCKS

You want to limit the size of the blocks you create so they propagate faster.

Code:
blockmaxsize=50000
blockminsize=0
blockprioritysize=10000
mintxfee=0.0005

PUNISH HIGH-FREQUENCY USERS

You want to mostly include transactions based on priority, to discourage SatoshiDice-like services where people are sending blizzards of low-value transactions. But you still want to pick up any large-transaction-fee transactions.

Code:
blockmaxsize=100000
blockminsize=0
blockprioritysize=50000
mintxfee=0.01

MAXIMUM FEES

You want to maximize your block reward, including as many fee-paying transactions as possible but avoiding all free transactions.

Code:
blockmaxsize=250000
blockminsize=0
blockprioritysize=0
mintxfee=0.0001


MAXIMUM FEES, ALLOW FREE

You want to maximize the fees you get, but allow some free transactions if transaction volume on the network is low.

Code:
blockmaxsize=250000
blockminsize=50000
blockprioritysize=0
mintxfee=0.0001

MAXIMUM COMPATIBILITY WITH EXISTING CLIENTS

If you want the best compatibility with Bitcoin-Qt and other existing clients, use the default values.



Next on my TODO list: implement client-side code to figure out what the average miner's fee policy is by looking at how quickly transactions are being accepted into blocks, and recommend a reasonable fee to users on a per-transaction basis.

How often do you get the chance to work on a potentially world-changing project?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481149318
Hero Member
*
Offline Offline

Posts: 1481149318

View Profile Personal Message (Offline)

Ignore
1481149318
Reply with quote  #2

1481149318
Report to moderator
1481149318
Hero Member
*
Offline Offline

Posts: 1481149318

View Profile Personal Message (Offline)

Ignore
1481149318
Reply with quote  #2

1481149318
Report to moderator
Coinoisseur
Sr. Member
****
Offline Offline

Activity: 252


View Profile
July 26, 2012, 06:05:56 PM
 #2

Happy to see the groundwork being set for a healthy "post-fixed block reward mining" Bitcoin network.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
July 26, 2012, 06:08:59 PM
 #3

Very nice to see this.   Laying the foundation for a future fee marketplace.
sturle
Legendary
*
Offline Offline

Activity: 1418

http://bitmynt.no


View Profile WWW
July 26, 2012, 06:16:11 PM
 #4

-blockmaxsize controls the maximum size of blocks created, in bytes. I know some pools are limiting the size of the blocks they create because they think larger blocks are more likely to be orphaned; this setting lets you do that easily. Reasonable values are between 50,000 and 250,000 bytes.
I think it is unfortunate to implement this without implementing a way to ignore asocial blocks as well.  If a new block arrive and only include a very small percentage of the waiting priority transactions, this is in effect a DOS attack against Bitcoin.  We all remember the 0-tx miner from earlier this year.  I don't want to build on those blocks until I have to.
Quote
Next on my TODO list: implement client-side code to figure out what the average miner's fee policy is by looking at how quickly transactions are being accepted into blocks, and recommend a reasonable fee to users on a per-transaction basis.
I think this should have come as the first patch.  There are several policies around already, and no way for the clients to know.  This patch could make the situation worse.

Another option I would hope to see was tiers of different cost, a combination of -blockprioritysize and -mintxfee.  E.g. first 25k for high priority 0-fee tx, next 25k for at least 0.0001 fee, next 25k for 0.0005 fee, next for 0.001 fee, etc.  Large fee transactions will get included by making the block larger, not by squeezing out the smaller fee transactions which have waited for a long time already.

Sjå http://bitmynt.no for veksling av bitcoin mot norske kroner.  Trygt, billig, raskt og enkelt sidan 2010.
I buy with EUR and other currencies at a fair market price when you want to sell.  See http://bitmynt.no/eurprice.pl
I support the roadmap.  If a majority of miners ever try to forcefully take control of Bitcoin through a hard fork without 100% consensus, I will immediately split out and dump all my forkcoins, and buy more real Bitcoin.
Eiii
Newbie
*
Offline Offline

Activity: 23


View Profile
July 26, 2012, 09:52:25 PM
 #5

I'm really happy to see fees start to get some use, it'll be interesting to see how pools choose transactions once the reward drops from the 50 everyone's so comfortable with now. Hopefully pools adopt this soon!
Graet
VIP
Legendary
*
Offline Offline

Activity: 980



View Profile WWW
July 27, 2012, 01:25:34 AM
 #6

Thanks Gavin
Good work Smiley

| Ozcoin Pooled Mining Pty Ltd https://ozcoin.net Double Geometric Reward System https://lc.ozcoin.net for Litecoin mining DGM| https://crowncloud.net VPS and Dedicated Servers for the BTC community
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!