2012-05-08 Update:
NFTF - versions 0.6.0.7/0.6.1 & 0.6.2 released.
Fresh tags -are avaiable for download as usual.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags
Trunk code has also been merged from mainline client:
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tree/
Topic: [UPDATE: 2015-05-10] Bitcoin Core soft-fork "No Forced TX Fee" v0.10.1 available - page 7. (Read 59262 times)
May 08, 2012, 02:33:10 PM
May 06, 2012, 04:40:03 AM
I've not tried your fork yet, but does it just ignore the suggested fee or does it tell you about the suggested fee and offer the option of ignoring it?
It just ignores the fee if there is high probability that it won't be necessary.
It is quite safe for everyday usage, if you keep certain rules (eg. not resending money which don't have enough confirmations yet). Sending money which have at least 7 confirmations should be 100% safe, always.
May 05, 2012, 02:54:16 PM
I've not tried your fork yet, but does it just ignore the suggested fee or does it tell you about the suggested fee and offer the option of ignoring it?
May 04, 2012, 07:50:35 PM
It does work as intended. I was just trying to send from a wallet with too little in it. You don't need to test it, but thanks.
Glad i could help.
April 26, 2012, 08:23:20 PM
It does work as intended. I was just trying to send from a wallet with too little in it. You don't need to test it, but thanks.
April 26, 2012, 03:48:21 AM
Edit: Never mind it does work. I was just testing a wallet that only had .00051 in it and it refused to send anything without a fee, but if I used a wallet with more in it then it works.
Ok so I finally successfully built the windows version, but for some reason it is still requiring a fee. I have tried both 5.3.1 and 6.0rc4 and command line version without success. I checked the source I have and it does have your wallet modification. Would there be a reason why it wouldn't let me send fee-less? I am using gitian to build it.
Ok so I finally successfully built the windows version, but for some reason it is still requiring a fee. I have tried both 5.3.1 and 6.0rc4 and command line version without success. I checked the source I have and it does have your wallet modification. Would there be a reason why it wouldn't let me send fee-less? I am using gitian to build it.
Hmmm... this is indeed peculiar.
However, there can be reasons it won't let you send without fee. For example, i believe the algorithm (in my fork and in official client) doesn't allow sending very small amounts, or amounts that does not have enough confirmations.
I have not removed all safeguards against sending money without fee, just some of them.
If you want to make sure it works as it should, you can build 0.3.21 version of the mainline client and compare the functioning of that with NFTF. If it is the same, then it works.
Unfortunately, i dont't have time to test it now, because I am going on holidays. When I am back (about 8 april), I am going to test it thoroughly.
April 25, 2012, 10:09:16 PM
Edit: Never mind it does work. I was just testing a wallet that only had .00051 in it and it refused to send anything without a fee, but if I used a wallet with more in it then it works.
Ok so I finally successfully built the windows version, but for some reason it is still requiring a fee. I have tried both 5.3.1 and 6.0rc4 and command line version without success. I checked the source I have and it does have your wallet modification. Would there be a reason why it wouldn't let me send fee-less? I am using gitian to build it.
Ok so I finally successfully built the windows version, but for some reason it is still requiring a fee. I have tried both 5.3.1 and 6.0rc4 and command line version without success. I checked the source I have and it does have your wallet modification. Would there be a reason why it wouldn't let me send fee-less? I am using gitian to build it.
March 25, 2012, 07:38:59 AM
2012-03-25 Update:
NFTF tags for mainline client versions v0.5.3rc1, v0.5.3rc2, v0.5.3rc3, v0.5.3rc4, v0.5.4rc1, v0.6.0rc2, v0.6.0rc3, v0.6.0rc4 released.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags
Trunk/master has also been fully updated to the latest mainline version.
NFTF tags for mainline client versions v0.5.3rc1, v0.5.3rc2, v0.5.3rc3, v0.5.3rc4, v0.5.4rc1, v0.6.0rc2, v0.6.0rc3, v0.6.0rc4 released.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags
Trunk/master has also been fully updated to the latest mainline version.
March 23, 2012, 09:09:49 AM
I don't know if you have already figured it out or not, but if you want something done in Free Software world, you have to either do it yourself, or make somebody to do it for you.
This is exactly what i did here, because nobody cared that i do not want to pay fees when they are not necessary.
So the best option is probably to start a fork of your own (if you can code), or pay/convince somebody to do it.
Yes, I know. I've worked on open source projects for close to 15 years. But I also know that if you keep an idea to yourself, there is close to zero chance that someone else will implement it if you don't anticipate having time to do it yourself. This is exactly what i did here, because nobody cared that i do not want to pay fees when they are not necessary.
So the best option is probably to start a fork of your own (if you can code), or pay/convince somebody to do it.
March 23, 2012, 02:50:54 AM
I've thought this would be a good idea for a long time. The key problem is that miners don't resolve dependencies like this yet.
I think that's a problem that would fix itself if clients had this feature and people started using it. If you're a miner and are actively seeking fee bearing transactions, you really shouldn't be rejecting fee-less transactions if they are inputs to fee bearing transactions that meet your fee requirements. This situation can occur today, though it's probably quite rare given the behavior of the main client.Regarding my suggestion of a fee that has a high likelihood of making it into the next block, I was thinking of some sort of statistical analysis that could determine a fee that is in the Nth percentile with respect to the time between the transaction appearing on the network and it being included in a block. You could configure the percentile that you wanted your client to suggest (with perhaps the 95th percentile being the default or so). This means that if you applied the suggested fee, you would have a transaction that should be in the 95th percentile of all transactions in terms of the time it takes for that transaction to get included in a block.
In most cases, you either want the transaction to get into a block as fast as possible or you don't care at all how long it takes. So choosing between a 95th percentile fee or no fee at all is likely the only choice most people need.
I don't know if you have already figured it out or not, but if you want something done in Free Software world, you have to either do it yourself, or make somebody to do it for you.
This is exactly what i did here, because nobody cared that i do not want to pay fees when they are not necessary.
So the best option is probably to start a fork of your own (if you can code), or pay/convince somebody to do it.
March 22, 2012, 11:54:29 PM
I've thought this would be a good idea for a long time. The key problem is that miners don't resolve dependencies like this yet.
I think that's a problem that would fix itself if clients had this feature and people started using it. If you're a miner and are actively seeking fee bearing transactions, you really shouldn't be rejecting fee-less transactions if they are inputs to fee bearing transactions that meet your fee requirements. This situation can occur today, though it's probably quite rare given the behavior of the main client.Regarding my suggestion of a fee that has a high likelihood of making it into the next block, I was thinking of some sort of statistical analysis that could determine a fee that is in the Nth percentile with respect to the time between the transaction appearing on the network and it being included in a block. You could configure the percentile that you wanted your client to suggest (with perhaps the 95th percentile being the default or so). This means that if you applied the suggested fee, you would have a transaction that should be in the 95th percentile of all transactions in terms of the time it takes for that transaction to get included in a block.
In most cases, you either want the transaction to get into a block as fast as possible or you don't care at all how long it takes. So choosing between a 95th percentile fee or no fee at all is likely the only choice most people need.
March 22, 2012, 03:42:45 PM
True miners would need to notice that B->C depends on A->B but as subsidies decline and tx fees become more important it is a useful way to move the tx cost to the receiver. Receiver can wait and hope it is included eventually (which maybe the want to do if the payment isn't pressing) or pay a premium fee to get it in the next block.
March 22, 2012, 03:37:59 PM
b) building on an unconfirmed transaction won't make the original transaction happen any sooner. The method suggested will not work anyway, as the coins in the pending transaction can only be re-sent by the recipient, who is not the sender. A Bitcoin modified to allow its users to cancel transmitted transactions (that broke the fee rules anyway) would make a huge double-spend attack vector.
What?
The RECEIVER would build upon the unconfirmed transaction.
i.e. you (being cheap) send me 5 BTC from Address A (owned by you) to Address B (owned by me). No fee was included so the transaction isn't being picked up by miners. I take the unconfirmed B and send it to C (another address owned by me). I include a fee of 0.10 BTC.
A smart miner would see B->C wanting the fees see it is dependent on A->B and include both in the next block. A really awesome "confirmation booster". A solid +1 to Steve. A very nice way around senders paying for tx fees.
Quote
The solution would be to have a special "add-more-fee" transaction you can send, that can only be added to a block that includes the original transaction. The real solution is to not send payments that clients won't relay and miners won't include.
Um that is exactly what he proposed except there is no need for a special tx. Simply a tx with a fee that uses as an input the output of an unconfirmed tx w/ no fee.
March 22, 2012, 03:23:55 PM
b) building on an unconfirmed transaction won't make the original transaction happen any sooner. The method suggested will not work anyway, as the coins in the pending transaction can only be re-sent by the recipient, who is not the sender. A Bitcoin modified to allow its users to cancel transmitted transactions (that broke the fee rules anyway) would make a huge double-spend attack vector.
What?
The RECEIVER would build upon the unconfirmed transaction.
i.e. you (being cheap) send me 5 BTC from Address A (owned by you) to Address B (owned by me). No fee was included so the transaction isn't being picked up by miners. I take the unconfirmed B and send it to C (another address owned by me). I include a fee of 0.10 BTC.
A smart miner would see B->C wanting the fees see it is dependent on A->B and include both in the next block. A really awesome "confirmation booster". A solid +1 to Steve. A very nice way around senders paying for tx fees.
Quote
The solution would be to have a special "add-more-fee" transaction you can send, that can only be added to a block that includes the original transaction. The real solution is to not send payments that clients won't relay and miners won't include.
Um that is exactly what he proposed except there is no need for a special tx. Simply a tx with a fee that uses as an input the output of an unconfirmed tx w/ no fee.
March 22, 2012, 03:17:37 PM
This fork is only a simple patch to maintain the way things previously were, before developers introduced a change that is unfair and unacceptable by my standards.
I'm not aware of any version that didn't force fees...Well yeah - to be precise I am talking about versions that force fee even when there is high probability of it being completely unnecessary.
All versions newer that 0.3.21 do that.
March 22, 2012, 10:01:40 AM
This fork is only a simple patch to maintain the way things previously were, before developers introduced a change that is unfair and unacceptable by my standards.
I'm not aware of any version that didn't force fees... March 22, 2012, 06:38:30 AM
What I would like to see is not only the ability to create transactions without a fee, but also the following:
a) the client to offer a suggestion of a fee that would have a high probability of getting into the next block or two based on some kind of analysis of recent blocks
b) the ability to add a transaction fee to a transaction that you've received and that hasn't yet made it into a block…the client would do this by creating a new transaction with that transaction as an input and sending coins back to yourself (less the desired tx fee)…the client would immediately broadcast this new transaction
a) the client to offer a suggestion of a fee that would have a high probability of getting into the next block or two based on some kind of analysis of recent blocks
b) the ability to add a transaction fee to a transaction that you've received and that hasn't yet made it into a block…the client would do this by creating a new transaction with that transaction as an input and sending coins back to yourself (less the desired tx fee)…the client would immediately broadcast this new transaction
This fork is only a simple patch to maintain the way things previously were, before developers introduced a change that is unfair and unacceptable by my standards.
I have no intention (or required C/C++ skill) of taking it further.
Perhaps somebody else will take up the challenge.
March 21, 2012, 09:27:05 PM
b) the ability to add a transaction fee to a transaction that you've received and that hasn't yet made it into a block…the client would do this by creating a new transaction with that transaction as an input and sending coins back to yourself (less the desired tx fee)…the client would immediately broadcast this new transaction
Steve, that's the best friggin' idea I've read in this forum at least in the last 6 months
And I'm serious!
March 21, 2012, 09:03:12 PM
What I would like to see is not only the ability to create transactions without a fee, but also the following:
a) the client to offer a suggestion of a fee that would have a high probability of getting into the next block or two based on some kind of analysis of recent blocks
b) the ability to add a transaction fee to a transaction that you've received and that hasn't yet made it into a block…the client would do this by creating a new transaction with that transaction as an input and sending coins back to yourself (less the desired tx fee)…the client would immediately broadcast this new transaction
a) the client to offer a suggestion of a fee that would have a high probability of getting into the next block or two based on some kind of analysis of recent blocks
b) the ability to add a transaction fee to a transaction that you've received and that hasn't yet made it into a block…the client would do this by creating a new transaction with that transaction as an input and sending coins back to yourself (less the desired tx fee)…the client would immediately broadcast this new transaction
March 21, 2012, 05:11:34 PM
More updates (other tags, trunk) should follow soon.
Be aware that if you cross-compile, 0.6rc4 will only build securely if you rebuild Qt with the gitian hacks first (or merge #946). Jump to: