Topic: Calculation for transaction input-output balling: (Read 2254 times)

Yes although it is more complicated than that.  It is entirely possible that a tx paying the reduced fee could be included in a block now.  Remember Bitcoin isn't a single unified network with a central rule processor.  It is more like a collection of independent nodes.  Right now ~30% of all nodes on the network are running v0.9 and thus they will relay txs which meet the new lower fee.  If one or more miners are running nodes based on v0.9 (or custom solution using the same rules) it is very likely your tx will be included.   Now to prevent a chicken or the egg scenario v0.9 nodes will relay a tx w/ the lower fee but they won't allow users to create new tx based on that reduced fee.  This is to prevent stuck txs.  Imagine if you were the first node to upgrade to v0.9 and created a tx with the reduced fee.  Well it would go nowhere as all your peers (actually every other node on the planet) would see the see as insufficient and drop the tx.  Right now you could however bypass this (using raw transactions) and the tx might be confirmed.  A lot depends on how many (if any) miners are including low priority txs with the lower fee.  At some point in the future once most nodes and miners have upgraded to the new lower fee requirement a new version of the client will be released which can created tx as that lower requirement by default (the infrastructure now exists).


Agreed.  For each node if a tx has insufficient fee (unless it is high priority) then it is dropped.  It isn't included in the memory pool and it isn't relayed.  Miners select txs for the next block by pulling from their local memory pool.  If your tx isn't in that pool then you have no chance of being included in the block.  For all intents and purposes your tx doesn't exist.   Now some may ask why isn't it lower why not just allow tx w/ 1 satoshi fee and miners can decide if they want to include it or not.    The problem isn't inclusion in a block, the problem is relaying.  If lets say no miner will accept a tx w/ a fee less than 100 satoshis and all nodes will relay all txs regardless of the fee amount (or even 0 fee) then you could kill the network very easily by just flooding the network with tx that have a very low priority of ever getting in a block but it would degrade the performance of the network.  Imagine if your (and everyone elses) node resource requirements increased by 1000x because someone was continually rebroadcasting 1,000,000+ txs which have almost no chance of being included in the memory pool.


Well there are two factors to be considered:
a) will a tx will be relayed and even kept in the memory pool of the miner
b) how long will it take for the tx to end up at the top of the memory pool and be included in the next block.

The first is easier to answer and understand.  If your tx is low priority (less than 1 bitcoin day in age) and you do not include a fee equal to the min fee to relay, or any of the outputs are less than 5,430 satoshis (the dust threshold) then it is probably never* going to be confirmed.  Most miners will never even see it.  It is very likely that all your direct peers are running rules similar to the bitcoin-core and will just drop the tx.  In essence nobody will ever see it.  Now your node won't give up and it will keep rebroadcasting it and it will keep getting dropped.  It can't be included in a block if nobody even knows about it.

On the second this is much more dynamic.  It depends not only on your priority (or fee for paying txs) but the current and future priority (or fees) of other transactions.   Miners will simply sort the txs.  First they sort all the high priority txs by priority and include as many of them as will fit into the space reserve for free txs.  Then they sort all txs by fee per KB and include as many of them as will fit into the total block size.  All these parameters (min fee, kb of free txs, kb of total block space) are set by the miner.  As a rule of thumb if your tx is high priority (even 57,600,000 exactly), under 1KB, and has no dust outputs then it will be relayed by all nodes.  It will end up in the memory pool of all miners and it will eventually be included in a block.  It might by luck by the next block or it might be one of the next hundred blocks but it will be included.  It looks like most high priority txs make it into a block within a day.

* In theory eventually the rules might change such that the tx meets the new relay requirement or it might end up becoming high priority due to age and when either of those happen (assuming your nodes is still rebroadcasting) it will be relayed.  Of course that could be months, years, or potentially never in your lifetime so as a practical matter I just say "never".


The min fee to relay is really just a DDOS prevention mechanism and thus is has been lowered five times since the genesis block due to the rising value of one Bitcoin.  The fee has generally been lowered once it exceeded more than a few US cents and reduced to a fraction of a cent.  The goal is to keep the min fee low but not so low as to make it possible to flood the network with no or little cost.  As pointed out it is a crude system and in time will be replaced with floating fees but that is a more complex situation.   In the interim it would be good if the min fee was less than what miners required to include txs in a block.  This would mean the min fee isn't setting the "cost" of getting into a block, miners are. 

WOW!

http://www.coindesk.com/bitcoin-transaction-fees-slashed-tenfold/


From the article:

So the min fee in BTC is

0.0001BTC //now
0.00001BTC //soon

Anything below that is seen as the equivalent to offering zero (a waist of money).

It makes me really wonder; What is the minimum payment you would personally accept before you would consider it zero-worthless-a-waste-of-your-time?

I would like to contemplate how far these rules can be 'pushed' not so I can go ahead and deliberately 'push' them, but to get a better understanding of the boundaries (a line of chalk on the floor). What about a very small transaction that is just above the threshold (below 1000 bytes in size, with an old coin age)? How long would that take to go through? days, weeks? Is there a calculation for time-scale prediction?

For a second lets talk about faucets (The notion of a faucet is becoming ever more ridiculous to me). I don't do faucets but a friend does. I'm not wanting to bring the conversation entirely in this direction. I just want to make a grim point to her. Also just so you don't question my sanity - To add to my disclaimer; A transaction like this is almost infinitely unlikely (at least for 190 years) we would be dead by the time  .

I would like to know if this point is correct?

It would take 6 inputs of 0.00001BTC (the sort of payout a faucet might give) each with a coin age of ten million conformations (with a block generated every ten minutes this would take 69444.4 days) would be like so, In order to be free:


a transaction like that in it's self is crazy in the first place but, that is what it would look like. How long though would it take to confirm a transaction like that?? It is totally stupid but, based on the rules of Bitcoin's coin age it cannot be classed as transaction spam!
All that has happened here is the potential irritation and inconvenience of the 'dumb ass'-fee-less transaction has been passed to the user. So I can see why these rules are implemented!

But the rules would have to change as the worth of bit coin grows. As you say the min fee will soon be lowered! But there must be some reasoning (or rather equation) behind this! Is the min fee decreasing periodically based on a % of Bitcoin's worth?

Now sure what you mean 5% to 10%.  There is absolutely no reason to pay a fee greater than zero but below the min fee to relay (which is 0.1 mBTC but will be dropping to 0.01 mBTC so it may depend on what version of rules miners are using).  Any fee below the min is considered zero so it is just funds thrown away.  Generally speaking I find the min fee more than sufficient.  90%+ of the time the tx is in the next block and I can't remember it ever taking more than 3 blocks max.

So if I, in addition to this strategy add my own transaction fee 5-10% would this speed things up? Also I could wait a more on the coin age I think.

Tanks

#- - - >¬[¯¯°]]
________oooo,,,.. .

That looks correct although most of the time the calculations are done in satoshis and that makes the required priority to be 57,600,000.  A good rule of thumb is one bitcoin day.  1 BTC that is 1 day old can be sent without a fee.

I would point out that the 57,600,000 threshold is only the requirement for the tx to be relayed by nodes with no fee (or fee below min fee to relay).  A miner still needs to include it in a block.  Free tx are ranked by priority so just being barely over the requirement may put you at the end of a very long time.  Miners routinely only devote a small portion (or none) of the block to free tx so hypothetically if you are the 2,00th free tx when ranked and the average block holds 50 well you are going to be waiting a while.

Most likely in the release notes of the bitcoin core client.   The priority requirement should probably be lowered as it is really just intended as a safety mechanism to prevent an attacker from freely bloating the blockchain by sending tiny amounts of coins back and forth.

To roughly calculate transaction send size in bytes we do:

((numberOfInputs*148)+(numberOfOutputs*34)+10)

We want to make a transaction using two inputs of 0.01BTC (Amount to send = 0.015BTC, change left over = 0.005BTC). Number of outputs in this case will be two; as we have two inputs, one of which we are 'tearing-in-two' creating change that will be sent back to us (we are the second output so the change is not lost).

So to calculate the fee:

• We calculate the value of each input in BTC multiplied by the age of the input in blocks
• Add up all the answers into a total priority
• Divide the priority by the size of the transaction in bytes
• If this gives a number less than 0.576 then the transaction requires a fee
• Also if the transaction size exceeds 1000 bytes it requires a fee

If both inputs were 1000 conformations old, a fee would be required:


If both inputs were 11000 conformations old, a fee would not be required:


Is this correct?

If one input was old dust and the other new and large (this looks free to me):


Does this explain how you can put a dust-input with a large-input to rescue dust?

Will the threshold of 0.576 change in the future and if so how will we find out?

I gathered this theory from various posts on this site, google, bitcoin.stackexchange, and bitcoinfees.com