Well, it really depends on the miners. Check out the https://en.bitcoin.it/wiki/Free_transaction_relay_policy .
Some people run tests with modified clients. It may be worthwhile for you to connect to the node(s) described in the above article.
Topic: Transaction fees (for 0.01 BTC) (Read 2506 times)
It is a completely linear score:
This is all in main.{h,cpp} for the curious.
Thank you, very helpful!Code:
static bool AllowFree(double dPriority)
{
// Large (in bytes) low-priority (new, small-coin) transactions
// need a fee.
return dPriority > COIN * 144 / 250;
}
where dPriority is measured in value-in-satoshis times age-in-blocks divided by transaction-size-in-bytes.{
// Large (in bytes) low-priority (new, small-coin) transactions
// need a fee.
return dPriority > COIN * 144 / 250;
}
This is all in main.{h,cpp} for the curious.
Guess that 1 satoshi I sent won't be fee-free for quite a while...
It is a completely linear score:
This is all in main.{h,cpp} for the curious.
Code:
static bool AllowFree(double dPriority)
{
// Large (in bytes) low-priority (new, small-coin) transactions
// need a fee.
return dPriority > COIN * 144 / 250;
}
where dPriority is measured in value-in-satoshis times age-in-blocks divided by transaction-size-in-bytes.{
// Large (in bytes) low-priority (new, small-coin) transactions
// need a fee.
return dPriority > COIN * 144 / 250;
}
This is all in main.{h,cpp} for the curious.
how long do I need to wait for bitcoins to qualify as not 'recently received' ?
I'm interested in this answer as well... though I suspect it's not a set limit, just a linear or logarithmic score based on age.well I waited about 12 hours and I was able to send w/ no fee so there is one data point
how long do I need to wait for bitcoins to qualify as not 'recently received' ?
I'm interested in this answer as well... though I suspect it's not a set limit, just a linear or logarithmic score based on age.
how long do I need to wait for bitcoins to qualify as not 'recently received' ?
Thank to both of you. Pieter Wuille's post is very useful after InstaGx's answer.
In Pieter Wuille's answer I've read that there is no verification of the address. It will be a great idea to publish somewhere a list of generated address (each of one signed for proof of existence) so we can have safe transaction. Thank you anyway.
In Pieter Wuille's answer I've read that there is no verification of the address. It will be a great idea to publish somewhere a list of generated address (each of one signed for proof of existence) so we can have safe transaction. Thank you anyway.
Hello,
I've sent 0.01 BTC to an address to check the system is working (auto generation of address) without any fee and it is. But now I cannot send my 0.01 BTC back because it requests a small fee of: 0.005 BTC. I've tried with the GUI and RPC and it is the same behavior : "Error: This transaction requires a transaction fee of at least 0.0005 because of its amount, complexity, or use of recently received funds".
Ok now I would like to understand why is there such a limitation (I mean why didn't have I to pay a fee for the 1st transaction but only for the 2nd?)? Is there a way to send them anyway and wait even if it has ridiculous low priority? It's been 3 days that I test it so the "recently received funds" should have expired?
I've sent 0.01 BTC to an address to check the system is working (auto generation of address) without any fee and it is. But now I cannot send my 0.01 BTC back because it requests a small fee of: 0.005 BTC. I've tried with the GUI and RPC and it is the same behavior : "Error: This transaction requires a transaction fee of at least 0.0005 because of its amount, complexity, or use of recently received funds".
Ok now I would like to understand why is there such a limitation (I mean why didn't have I to pay a fee for the 1st transaction but only for the 2nd?)? Is there a way to send them anyway and wait even if it has ridiculous low priority? It's been 3 days that I test it so the "recently received funds" should have expired?
The reason is a limitation in most currently active nodes on the network, which block (do not even forward) transactions that look "spammy" (too large, using too recent funds, or too small outputs) if they do not carry a minimum fee. We've been decreasing the minimum fee the past few versions, hoping to move to a more flexible scheme somewhere in the future. However, for some transactions now, if they do not carry a fee, there is a chance they will not be relayed at all by the network, effectively placing your coins in limbo. As a protection for the user, the client will not send without a fee in such cases.
Hello,
I've send 0.01 BTC to an address to check the system is working (auto generation of address) without any fee and it is. But now I cannot send my 0.01 BTC back because it request a small fee of: 0.005 BTC. I've tried with the GUI and RPC and it is the same behavior : "Error: This transaction requires a transaction fee of at least 0.0005 because of its amount, complexity, or use of recently received funds". Ok now I would like to understand why is there such a limitation (I mean why didn't have I to pay a fee for the 1st transaction but only for the 2nd?)? Is there a way to send them anyway and wait even if it has ridiculous low priority? It's been 3 days that I test it so the "recently received funds" should have expired?
I've send 0.01 BTC to an address to check the system is working (auto generation of address) without any fee and it is. But now I cannot send my 0.01 BTC back because it request a small fee of: 0.005 BTC. I've tried with the GUI and RPC and it is the same behavior : "Error: This transaction requires a transaction fee of at least 0.0005 because of its amount, complexity, or use of recently received funds". Ok now I would like to understand why is there such a limitation (I mean why didn't have I to pay a fee for the 1st transaction but only for the 2nd?)? Is there a way to send them anyway and wait even if it has ridiculous low priority? It's been 3 days that I test it so the "recently received funds" should have expired?
I guess it should be possible to send them anyway if you modify the client. Or just wait a few more days. It's just 0.01 BTC and they won't go anywhere.
An other short question: Can someone sends bitcoins to an offline generated address and the address owner check he received them when he is online again? If yes it should means that when my client generates a new address it don't needs to broadcast it or inform the Network.
Yes, it's possible to receive bitcoins on an address that has never been connected to the network. It's also possible to send btc to non-existing addresses that are in the correct format (we had that question in another thread yesterday).
Hello,
I've sent 0.01 BTC to an address to check the system is working (auto generation of address) without any fee and it is. But now I cannot send my 0.01 BTC back because it requests a small fee of: 0.005 BTC. I've tried with the GUI and RPC and it is the same behavior : "Error: This transaction requires a transaction fee of at least 0.0005 because of its amount, complexity, or use of recently received funds".
Ok now I would like to understand why is there such a limitation (I mean why didn't have I to pay a fee for the 1st transaction but only for the 2nd?)? Is there a way to send them anyway and wait even if it has ridiculous low priority? It's been 3 days that I test it so the "recently received funds" should have expired?
An other short question: Can someone sends bitcoins to an offline generated address and the address owner check he received them when he is online again? If yes it should means that when my client generates a new address it don't needs to broadcast it or inform the Network.
I've sent 0.01 BTC to an address to check the system is working (auto generation of address) without any fee and it is. But now I cannot send my 0.01 BTC back because it requests a small fee of: 0.005 BTC. I've tried with the GUI and RPC and it is the same behavior : "Error: This transaction requires a transaction fee of at least 0.0005 because of its amount, complexity, or use of recently received funds".
Ok now I would like to understand why is there such a limitation (I mean why didn't have I to pay a fee for the 1st transaction but only for the 2nd?)? Is there a way to send them anyway and wait even if it has ridiculous low priority? It's been 3 days that I test it so the "recently received funds" should have expired?
An other short question: Can someone sends bitcoins to an offline generated address and the address owner check he received them when he is online again? If yes it should means that when my client generates a new address it don't needs to broadcast it or inform the Network.
Jump to: