Bitcoin Forum
December 04, 2016, 02:24:04 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: dPriority and free transactions  (Read 1161 times)
Hal
VIP
Sr. Member
*
expert
Offline Offline

Activity: 314



View Profile
March 05, 2011, 07:14:52 AM
 #1

CreateNewBlock() has this code:
Code:
3368         uint64 nBlockSize = 1000;
3369         int nBlockSigOps = 100;
3370         while (!mapPriority.empty())
3371         {
3372             // Take highest priority transaction off priority queue
3373             double dPriority = -(*mapPriority.begin()).first;
3374             CTransaction& tx = *(*mapPriority.begin()).second;
3375             mapPriority.erase(mapPriority.begin());
3376
3377             // Size limits
3378             unsigned int nTxSize = ::GetSerializeSize(tx, SER_NETWORK);
3379             if (nBlockSize + nTxSize >= MAX_BLOCK_SIZE_GEN)
3380                 continue;
3381             int nTxSigOps = tx.GetSigOpCount();
3382             if (nBlockSigOps + nTxSigOps >= MAX_BLOCK_SIGOPS)
3383                 continue;
3384
3385             // Transaction fee required depends on block size
3386             bool fAllowFree = (nBlockSize + nTxSize < 4000 || dPriority > COIN * 144 / 250);
3387             int64 nMinFee = tx.GetMinFee(nBlockSize, fAllowFree);
The last couple of lines here relate to one of the free-transaction rules: if the size counting the new tx is < 4000 then it is eligible to pay no tx fee.

I wanted to point out the first line, which initializes nBlockSize to 1000. It means there is only 3000 bytes reserved for free transactions, not 4K as often stated.

dPriority for a tx is calculated as sum over all input transactions of the input value times its depth, divided by tx size in bytes. This is compared above with 144/250, in units of bitcoins. 250 is about the size of a simple transaction, so to be eligible for no tx fees beyond the 3000 bytes area, the average depth of the inputs times the tx value must be > 144 btc (more for complex transactions with many inputs). If so, the GetMinFee() function allows up to 27K of space.

A special case is transactions with input(s) not in blocks. These don't contribute to priority, as though depth==0. If all the inputs are not in blocks, then dPriority will be zero, and the tx can go into the block only if its predecessors have got into the block.

If someone sends out a bunch of transactions quickly, such that each one depends on the one before, then all but possibly the first will have dPriority zero. With no tx fees, only about 12 can get into the 3K free area. If there are other transactions around, there will be room for fewer.

I do see a pattern of blocks about 3.1K in size with about 12 transaction. Also there have been reports of chains of transactions, each dependent on the previous, getting into consecutive blocks, one per block. This might be because with each new block, (only) the next tx in the chain gets nonzero dPriority.

Hal Finney
1480861444
Hero Member
*
Offline Offline

Posts: 1480861444

View Profile Personal Message (Offline)

Ignore
1480861444
Reply with quote  #2

1480861444
Report to moderator
1480861444
Hero Member
*
Offline Offline

Posts: 1480861444

View Profile Personal Message (Offline)

Ignore
1480861444
Reply with quote  #2

1480861444
Report to moderator
1480861444
Hero Member
*
Offline Offline

Posts: 1480861444

View Profile Personal Message (Offline)

Ignore
1480861444
Reply with quote  #2

1480861444
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
March 05, 2011, 03:34:39 PM
 #2

Nice analysis!  I'm tempted to put a link to your post in the code as a comment...

The whole transaction prioritization scheme was written by Satoshi after I suggested that de-prioritizing "small new" transactions might help the spamming problem.  In the last couple of days we've exchanged email about possibly modifying it; pull request 88 is the first suggested change (it makes the CreateTransaction fee calculations match the CreateBlock calculations).

Until somebody finishes implementing lightweight 'headers-only block download', we should try to keep block size small-- otherwise new users will have to wait an even longer time before being able to use bitcoin.

Also:  the Faucet is now paying a 0.01 BTC fee per transaction.  With the CreateTransaction fix, it probably would be anyway (the transactions it creates look very spammy).

How often do you get the chance to work on a potentially world-changing project?
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
March 05, 2011, 05:43:54 PM
 #3

For the Faucet, I think somebody already suggested pre-warming transactions and I didn't really understand the rationale for not doing it. So we'd take a block of ⓑ50 or whatever and then break it down into lots of ⓑ0.05 sends to unique addresses, but it can be done in a rolling manner. Then when somebody requests coins from the faucet one of those addresses is used. The coin being sent has many confirmations by this point so it's not deemed to be spam.
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!