|
Title: Transaction fees (for 0.01 BTC) Post by: jamesb on June 23, 2011, 11:31:39 AM 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. Title: Re: Transaction fees (for 0.01 BTC) Post by: InstaGx on June 23, 2011, 12:01:16 PM 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 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). Title: Re: Transaction fees (for 0.01 BTC) Post by: Pieter Wuille on June 23, 2011, 12:40:28 PM 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? 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. Title: Re: Transaction fees (for 0.01 BTC) Post by: jamesb on June 23, 2011, 05:42:59 PM 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. Title: Re: Transaction fees (for 0.01 BTC) Post by: Valhalla1 on July 15, 2011, 02:58:44 PM how long do I need to wait for bitcoins to qualify as not 'recently received' ?
Title: Re: Transaction fees (for 0.01 BTC) Post by: SgtSpike on July 15, 2011, 10:47:19 PM 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.Title: Re: Transaction fees (for 0.01 BTC) Post by: Valhalla1 on July 16, 2011, 12:56:03 AM 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 Title: Re: Transaction fees (for 0.01 BTC) Post by: 2112 on July 16, 2011, 01:07:04 AM It is a completely linear score:
Code: static bool AllowFree(double dPriority) This is all in main.{h,cpp} for the curious. Title: Re: Transaction fees (for 0.01 BTC) Post by: SgtSpike on July 16, 2011, 01:09:06 AM It is a completely linear score: Thank you, very helpful!Code: static bool AllowFree(double dPriority) 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... :P Title: Re: Transaction fees (for 0.01 BTC) Post by: 2112 on July 16, 2011, 02:10:37 AM 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. |