[UPDATE: 2015-05-10] Bitcoin Core soft-fork "No Forced TX Fee" v0.10.1 available

[ShadowOfHarbringer]

Warning: Only use this fork if you know what you are doing.
Otherwise, there is a low probability that some coins sent without a fee will be lost stuck in a limbo and difficult to recover.
Read details below.

-------------------



2013-03-24 WARNING !!
PLEASE NOTE THAT UNTIL MAX BLOCK SIZE PROBLEM HAS BEEN SOLVED BY DEVELOPERS, SOME FREE (WITHOUT FEE) TRANSACTIONS CREATED BY THIS FORK MAY CONFIRM VERY SLOWLY OR NEVER.
YOU HAVE BEEN WARNED, THANK YOU FOR YOUR ATTENTION.




-------------------

Okay, here we go.

So as I promised, I created the "NFTF" (short of No Forced TX Fee) section on Github.
This isn't going to be anything big & professional, just few lines of code changed comparing to the standard client.

I did it, because i was unsatisfied with standard client forcing people to pay fees, even when they are not necessary at all.
I wrote many complaints about this on multiple topics on this forum, and for unknown reasons the main developers do not want either to remove this broken algorithm, or to improve it. Mining cartel ? CIA-related conspiracy ? Who knows & Who cares. I don't know and I don't care so I am going my own way.

So here you are.

Full list of branches & tags is avaiable here:

Code:

https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags
https://github.com/ShadowOfHarbringer/bitcoin-nftf/branches

Branches contain code of older versions (from 0.3.21 to 0.3.24).
Tags contain newer versions, 0.4.0 and up.

----------------

Warning: Use this fork with following precautions (the same as if you would use mainline client v0.3.20 version):

- Make sure you get at least 7 confirmations first when resending the money without a fee.
- Sending small amounts (< 0.01) without any fee may be risky.
- Include a fee when sending money received from a lot of inputs.


----------------

2011-09-22 Update:

Today I have merged back the commit from trunk which fixes an unfairly high fees that have to be paid to the miners sometimes due to a bug re-introduced in 0.3.24.

For details see the discussion here:
https://bitcointalk.org/index.php?topic=45259.0

The patch is/will be already present in 0.4x version of official client, but i have also merged it back into 0.3.21, 0.3.22, 0.3.23 and 0.3.24 versions - for people who like to use older and more tested apps.

https://github.com/ShadowOfHarbringer/bitcoin-nftf/commits/nftf-0.3.21
https://github.com/ShadowOfHarbringer/bitcoin-nftf/commits/nftf-0.3.22
https://github.com/ShadowOfHarbringer/bitcoin-nftf/commits/nftf-0.3.23 (that version already contained the patch)
https://github.com/ShadowOfHarbringer/bitcoin-nftf/commits/nftf-0.3.24

If you have used trunk version, it already contained the patch, merged back from official client.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/

Enjoy your no-unnecessary-fee transactions !
As always, wait for at least 7 confirmations before re-sending money so you lower the risk of transaction not being accepted by the network.


----------------
2011-09-24 Update:

NFTF - version 0.4.0 released.

Also:
- Removed all the messy git tags merged previously from the mailine client
- Created new, clean tag for NFTF-0.4.0
- Minor cosmetic changes in comments

So from now on, code will be organized in tags, not versions - as it should be from the beginning.

0.4.0 code is avaiable in the tag:
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tree/nftf-v0.4.0/

And trunk code is avaiable from the trunk, as always. I usually only update it on major version changes or important features/bugfixes, so don't expect me to keep up with mainstream client developers all the time.

Trunk: https://github.com/ShadowOfHarbringer/bitcoin-nftf/tree/

Also, i have performed few tests, sending back and forth small amounts of BTC (0.01) having only 2 confirmations, and it seems that my fork is stable enough for the payments to get confirmed easily (up to 2 hours) without using any fees.


----------------
2011-12-03 Update:

NFTF - version 0.5.0 released.

A fresh tag - nftf-v0.5.0 is avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags

Trunk code was also updated:
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tree/


----------------
2012-01-07 Update:

NFTF - version 0.5.1 released.

A fresh tag - nftf-v0.5.1 is avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags

Trunk code has also been merged back:
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tree/


----------------
2012-02-12 Update:

NFTF - versions 0.5.2 & 0.6.0rc1 released.

NOTE: From now on i will also include release candidate (rc) tags in my fork.

Fresh tags - nftf-v0.5.2, nftf-v0.6.0rc1 are avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags

Trunk code has also been merged back:
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tree/


----------------
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.


----------------
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.


----------------
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/


----------------
2012-08-15 Update:

NFTF - version 0.6.3 released.

Fresh tags - nftf-v0.6.3, nftf-v0.6.2.1 are avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags

Also, I may be making a new repo with Gentoo ebuilds avaiable soon, since I am creating them anyway for my Gentoo.
So stay tuned.


----------------
2012-11-04 Update:

NFTF - versions 0.7.0 & 0.7.1 released.

Fresh tags - nftf-v0.7.0, nftf-v0.7.1 are avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags


----------------
2013-01-27 Update:

NFTF - version 0.7.2 released.

Fresh tag - nftf-v0.7.2 is avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags

MASTER branch was also updated to latest Bitcoin version:
https://github.com/ShadowOfHarbringer/bitcoin-nftf


----------------
2013-03-24 Update:

NFTF - version 0.8.0, 0.8.1 released.

Fresh tags - nftf-v0.8.0, nftf-v0.8.1 are avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags

MASTER branch was also updated to latest Bitcoin version:
https://github.com/ShadowOfHarbringer/bitcoin-nftf


----------------
2013-06-23 Update:

NFTF - version 0.8.2 released.

Fresh tag - nftf-v0.8.2 is avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags


----------------
2013-08-19 Update:

NFTF - version 0.8.3 released.

Fresh tag - nftf-v0.8.3 is avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags

MASTER branch was also updated to latest Bitcoin version:
https://github.com/ShadowOfHarbringer/bitcoin-nftf


----------------
2013-10-07 Update:

NFTF - versions 0.8.4, 0.8.5 released.

Fresh tag - nftf-v0.8.4, nftf-v0.8.5 is avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags

MASTER branch was also updated to latest Bitcoin version:
https://github.com/ShadowOfHarbringer/bitcoin-nftf


----------------
2014-01-26 Update:

NFTF - version 0.8.6 released.

Fresh tag - nftf-v0.8.6 is avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags

MASTER branch was updated to the last tag (0.8.6).


----------------
2014-06-01 Update:

NFTF - versions 0.9.0 & 0.9.1 released.

Fresh tags - nftf-v0.9.0, nftf-v0.9.0 are avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags

MASTER branch was updated to the newest tag (0.9.1).


----------------
2014-08-10 Update:

NFTF - versions 0.9.2 & 0.9.2.1 released.

Fresh tags - nftf-v0.9.2, nftf-v0.9.2.1 are avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags

MASTER branch was updated to the newest version (0.9.2.1).


----------------
2014-10-05 Update:

NFTF - version 0.9.3 released.

Fresh tag - nftf-v0.9.3 is avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags

MASTER branch was updated to the newest version (0.9.3).

----------------
2015-05-10 Update:

NFTF - versions 0.10.0 & 0.10.1 released.

Fresh tags - nftf-v0.10.0, nftf-v0.10.1 are avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags
https://github.com/ShadowOfHarbringer/bitcoin-nftf/archive/nftf-v0.10.1.tar.gz
https://github.com/ShadowOfHarbringer/bitcoin-nftf/archive/nftf-v0.10.0.tar.gz

MASTER branch was updated to the newest tag (0.10.1).

[o]

Welcome for the change. But I think it would be more useful if you can show calculated fee in the send coin dialogue. When the user input the amount, then it should automatically calculate the minimum fee (COIN * 144 / 250) or when the user click the button. The user can freely adjust the fee as they want in the fee input field.

