2012-03-21 Update:
NFTF - version 0.5.3.1 [critical security vulnerability hotfix] released.
Fresh tag - nftf-v0.5.3.1 is avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags
More updates (other tags, trunk) should follow soon.
Topic: [UPDATE: 2015-05-10] Bitcoin Core soft-fork "No Forced TX Fee" v0.10.1 available - page 8. (Read 59296 times)
March 21, 2012, 03:55:30 PM
February 27, 2012, 04:49:33 PM
Excellent. I will review the code, and if it is what i expect (and it gets pulled into mainline), then i will be able to stop maintaining this fork.
Force strong is with you, Luke - big thanks.
February 27, 2012, 01:59:26 PM
February 27, 2012, 12:16:18 PM
Could everybody please stop derailing this topic ?
I kind of wanted to use it to inform people about releases of NFTF.
I kind of wanted to use it to inform people about releases of NFTF.
February 27, 2012, 02:25:59 AM
:3
February 26, 2012, 07:11:55 PM
For Sale: Bitcoin Fork
Zwilling J.A. Henckels Premiere Series "Earl Frost" 18/10 Stainless Flatware:
From the makers of the world's finest cutlery since 1731 comes the J. A. Henckels International Flatware Collection. The Earl pattern features a sculpted, contemporary design with a larger, continental size similar to those found in nicer restaurants around the world. All pieces in the collection are made of the highest quality, 18/10 stainless steel. The knives have hollow handles for a better balance and comfortable grip, and finely honed, extra-sharp blades for superior cutting.
Medium Solid Cold Meat Serving Fork:
http://we.lovebitco.in/img/fork1.jpg
http://we.lovebitco.in/img/fork2.jpg
2 BTC, Shipped USA
Complete 5-Piece Hostess Serving Set including fork:
http://ecx.images-amazon.com/images/I/41ASCFDFV4L.jpg
5 BTC Shipped USA
i see what you did there Zwilling J.A. Henckels Premiere Series "Earl Frost" 18/10 Stainless Flatware:
From the makers of the world's finest cutlery since 1731 comes the J. A. Henckels International Flatware Collection. The Earl pattern features a sculpted, contemporary design with a larger, continental size similar to those found in nicer restaurants around the world. All pieces in the collection are made of the highest quality, 18/10 stainless steel. The knives have hollow handles for a better balance and comfortable grip, and finely honed, extra-sharp blades for superior cutting.
Medium Solid Cold Meat Serving Fork:
http://we.lovebitco.in/img/fork1.jpg
http://we.lovebitco.in/img/fork2.jpg
2 BTC, Shipped USA
Complete 5-Piece Hostess Serving Set including fork:
http://ecx.images-amazon.com/images/I/41ASCFDFV4L.jpg
5 BTC Shipped USA
February 26, 2012, 01:49:32 PM
I came here looking for a fork you could buy with bitcoins.
It was in the latest post in technical discussion, and I got excited.
And I get this.
Thanks a lot.
It was in the latest post in technical discussion, and I got excited.
And I get this.
Thanks a lot.
February 26, 2012, 12:50:03 PM
The quickest and easiest solution is probably to change the coin selection algorithm to always select the oldest coin(s) possible for the inputs, thereby not triggering a fee in bitcoind. In most/many cases that will avoid the fee.
btc_artist: this is already part of the SelectCoins algorithm optimization (or at least it is in Armory, I assume Satoshi SelectCoins is similar). But you don't always win when you do that -- you frequently have no way to construct a transaction without doing something that invokes a fee (usually having to combine lots of tiny inputs to make the transaction).
From talking to gmaxwell, it sounded like the dust-output trigger (for sending a tx with any sub-0.01 outputs) is universal. In otherwords, there are plenty of miners that will mine large transactions, or transactions with young inputs, but all nodes impose a fee for dust outputs. Without it, there's nothing stopping people from spamming the network with single Satoshi coins and adding a GB to the blockchain per day.
February 25, 2012, 07:51:51 PM
The quickest and easiest solution is probably to change the coin selection algorithm to always select the oldest coin(s) possible for the inputs, thereby not triggering a fee in bitcoind. In most/many cases that will avoid the fee.
"Most cases" is still not satisfactory for me, hence the fork.
I like my freedom served fresh & juicy on a plate.
When the mainline client gets a proper "are you sure" dialog and/or a configuration setting "Always.AllowNoFees.IKnowWhatIamDoing = 0/1" implemented, this fork will become obsolete. Since then, i will continue maintaining it.
February 25, 2012, 04:49:13 PM
The quickest and easiest solution is probably to change the coin selection algorithm to always select the oldest coin(s) possible for the inputs, thereby not triggering a fee in bitcoind. In most/many cases that will avoid the fee.
February 21, 2012, 03:11:24 PM
You could work around it though. When you have a forced zero-fee tx, instead of just passing the tx to the local bitcoind, send a getaddr message to the local bitcoind, parse the addresses received, then connect to all of those nodes and broadcast the tx to them.
If I understand correctly, you need the local bitcoind for the blockchain, but there's no reason you have to use it exclusively for broadcasting transactions.
If I understand correctly, you need the local bitcoind for the blockchain, but there's no reason you have to use it exclusively for broadcasting transactions.
This might work, but using NFTF fork would probably be much easier & quickier solution.
February 21, 2012, 10:47:43 AM
Shadow,
I wanted to follow up on a recent conversation I had with you concerning Armory and transaction fees.
I made a mistake in my initial assessment of what I could do with it. I have implemented all the tx fee calculations and exactly when they need to be applied. The default behavior of Armory is to let you select 0.0 fee, but if the calculation determines you need more, you either have to increase the fee, or cancel.
I had decided to put in an "Override Minimum Fee" setting that you would have to change by hand, but it could be done. This was all implemented and the dialogs are even created and work. The problem is that since Armory connects through localhost-Satoshi-client, transactions that "need" a fee but don't have them, will not get forwarded. Thus, even though the network is full of nodes that will take zero-fee txs, Armory only has one peer, and the forced-zero-fee transactions are DOA.
It seems, the only way for Armory to do this, is if this fork is used along with the over-ride min fee option (though, I haven't tried it). In the future, I will have some kind of independent networking that will allow me to sidestep this problem. Until then, I can't live up to my promise of supporting forced zero-tx fees!
You could work around it though. When you have a forced zero-fee tx, instead of just passing the tx to the local bitcoind, send a getaddr message to the local bitcoind, parse the addresses received, then connect to all of those nodes and broadcast the tx to them.I wanted to follow up on a recent conversation I had with you concerning Armory and transaction fees.
I made a mistake in my initial assessment of what I could do with it. I have implemented all the tx fee calculations and exactly when they need to be applied. The default behavior of Armory is to let you select 0.0 fee, but if the calculation determines you need more, you either have to increase the fee, or cancel.
I had decided to put in an "Override Minimum Fee" setting that you would have to change by hand, but it could be done. This was all implemented and the dialogs are even created and work. The problem is that since Armory connects through localhost-Satoshi-client, transactions that "need" a fee but don't have them, will not get forwarded. Thus, even though the network is full of nodes that will take zero-fee txs, Armory only has one peer, and the forced-zero-fee transactions are DOA.
It seems, the only way for Armory to do this, is if this fork is used along with the over-ride min fee option (though, I haven't tried it). In the future, I will have some kind of independent networking that will allow me to sidestep this problem. Until then, I can't live up to my promise of supporting forced zero-tx fees!
If I understand correctly, you need the local bitcoind for the blockchain, but there's no reason you have to use it exclusively for broadcasting transactions.
February 20, 2012, 05:34:04 PM
It seems, the only way for Armory to do this, is if this fork is used along with the over-ride min fee option (though, I haven't tried it). In the future, I will have some kind of independent networking that will allow me to sidestep this problem. Until then, I can't live up to my promise of supporting forced zero-tx fees!
I actually made this fork to save "the old way" of doing transactions, so that it will not be forgotten.
You can use my code to implement the override properly, as the only thing it does (2 lines of code changed) is it reverts the client behavior to pre-0.3.23 one.
It should be extremely easy to add an extra configuration switch/parameter/whatever, so you can choose between default Satoshi-client-behavior mode, or NFTF-client-behavior mode when creating a transaction.
I am happy to see that my fork can be actually useful for something important.
February 20, 2012, 12:53:58 AM
Shadow,
I wanted to follow up on a recent conversation I had with you concerning Armory and transaction fees.
I made a mistake in my initial assessment of what I could do with it. I have implemented all the tx fee calculations and exactly when they need to be applied. The default behavior of Armory is to let you select 0.0 fee, but if the calculation determines you need more, you either have to increase the fee, or cancel.
I had decided to put in an "Override Minimum Fee" setting that you would have to change by hand, but it could be done. This was all implemented and the dialogs are even created and work. The problem is that since Armory connects through localhost-Satoshi-client, transactions that "need" a fee but don't have them, will not get forwarded. Thus, even though the network is full of nodes that will take zero-fee txs, Armory only has one peer, and the forced-zero-fee transactions are DOA.
It seems, the only way for Armory to do this, is if this fork is used along with the over-ride min fee option (though, I haven't tried it). In the future, I will have some kind of independent networking that will allow me to sidestep this problem. Until then, I can't live up to my promise of supporting forced zero-tx fees!
I wanted to follow up on a recent conversation I had with you concerning Armory and transaction fees.
I made a mistake in my initial assessment of what I could do with it. I have implemented all the tx fee calculations and exactly when they need to be applied. The default behavior of Armory is to let you select 0.0 fee, but if the calculation determines you need more, you either have to increase the fee, or cancel.
I had decided to put in an "Override Minimum Fee" setting that you would have to change by hand, but it could be done. This was all implemented and the dialogs are even created and work. The problem is that since Armory connects through localhost-Satoshi-client, transactions that "need" a fee but don't have them, will not get forwarded. Thus, even though the network is full of nodes that will take zero-fee txs, Armory only has one peer, and the forced-zero-fee transactions are DOA.
It seems, the only way for Armory to do this, is if this fork is used along with the over-ride min fee option (though, I haven't tried it). In the future, I will have some kind of independent networking that will allow me to sidestep this problem. Until then, I can't live up to my promise of supporting forced zero-tx fees!
February 18, 2012, 07:39:03 PM
These patches also don't do what they claim to do— they'll still apply fees in some cases. (Though at least thats a good thing)
Of course, it wasn't my intention for the patch to remove ALL fees. It only removes the necessity of paying the fee which started around 0.3.23.It reverts the client behavior to the one from 0.3.20.
I'm not quite happy with that, why not eliminate forced transaction fees altogether?
Because some fees are mandatory, and the network rejects transactions without those fees as being spam.
I suspect the transaction you mentioned above won't ever be confirmed.
Yes, exactly.
The only mandatory fees that are not-really-so-mandatory are the ones which were introduced around 0.3.23.
The first conception of my fork was to remove necessity of any fee. But removing other requirements
Code:
(...)
A suggestion - If you want to be really useful, try coding a proper dialog like "Are you sure you really want not to include a fee ? Transaction may never be confirmed !" or/and a configuration setting in the bitcoin.conf file, so that power users/people who know what they are doing can send whatever transaction they want to.
Right now, this fork is not a "proper" solution. With a patch like that, it could become good enough to be pulled into the main bitcoin tree perhaps.
February 18, 2012, 06:29:26 PM
These patches also don't do what they claim to do— they'll still apply fees in some cases. (Though at least thats a good thing)
Of course, it wasn't my intention for the patch to remove ALL fees. It only removes the necessity of paying the fee which started around 0.3.23.It reverts the client behavior to the one from 0.3.20.
I'm not quite happy with that, why not eliminate forced transaction fees altogether?
Because some fees are mandatory, and the network rejects transactions without those fees as being spam.
I suspect the transaction you mentioned above won't ever be confirmed.
February 18, 2012, 08:30:38 AM
These patches also don't do what they claim to do— they'll still apply fees in some cases. (Though at least thats a good thing)
Of course, it wasn't my intention for the patch to remove ALL fees. It only removes the necessity of paying the fee which started around 0.3.23.It reverts the client behavior to the one from 0.3.20.
I'm not quite happy with that, why not eliminate forced transaction fees altogether?
Here's the patch I use:
Code:
--- main.h 2012-02-18 14:00:22.008162091 +0100
+++ main.h 2012-02-18 14:00:22.008162091 +0100
@@ -35,8 +35,8 @@
static const int MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;
static const int64 COIN = 100000000;
static const int64 CENT = 1000000;
-static const int64 MIN_TX_FEE = 50000;
-static const int64 MIN_RELAY_TX_FEE = 10000;
+static const int64 MIN_TX_FEE = 0; // Changed by dani147624
+static const int64 MIN_RELAY_TX_FEE = 0; // Changed by dani147624
static const int64 MAX_MONEY = 21000000 * COIN;
inline bool MoneyRange(int64 nValue) { return (nValue >= 0 && nValue <= MAX_MONEY); }
static const int COINBASE_MATURITY = 100;
@@ -568,6 +568,8 @@
int64 GetMinFee(unsigned int nBlockSize=1, bool fAllowFree=true, enum GetMinFee_mode mode=GMF_BLOCK) const
{
+ // Changes by dani147624: this should now check what the minimum fee would be, and then return 0 anyway.
+
// Base fee is either MIN_TX_FEE or MIN_RELAY_TX_FEE
int64 nBaseFee = (mode == GMF_RELAY) ? MIN_RELAY_TX_FEE : MIN_TX_FEE;
@@ -602,13 +604,14 @@
if (nBlockSize != 1 && nNewBlockSize >= MAX_BLOCK_SIZE_GEN/2)
{
if (nNewBlockSize >= MAX_BLOCK_SIZE_GEN)
- return MAX_MONEY;
+ return 0; // Changed by dani147624
+
nMinFee *= MAX_BLOCK_SIZE_GEN / (MAX_BLOCK_SIZE_GEN - nNewBlockSize);
}
if (!MoneyRange(nMinFee))
nMinFee = MAX_MONEY;
- return nMinFee;
+ return 0; // Changed by dani147624
}
+++ main.h 2012-02-18 14:00:22.008162091 +0100
@@ -35,8 +35,8 @@
static const int MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;
static const int64 COIN = 100000000;
static const int64 CENT = 1000000;
-static const int64 MIN_TX_FEE = 50000;
-static const int64 MIN_RELAY_TX_FEE = 10000;
+static const int64 MIN_TX_FEE = 0; // Changed by dani147624
+static const int64 MIN_RELAY_TX_FEE = 0; // Changed by dani147624
static const int64 MAX_MONEY = 21000000 * COIN;
inline bool MoneyRange(int64 nValue) { return (nValue >= 0 && nValue <= MAX_MONEY); }
static const int COINBASE_MATURITY = 100;
@@ -568,6 +568,8 @@
int64 GetMinFee(unsigned int nBlockSize=1, bool fAllowFree=true, enum GetMinFee_mode mode=GMF_BLOCK) const
{
+ // Changes by dani147624: this should now check what the minimum fee would be, and then return 0 anyway.
+
// Base fee is either MIN_TX_FEE or MIN_RELAY_TX_FEE
int64 nBaseFee = (mode == GMF_RELAY) ? MIN_RELAY_TX_FEE : MIN_TX_FEE;
@@ -602,13 +604,14 @@
if (nBlockSize != 1 && nNewBlockSize >= MAX_BLOCK_SIZE_GEN/2)
{
if (nNewBlockSize >= MAX_BLOCK_SIZE_GEN)
- return MAX_MONEY;
+ return 0; // Changed by dani147624
+
nMinFee *= MAX_BLOCK_SIZE_GEN / (MAX_BLOCK_SIZE_GEN - nNewBlockSize);
}
if (!MoneyRange(nMinFee))
nMinFee = MAX_MONEY;
- return nMinFee;
+ return 0; // Changed by dani147624
}
I'm waiting for a transaction created with this to be confirmed, but have had little luck in the last 2 days. It's input has many transactions (maybe 20-40) of newly generated coins (from p2pool) and it's output has 1 BTC plus some change. I hope it will get included in a block once. (It would take quite some months for me to mine it with my 160 MH/s.) Details of transaction:
Code:
"account" : "",
"address" : "1AaTGqfaGhuqUq8Eaq6dmLsDjEFjtwGkQA",
"category" : "send",
"amount" : -1.00000000,
"fee" : 0.00000000,
"confirmations" : 0,
"txid" : "ded01bdef405f10258d4bb180f79680f83023e8c179d3e165f4a2db268fa34fb",
"time" : 1329412273
"address" : "1AaTGqfaGhuqUq8Eaq6dmLsDjEFjtwGkQA",
"category" : "send",
"amount" : -1.00000000,
"fee" : 0.00000000,
"confirmations" : 0,
"txid" : "ded01bdef405f10258d4bb180f79680f83023e8c179d3e165f4a2db268fa34fb",
"time" : 1329412273
I did manage to get about a thousand 1 satoshi, no fee transactions into the testnet blockchain with it, but I had to mine the block myself.
February 12, 2012, 06:56:22 PM
Ah.
What you're having happen there is that when you send your transaction is dropped by the network— lacking the required fees because it looks like a DOS attack (fast turnaround)—, but after every block that doesn't contain your transaction the client tries retransmitting it (with a random delay). After two hours or so, the input coins have matured enough that they no longer require a fee. After that when your client resends then it goes through.
If you'd just waited the same time it would have sent without a fee in mainline. From a usability perspective, when the times are reasonably short, it might be better to wait like that... but if you shut down right after sending the transaction will be stuck until you start back up and wait an hour or so, and a lot of people do that.
What you're having happen there is that when you send your transaction is dropped by the network— lacking the required fees because it looks like a DOS attack (fast turnaround)—, but after every block that doesn't contain your transaction the client tries retransmitting it (with a random delay). After two hours or so, the input coins have matured enough that they no longer require a fee. After that when your client resends then it goes through.
If you'd just waited the same time it would have sent without a fee in mainline. From a usability perspective, when the times are reasonably short, it might be better to wait like that... but if you shut down right after sending the transaction will be stuck until you start back up and wait an hour or so, and a lot of people do that.
You are absolutely right, however still missing the point.
It is my risk to take and whether i still want to gamble and send the coins should be my decision.
This is why i bugged mainline devs multiple times for a simple configuration setting or a simple "are you sure" dialog, or both.
They are acting like the issue doesn't exist at all. Why is a simple configuration setting such a problem ? Open source is all about choice.
February 12, 2012, 06:51:13 PM
@gmaxwell
OK, seems you were right. Thanks for pointing that out, i could not notice it myself.
Some "weird magic" happened during my git patchwork, and some conflicts didn't merge properly.
The errors were so serious though that the program would probably not compile (at least i hope so). Lucky the changes were only visible for a couple of hours.
Updated & fixed tags are now avaiable, the old ones were removed. Everything is now merged properly, including the trunk.
Also, from now on i will always diff all tags & trunk with mainline client in case of some more merge errors.
OK, seems you were right. Thanks for pointing that out, i could not notice it myself.
Some "weird magic" happened during my git patchwork, and some conflicts didn't merge properly.
The errors were so serious though that the program would probably not compile (at least i hope so). Lucky the changes were only visible for a couple of hours.
Updated & fixed tags are now avaiable, the old ones were removed. Everything is now merged properly, including the trunk.
Also, from now on i will always diff all tags & trunk with mainline client in case of some more merge errors.
February 12, 2012, 05:35:38 PM
Actually, I did a 2-level testing.
First, i tested the "normal" client to check if it adds fees. Then i did an identical transaction with identical sum of money.
And guess what. The mainline client ALWAYS (state as of december 2011) wants a fee when you resend money that are younger than 30 minutes.
My client does not. And the transaction produced by my client got confirmed easily (up to 2 hours).
First, i tested the "normal" client to check if it adds fees. Then i did an identical transaction with identical sum of money.
And guess what. The mainline client ALWAYS (state as of december 2011) wants a fee when you resend money that are younger than 30 minutes.
My client does not. And the transaction produced by my client got confirmed easily (up to 2 hours).
Ah.
What you're having happen there is that when you send your transaction is dropped by the network— lacking the required fees because it looks like a DOS attack (fast turnaround)—, but after every block that doesn't contain your transaction the client tries retransmitting it (with a random delay). After two hours or so, the input coins have matured enough that they no longer require a fee. After that when your client resends then it goes through.
If you'd just waited the same time it would have sent without a fee in mainline. From a usability perspective, when the times are reasonably short, it might be better to wait like that... but if you shut down right after sending the transaction will be stuck until you start back up and wait an hour or so, and a lot of people do that.
I've had transaction queuing on my feature wishlist for a while (mostly for the purpose of automatically grouping transactions into a sendmany). Perhaps that would be a good way to address this.
FWIW, you can do this testing with Testnet too. So you can do a bunch without having to move around a bunch of real bitcoin.
Quote
There is a "cautionary" big, red warning in the first post, shouldn't that be enough ?
I don't know about you, but I usually skip to the end of long threads and don't bother reading much of the start.
Jump to: