Bitcoin Forum
July 29, 2024, 10:19:18 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Does transfers get higher priority as time goes by?  (Read 554 times)
Mysticsam_3579 (OP)
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
March 12, 2013, 09:52:34 PM
Last edit: March 12, 2013, 10:45:38 PM by Mysticsam_3579
 #1

Hi

I have search the forum and i haven't found a solid answer for this question.

Say that i am transferring 0.00004 bitcoin that have 73 confirms from my wallet-A to my wallet-B with no fee.

To calculate the priority for the transfer is: (input_value_in_base_units * input_age)/size_in_bytes

So: (4000*73)/300 (I just picked a number for the size of the transfer) =  973,33

The priority for the transfer as it is sent will be 973,33. But it need a priority of 57,600,000 to avoid the enforced fee and being viewed as a non low priority transfer.

To calculate how long it will take: (57.600.000*300)/(4000*73)= 59178,082191781 (which are the numbers of confirmations required to get passed the enforced fee level)
/ 6 (the number of confirmations per hour) / 24 (number of hours in a day) = 410,958904110  (the number of days required to bring it in a block)
 (this is over a year but because it is my own wallets i dont mind)

That if the priority goes up as the time goes by and there is a miner that accept nofee transfers.

But if the priority is the same 973,33 when it will never get included in a block.

So how is it?

Will this transfer never get included in a block or is it just to wait for the transfer to get through?
And are my calculations right?

Thank you all in advance.
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2506
Merit: 1010


View Profile
March 13, 2013, 10:02:04 AM
 #2

Will this transfer never get included in a block or is it just to wait for the transfer to get through?

There is only so much space for free transactions in a block.   Miners will try to put even low priority transactions into a block when there is space.  If there is no space, then your transaction waits.    

The mining nodes keep transactions that it knows about in a memory pool.  However that too has a limit.  So if your transaction doesn't confirm in about a day and the miner's memory pool is filling, your low priority transaction might be the first to get shipped to /dev/null (it is based on age).   Your node would rebroadcast it but the miner would just add it back in to the memory pool as a new transaction.  And the process repeats until it gets /dev/null.

Bitcoin wasn't made for sub-cent microtransactions.  Because there was space to accommodate it, you used to be able to get away with free and/or low priority transactions.    Those days are just about over.

So, ..  just pay the freight.  

Unichange.me

            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █


Mysticsam_3579 (OP)
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
March 13, 2013, 12:02:11 PM
 #3

Ok
So the transfer never gets higher priority as it is waiting to get included in a block ?
If it would when in this example after little more then a year the transfer would be seen as a normal transfer and it would get included in a block.

That is what you are saying right?
co5hike
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000



View Profile
March 13, 2013, 12:30:33 PM
 #4

Ok
So the transfer never gets higher priority as it is waiting to get included in a block ?
If it would when in this example after little more then a year the transfer would be seen as a normal transfer and it would get included in a block.

That is what you are saying right?

To be egliblible for free transaction and storing in waiting memory pool, it must have both required priority and all outputs must be at least 0,01 BTC
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
March 13, 2013, 03:01:35 PM
 #5

Priority is based on current time not the time of sending.  So yes the priority will slowly rise.

Many miners include no fee transactions HOWEVER as an anti DOS prevention measure they only include no fee HIGH PRIORITY tx.  Your example tx is low priority.  You can't even send that without patching the client or creating a raw transaction.   Most nodes will refuse to relay it and most miners will refuse to mine it.... until it becomes high priority in ~410 days.

It is important to remember there are essentially two fees in Bitcoin although they are lumped together:

a) min mandatory fees on low priority tx - these are essentially anti-spam rules and don't exist to generate revenue (the amount of revenue they would generate is negligible).  The purpose of these rules is to prevent an attacker from destroying the network at negligible cost.

To avoid this requirement your tx must meet the criteria here:
https://en.bitcoin.it/wiki/Transaction_fees

If your tx is doesn't meet the criteria to bypass the min mandatory fee AND you send it without a fee it is highly likely it will never be included in a block as any node running unmodified bitcoind will refuse to relay/mine these tx as a security measure even if there is space available in a block.  

b) optional fees.  fees paid on high priority txs (which don't require a fee) or fees paid in excess of the min mandatory fees.  Users include these fees to increase the likelihood a tx will be included in the next block.  Since miners prioritize tx in the memory pool based on fees paid a higher fee in theory means faster inclusion in a block.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
March 13, 2013, 03:08:36 PM
 #6

So the transfer never gets higher priority as it is waiting to get included in a block ?
If it would when in this example after little more then a year the transfer would be seen as a normal transfer and it would get included in a block.

No.  Priority IS recalculated after each block.  Priority does increase "as time goes by". The priority of the tx will rise with time however if the outputs are less then 0.001 or the size is greater than 10kb the min mandatory fee is required.   The age is based on the current block height not the block height when the tx was first transmitted (something which can't be verified anyways).

However ALL three conditions must apply to avoid the fee:
The tx must be 10KB or smaller.
The outputs must all be 0.01 BTC or larger.
The priority must be 57,600,000 (roughly 1 bitcoin-day).

In your example tx even when the priority is over 1 bitcoin-day the tx will still require the min mandatory fee.  If you haven't paid it any node running same rules as the reference client will refuse to relay the tx or include it in a block.  If this seems "unfair" remember the min mandatory fee rules are about protecting the network.  They are designed to ensure that an attacker can't bloat the network with low/no cost.  Without the min mandatory fee rules an attacker could simply transfer coins from Address A to Address B and back again.  Even if these tx were lower priority then all "legit" traffic the attacker could "max out" all available block space (i.e. make every block 1MB or max allowed by miners even when real tx volume is much lower).
Mysticsam_3579 (OP)
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
March 13, 2013, 05:53:12 PM
 #7

Thanks for the explaining :=)

Now understand it better.
But what is this "block height"?
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
March 14, 2013, 12:15:22 AM
 #8

Thanks for the explaining :=)

Now understand it better.
But what is this "block height"?

The block number.  Technically blocks don't have a number (nothing in the block identifies it as block #220,000 or #1 for example).  

The block height of the current block (at time of writing) is 225726
http://blockchain.info/block-index/358746/000000000000005c77e001bc8cc0d9fcabbf6801a70d9dc4baca4534f2504cf4
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!