After they click send, it will give them a warning of the consequence of low fee and then asking whether they want to process payment with low fee. It should send out the transaction no mater what fee they enter. It should give a much higher usability improvement.

Many one should be happy for such change so that you may then ask a pull request then.

[joan]

Many one should be happy for such change so that you may then ask a pull request then.

IIRC, fee is the only known mechanism to protect against the "penny flooding" attack.

@OT, Didn't someone point that simply returning true has broader impact that just removing the fee?

[ShadowOfHarbringer]

Many one should be happy for such change so that you may then ask a pull request then.

IIRC, fee is the only known mechanism to protect against the "penny flooding" attack.

@OT, Didn't someone point that simply returning true has broader impact that just removing the fee?

This was default behavior in 0.3.20 and it worked fine for me.
EDIT: Err i checked in the code and actually it wasn't but if you know how to do it better, you are welcome to try.

0.3.21 and later versions has brought me only problems.

I can't even send 10 BTC i received hour earlier, because dialog says it needs a fee.
So i downgrade to 0.3.20 and poof ! Problem fixed. I can resend the money, and later i get 2-3 confirmations after about an hour.

So this is why i said that the algorithm is broken.

[ShadowOfHarbringer]

Welcome for the change. But I think it would be more useful if you can show calculated fee in the send coin dialogue. When the user input the amount, then it should automatically calculate the minimum fee (COIN * 144 / 250) or when the user click the button. The user can freely adjust the fee as they want in the fee input field.

After they click send, it will give them a warning of the consequence of low fee and then asking whether they want to process payment with low fee. It should send out the transaction no mater what fee they enter. It should give a much higher usability improvement.

Yeah, i had the same idea that a while ago, but i was either unnoticed or ignored by main devs.

Also, i cannot create a new dialog box myself, because I am not really a C/C++ programmer (and i don't have a proper C/C++ IDE installed at the moment) so i can only do minor changes & code merges at most.
I programmed several languages in my life and I was thinking many times about learning C, but it always was too time consuming and i never had the time.

But if you know how to implement this, you are welcome to do so yourself.

[Luke-Jr]

Just a friendly reminder that the "Satoshi client" is switching from wxWidgets to Qt4 soon, so it may make sense to wait until that is done before putting effort into new dialogs.

I would personally welcome a fork of the "Satoshi client" with other improvements (such as proper URI support), to shake the monopoly the mainline currently holds.

[ribuck]

Ideally the fee-setting algorithm will eventually become a plugin so that people can safely and conveniently experiment with different fee strategies.

Come to think of it, the coin selection algorithm would also benefit from being pluggable.

But this is a good interim measure. Thanks!

[ShadowOfHarbringer]

@OT, Didn't someone point that simply returning true has broader impact that just removing the fee?

OK, never mind. I fixed this myself in all branches.
AllowFree() returns correct values now.

----
Ah, one more thing.

IIRC, fee is the only known mechanism to protect against the "penny flooding" attack.

Incorrect.

I just looked at the code and it seems that it only protects against people who don't know programming well enough to change it themselves. And hackers & bad guys usually do, or simply pay somebody who knows.
Basically by changing one line of code in the client, you can do whatever you want (and send whatever transactions you want).

So i don't really understand what was the point of forcing everybody to pay the miners additional fees if it wasn't necessary.
Mining cartel of whatever ?

[o]

But if you know how to implement this, you are welcome to do so yourself.

I am good at C++, but not familiarize with the GUI stuff. The use of qt4 will make these thing easier.

So i don't really understand what was the point of forcing everybody to pay the miners additional fees if it wasn't necessary.
Mining cartel of whatever ?

Probably the reason is that there is also some non standard miners program. You change your own client does not affect the other client. It is always up to the miner to decide whether they want to include your transaction or not. The release notes http://forum.bitcoin.org/index.php?topic=16553.0 say that the official "miner" will accept as low as 0.0001 BTC, it is 5 times lower than the value set by normal interface. So you might consider to set it as your transaction fee so that other miner will relay your transaction. You know, most of the client out there are using officail one.

Have you ever take a look of the part of the miner code? I guess they have codes to require fee for frequency transaction.

[ShadowOfHarbringer]

It is always up to the miner to decide whether they want to include your transaction or not.

Yup. You have a point.

But still, most miners accept my transactions even though the mainline client says he doesn't like it.
I get many confirmations pretty quickly.

So perhaps the intent could be sincere (but i highly doubt it), but still, the algorithm is broken. It should be more dynamic, not fixed like this. Bitcoin is very volatile so making algorithms which are based totally on fixed constants is not a good idea.

[gmaxwell]

Okay, here we go.
So as I promised, I created the "NFTF" (short of No Forced TX Fee) section on Github.
This isn't going to be anything big & professional, just few lines of code changed comparing to the standard client.

So, you're also going to be offering your free services to help unstick transactions from people's wallets when they make ones which will _never_ become confirmed?

Because doing that is a pain, and that pain is why the fees are enforced for borderline transactions.  Otherwise people are going to be rightfully mad at you when your software causes them to lose small amounts of bitcoin forever.

Moreover, your claim that most miners will honor these transactions is patently false. It's not hard to find transactions that very few will honor and that almost no node will forward.  For example, send 0.0001 BTC with no fee or 10x reduced fe.

And this one decreases the minumum TX fee requirement by 10 times, making it much less probable that the "Transaction fee is required" monit will appear.

This is silly. The way the dust spam logic treats insufficient fees as non-existent. Simply reducing them by 10x isn't really any better than not paying them at all,  unless you're fortunate enough to manage to connect to eligius (which has a mandatory fee on every transaction but only a very small one). In that case you might as well just apply the eligius fee rules directly.

You've also failed to completely remove the need for fees, but I'm not going to show you what you missed, lest you footgun yourself and others even worse.

Incorrect.

I just looked at the code and it seems that it only protects against people who don't know programming well enough to change it themselves. And hackers & bad guys usually do, or simply pay somebody who knows.
Basically by changing one line of code in the client, you can do whatever you want (and send whatever transactions you want).

So i don't really understand what was the point of forcing everybody to pay the miners additional fees if it wasn't necessary.
Mining cartel of whatever ?

If you don't understand it then it is exceptionally irresponsible of you to modify it and encourage other people to run your modified version. Screw yourself, if you like, but not other people.  I hope other folks here are smart enough to not run code from someone who admits that they don't know what they are doing.

The relay and mining rules of other nodes is the only thing that protect them and the network from penny flooding attack. You can't change those except by convincing them to run software that you've made vulnerable.

The fee rules are there so that a consequence of the relay rules of other nodes you don't end up losing bitcoin because you have a stuck transaction that never confirms.  This isn't hypothetical, it happens to people, and it was in response to this that the minimums were setup for transactions that will very likely have forwarding problems.

The crappiest thing is that your patch will end up screwing people with the least ability to deal with it. Those of us with mature wallets with well aged inputs and enough bitcoin to not be doing bitdust transactions pretty much never run into needing fees, patch or not. Instead the people who will get screwed are newbies who won't even know where to get started in recovering coin lost due to forever non-confirmation.

[jrmithdobbs]

@OT, Didn't someone point that simply returning true has broader impact that just removing the fee?

OK, never mind. I fixed this myself in all branches.
AllowFree() returns correct values now.

----
Ah, one more thing.

IIRC, fee is the only known mechanism to protect against the "penny flooding" attack.

Incorrect.

I just looked at the code and it seems that it only protects against people who don't know programming well enough to change it themselves. And hackers & bad guys usually do, or simply pay somebody who knows.
Basically by changing one line of code in the client, you can do whatever you want (and send whatever transactions you want).

So i don't really understand what was the point of forcing everybody to pay the miners additional fees if it wasn't necessary.
Mining cartel of whatever ?

Wrong. It also prevents relaying them through the reference/satoshi/wtfever you want to call it client. As people (especially miners) upgrade to the newer versions of the code base you're going to start having a lot of difficulty getting these transactions into a block.

And has been stated zillions of times at this point:

You only pay fees if you're trying to spend immature (very recently generated) coins, coins you just received that don't have enough confirmations yet, or if you're combining huge numbers of tiny inputs (aka, you payout itty bitty tiny amounts from your pool or are participating in money laundering-like activities).

Good luck with shooting yourself in the foot by broadcasting txns that will never be included in a block but will prevent you from sending valid txns with the same inputs.

You did not think this through.

[ShadowOfHarbringer]

If you don't understand it then it is exceptionally irresponsible of you to modify it and encourage other people to run your modified version. Screw yourself, if you like, but not other people.  I hope other folks here are smart enough to not run code from someone

Sure i agree it may be little risky, but what you are doing is complaining isntead of trying to help me here. Not very constructive.

I bugged main developers many times that 0.3.21 is broken, and they didn't even comment on it - it's like they intentionally ignore the obviousness of the algorithm being flawed.
So there is something seriously wrong here.

Perhaps, instead of complaining, do something constructive and simply improve the code.

who admits that they don't know what they are doing.

I never said i completely don't know what I am doing. I programmed in many languages in my life and I should be able to make minor changes without doing harm. I understand the code to some point.
If i tried to do something more complex then it would be irresponsible - I agree.  But that is not the case here.

The relay and mining rules of other nodes is the only thing that protect them and the network from penny flooding attack. You can't change those except by convincing them to run software that you've made vulnerable.

Actually, in the latest update i fixed the AllowFree() to be normal and only modified bool CreateTransaction(), so that dust spam relaying code becomes unchanged.

Unless I am wrong, the only thing that is changed now is creating new transactions.

Code:

In CreateTransaction():

Before:
                bool fAllowFree = CTransaction::AllowFree(dPriority);
                int64 nMinFee = wtxNew.GetMinFee(1, fAllowFree);

After:
                //Bitcoin NFTF Patch - changed by ShadowOfHarbringer START
                int64 nMinFee = wtxNew.GetMinFee(1, true);
                //Bitcoin NFTF Patch - changed by ShadowOfHarbringer END

[ShadowOfHarbringer]

More:

----------

This is silly. The way the dust spam logic treats insufficient fees as non-existent. Simply reducing them by 10x isn't really any better than not paying them at all,  unless you're fortunate enough to manage to connect to eligius (which has a mandatory fee on every transaction but only a very small one). In that case you might as well just apply the eligius fee rules directly.

You are correct, i will remove the LowTxFee branch.

You've also failed to completely remove the need for fees, but I'm not going to show you what you missed, lest you footgun yourself and others even worse.

It wasn't my intention to COMPLETELY remove the need of fees.
My intention was to restore default 0.3.20 behavior, which didn't force the fee on me when i tried to send transaction that the client doesn't like.


----------
Also:

I realize my current fork isn't perfect, it only reverts creating transaction to default 0.3.20 behavior.
This of course isn't the best way to do this.

To do this properly, there should be additional dialog saying "Are you sure you want to send the bitcoins without a fee ? Without the transaction fee, it may never get confirmed", and only when the user selects "YES", the transaction should be sent.

The way it is now in the mainline client, everybody is FORCED to pay a fee, and THAT IS JUST PLAIN WRONG.

But as you can see, nobody cares to fix it, so here I am.

[westkybitcoins]

Also:

I realize my current fork isn't perfect, it only reverts creating transaction to default 0.3.20 behavior.
This of course isn't the best way to do this.

To do this properly, there should be additional dialog saying "Are you sure you want to send the bitcoins without a fee ? Without the transaction fee, it may never get confirmed", and only when the user selects "YES", the transaction should be sent.

The way it is now in the mainline client, everybody is FORCED to pay a fee, and THAT IS JUST PLAIN WRONG.

But as you can see, nobody cares to fix it, so here I am.

I've been finding it odd that your concerns were being ignored. Not being able to send 10btc received an hour ago without paying a transaction fee seems a bit harsh. Perhaps the client coin selection algorithm is trying to send other coins instead of the 10btc one. Maybe "one-hour old" is considered immature by the coders (although for an amount like 10btc, I find that a little surprising.) But it seems like the requirements to prevent dust spam need to be relaxed a bit, at the very least... at the worst, there may be some subtle error in the calculation for spam.

But as is often said on these forums... it's open source, you can make any changes you feel you need. And so you have. Personally, I'm curious as to how problematic your changes actually are/aren't. I'd appreciate hearing if you wind up with unconfirmed transactions, how long they stay that way, etc., if you wouldn't mind keeping us up to date on the performance.

[ShadowOfHarbringer]

I've been finding it odd that your concerns were being ignored. Not being able to send 10btc received an hour ago without paying a transaction fee seems a bit harsh. Perhaps the client coin selection algorithm is trying to send other coins instead of the 10btc one. Maybe "one-hour old" is considered immature by the coders (although for an amount like 10btc, I find that a little surprising.) But it seems like the requirements to prevent dust spam need to be relaxed a bit, at the very least... at the worst, there may be some subtle error in the calculation for spam.

Well, whatever are the details of all this, none of the devs seems to care even to talk to me about this.
So i find this extremely suspicious.
I wonder if some (or all) of them didn't invest heavy money in mining. After all, who would want to intentionally decrease their profits ?

But as is often said on these forums... it's open source, you can make any changes you feel you need. And so you have. Personally, I'm curious as to how problematic your changes actually are/aren't.

There are only two lines of code changed, and the change is very minor... So i **seriously** doubt anything could go wrong currently.

I'd appreciate hearing if you wind up with unconfirmed transactions, how long they stay that way, etc., if you wouldn't mind keeping us up to date on the performance.

No problem. I will keep everybody posted if i encounter any problems.

[gmaxwell]

Sure i agree it may be little risky, but what you are doing is complaining isntead of trying to help me here. Not very constructive.

I told you that what you have done will cause users to lose coins. The solution is to simply run stock bitcoind, which changed from the .20 behavior because people were losing coins. I think this is pretty darn constructive.

I bugged main developers many times that 0.3.21 is broken, and they didn't even comment on it - it's like they intentionally ignore the obviousness of the algorithm being flawed.
So there is something seriously wrong here.

Well, you haven't included links so I'm not sure exactly what you were saying—  but the behavior has changed in .23.

[EricJ2190]

There are only two lines of code changed, and the change is very minor... So i **seriously** doubt anything could go wrong currently.

Those sound like the famous last words of the Debian OpenSSL package maintainer.

[Maged]

Well, whatever are the details of all this, none of the devs seems to care even to talk to me about this.
So i find this extremely suspicious.
I wonder if some (or all) of them didn't invest heavy money in mining. After all, who would want to intentionally decrease their profits ?

There's no conspiracy. The reality is, this issue isn't high priority for the next release and is extremely complicated.

There are two main issues:
1) Someone needs to develop some heuristics to guess what fee is needed for a transaction to be confirmed in the timeframe the users requests.
2) We need a way to increase the fee of a transaction after it has been sent.

Until one or both of those are done it is EXTREMELY DANGEROUS to remove the fee requirements. I hope you're prepared to recover all the stuck coins your patch will create.

[ShadowOfHarbringer]

Until one or both of those are done it is EXTREMELY DANGEROUS to remove the fee requirements. I hope you're prepared to recover all the stuck coins your patch will create.

To this day i was using 0.3.20 all the time and guess what: no coins were lost. The patch i created reverts the fee forcing behavior to 0.3.20 and that is all it does.
Also, on http://bitcoincharts.com/bitcoin/ there is only one transaction that is due 20 days, but it contains coins from unconfirmed transactions. Really bad.

So i guess this isn't so extremely dangerous after all, you just need to be a little more careful and only send stuff after you get 7 confirmations or more.