Bitcoin Forum

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.

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


https://i.imgur.com/84jmq7O.png
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.

https://i.imgur.com/84jmq7O.png


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

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:

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

----------------
http://forum.bitcoin.org/smf/Themes/custom1/images/post/exclamation.gif http://forum.bitcoin.org/smf/Themes/custom1/images/post/exclamation.gif
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.

http://forum.bitcoin.org/smf/Themes/custom1/images/post/exclamation.gif http://forum.bitcoin.org/smf/Themes/custom1/images/post/exclamation.gif
----------------

2011-09-22 Update:

Today I have merged back the commit (https://github.com/bitcoin/bitcoin/commit/b6d19aefa0cf455dca57ca74eeb75e158a9390d0) 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 (https://github.com/ShadowOfHarbringer/bitcoin-nftf/tree/), 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).

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.

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.

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.

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

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!

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

----
Ah, one more thing.


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 ?

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


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.

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.

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.


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.


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.

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.

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.



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.



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.

More:

----------

You are correct, i will remove the LowTxFee branch.


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.

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.

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 are only two lines of code changed, and the change is very minor... So i **seriously** doubt anything could go wrong currently.


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

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.


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

Those sound like the famous last words of the Debian OpenSSL (http://digitaloffense.net/tools/debian-openssl/) package maintainer.

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.

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.

I wrote a proper Fee verbage and handling overhaul a while ago which allows just this (in the options page).
https://github.com/TheBlueMatt/bitcoin/tree/feefix (https://github.com/TheBlueMatt/bitcoin/tree/feefix) and https://github.com/bitcoin/bitcoin/pull/289 (https://github.com/bitcoin/bitcoin/pull/289) and http://forum.bitcoin.org/index.php?topic=10923.0 (http://forum.bitcoin.org/index.php?topic=10923.0)
sgimenez updated it to Wallet Class at https://github.com/TheBlueMatt/bitcoin/pull/2 (https://github.com/TheBlueMatt/bitcoin/pull/2).
This doesnt have any kind of crazy side effects, and ONLY changes UI, nothing about relaying of backend stuff.

That said, as the patch makes clear, "You may override this option, however it is likely that your transactions will not be relayed through the network and will never be confirmed." so use any such fork at your own risk.

So, developers, what's the solution if...

1. You run an exchange where your clients have accounts in your wallet.
2. A malicious client / competing exchange operator makes many small deposits to his account.
3. The malicious client withdrawals all of his money at once and the huge fee gives his account a negative balance, which eats into your reserves.
4. He opens a new account and repeats the process until you're bankrupt and owe your other users their bitcoins back, which you now don't have.

Will any of these solutions work?
- Patch to pay no fees and only allow withdrawals of bitcoins with > X confirmations.
- Institute some convoluted system that disregards small deposits.
- Patch to estimatetxfee and subtract that from withdrawals before sending them.

Or what?

No— Bitcoincharts won't show any transaction which looks too much like DDOS. For example, it won't show a fee-less transaction with a 1e-8 output.  This is because the node feeding that page imposes the same anti-DOS rules as other nodes and it drops those transactions on the floor the moment they come in. Also because a sufficiently "bad" transactions will seldom make it to that host in the first place.

I've verified this myself.  In fact it wasn't even showing transactions that were perfectly fine under .23 rules, like transactions with <0.01 btc outputs and a 0.0005 fee, because it hadn't been upgraded yet.

Moreover, the reason it contains coins from unconfirmed transactions but not the older unconfirmed transaction itself is probably because the unconfirmed transaction is stuck.  It's perfectly valid to spend unconfirmed coin, you'll just need to be mined at the same time or later.   But you can see how producing transactions that won't ever confirm isn't just bad for you, it's bad for other people because these transactions are like a cancer that spreads when they show up as the only coins in someone's wallet and they get respent.

The likely reason that you haven't had any issues is simply because the cases where fees are forced are fairly rare, especially after you've been running bitcoin with a non-zero balance for a few weeks.  You've likely just not had many cases where a fee would have been demanded by your client in the first place.

Err.  Bitcoins are fungible, it's pretty much never the case that the coins being withdrawn are at all related to the ones deposited.   Once you have a reasonably large balance you'll be cycling out old coins most of the time unless there is a bank run.

So that mostly just leaves the burden of lots of small inputs, but you'll cycle out the small inputs with other transactions in due time without incurring large fees... but if stuffing your wallet with pennies does become problematic you can simply employ a rule of not crediting dust inputs, or imposing a small fee on deposits.   It doesn't have to be "convoluted". if(amount<0.0001)amount=0;

Some sites, like tradehill for example make you specify the exact input size— and impose significant delays on deposits if you get it wrong. You can reject bitdust transactions at this point too, so no one should be surprised by their dust transaction being lost to them.

There has been some talk about tx fee estimation, but because the coin selection algorithm doesn't guarantee the lowest fees and is perturbed by new inputs it's currently hard to asynchronously estimate fees.

What is the minimum deposit size cutoff to be invulnerable to this type of attack? Someone could still dustbin you even with a lot of 1 BTC deposits. They could recycle the same bitcoins over and over.
So now what?
- Use a separate wallet for each user?
- Make a deposit buffer? e.g. Deposits go to one wallet and are sent to the main account wallet in large chunks, minus fees? (Convoluted)
- Join a free transaction relay network?

They could also flood you with HTTP requests sent by a million node botnet.  Whats your point?  There is nothing special about bitcoin here, you're also offtopic for this thread as far as I can tell.

FWIW, bitcoin itself resists big coin bitdusting by making the priority depend on tx_value * input_age / tx_size.  So quickly recirculating a large coin doesn't magically get you past it.

So you're willing to put pre-built binaries out there that let people send transactions that wont pass the spam checks. And said binaries also will not forward transactions that don't pass the spam rules if they see them?

You don't see the problem here?

This is the type of problem that ShadowOfHarbringer is trying to solve. A DDOS doesn't bankrupt you and your clients. The values can be randomized. It doesn't have to be done that quickly. Please don't get confrontational.

lol, look at all the recent blocks. the transaction fees were super low. take off your tinfoil hat, and admit to yourself that your concern is useless. "derp a dev won't respond to me. MUST BE SOME CONSPIRACY GOING ON INVOLVING THE DEVS, THE ILLUMINATI, AND THE 9001 YEAR OLD MINING CREED"

last 3 blocks:
Generation: 50 + 0.80834234 total fees (http://blockexplorer.com/block/000000000000098fa94883339e003c5b9c8beae3e26de42489e0efe1f57ca4a1)
Generation: 50 + 0.30386 total fees (http://blockexplorer.com/block/00000000000004646de1313cbbd6efba44134fbf543a0b76333e180b8e4cebf4)
Generation: 50 + 0.1656 total fees (http://blockexplorer.com/block/00000000000001b270339cef68760c2cd907b6653b9153d53cafab3fdf0dfe0f)

is 0.0005 fee on a transaction is too much? There are better ways of sabotaging the system, like getting a bunch of bitcoins, and deleting the wallet. :D

No he isn't.  It's not a problem that actually exists. You simply charge your clients for the txn fees generated when they are generated. Whats the issue? A DDOS can certainly bankrupt you— it can drive up absolutely astronomic connectivity fees, force you to use commercial mitigation services, and take you offline so that you can't earn the income you need to pay the bills.  Worse, they are hard to stop, compared to simply passing on txn fees to your customers in one form or another where they exist.

I'm not being confrontational, I just didn't follow that you thought this software would be desirable for exchanges simply because no competent exchange is going to run a fork of bitcoin that causes them to get stuck and unspendable outputs in their wallets and makes users wait days or weeks for payments to arrive. Presumably they care enough about the success of bitcoin to not allow this outcome.

If only it was that easy! It also would be a lot easier if fees were a fixed amount per transaction, as grue believes, instead of per KB, but that's not feasible.
The whole problem is that tx fees are added on top of the withdrawal amount. The user's withdrawal transaction proceeds without warning even if the amount+fee is larger than the user's account balance, which depletes your reserves. They just end up with a negative balance. The fees are unpredictable and can be very large - I'm talking 30% as seen in others' posts - when made up of lots of small inputs, even if the inputs are old. You can't charge them the fee if the withdrawal is of their entire balance. Neither can you only allow them to withdraw a small amount at a time because that just compounds the problem.

I didn't say it was 0.0005 for all transactions. I meant that most of the time, it was 0.0005

this could easily be fixed with a simple patch. somehow integrate the GUI function to determine if a fee is needed to a JSON-RPC method.  besides. this is not a very good way to attack a business.

That would be the way to do it. You would have a loop reducing the amount until amount+fee = intended amount. Can it know for sure what the required .0005 BTC/KB fee will be before sending it?

Citation on the 30%? I recall someone here claiming 30% when it was really more like 5% because they failed at math. :)

It takes about .1816 KB per input, if all inputs are 0.01 and you're paying 0.01 per KB (.20 node behavior) you'll have no more than 18.2% fees for large transactions made of many 0.01 inputs. With 0.0005 BTC/KB it's a 0.9% fee for a big transaction made entirely of 0.01 inputs.  Of course, this goes down very fast when the inputs are larger.

Since acounts are just a daemon local bookeeping function and don't control the inputs, I think it wouldn't be reasonable to change someone a txn fee of more than the base fee just because their TXN got an unlucky selection of coins from the shared inputs.  Instead you should just have a constant fee that covers the average and then some.  It's just a simple cost of doing business.

Of course, an RPC could be provided to query the fees for a TXN in advance (if you can tolerate an approximation, since additional inputs will change it), or a the send could get a maximum fee argument and reject with the required fee if you don't authorize enough.

The txn size related fees (which, FWIW, these patches do _nothing_ to) are simply not going away.  The tx_data has a direct cost on the network— every megabyte stored in the blockchain results in something like 40gigabytes transmitted and stored in the bitcoin network. Without fees for large transactions people will have a good reason do do psycho "backup my data into the blockchain" games and other such stuff.

:) So fees are good! As long as they have to pay a minimum fee of 0.0005 BTC / transaction, even if I set up a very poorly rate-limited exchange...

They send	They pay in fees	You send them	You lose reserves with a negative balance
1 x 100 BTC	0.0005 BTC	1 x 100 BTC	1 Input x 0.1816 KB/Input x 0.0005 BTC/KB = 0.0005 BTC
10 x 10 BTC	0.0050 BTC	1 x 100 BTC	10 Inputs x 0.1816 KB/Input x 0.0005 BTC/KB = 0.0009 BTC
100 x 1 BTC	0.0500 BTC	1 x 100 BTC	100 Inputs x 0.1816 KB/Input x 0.0005 BTC/KB = 0.0091 BTC
1000 x 0.1 BC	0.5000 BTC	1 x 100 BTC	1000 Inputs x 0.1816 KB/Input x 0.0005 BTC/KB = 0.0908 BTC
10,000 x 0.01 BTC	5 BTC	1 x 100 BTC	10,000 Inputs x 0.1816 KB/Input x 0.0005 BTC/KB = 0.9080 BTC
100,000 x 0.001 BTC	50 BTC	1 x 100 BTC	100,000 Inputs x 0.1816 KB/Input x 0.0005 BTC/KB = 9.0800 BTC
1,000,000 x 0.0001 BTC	500 BTC	1 x 100 BTC	1,000,000 Inputs x 0.1816 KB/Input x 0.0005 BTC/KB = 90.8000 BTC

So I guess this attacks isn't so bad because it asymmetrically costs them 5x as many bitcoins in fees as it costs you! Although they can still bankrupt you if they are rich and hate you  ;)

Unless i overlooked something in the code, CreateTransaction() is not used for relaying transactions, but for creating them (=sending money) is it ?
So what is the problem exactly ?



Not all of them are "super low".
There is a topic on this forums with a guy which claims that he was forced to pay something around 20% fees for sending 50 BTC of money (I may remember the exact numbers wrong, but you get the idea).

But that is of course talking about the old version having 0.01 fee, not 0.0005.

You are talking about a "naughty boy" who cannot change the code himself.

It will still be easy for all technical types/hackers/people with a lot of money to change the mainline client and send as many spam/dust transactions as they want.


-----------
I added a proper warning in the starting post of this topic.
As of now, this fork is not suited for Bitcoin newbies.

No, a "naughty boy" who can't change the software other people are using. The DDOS protection comes not from the fact that your client won't do it, but from the refusal of most potential neighbors to relay it and miners to miner it. Your client's refusal is your protection from the protection.

Didn't I say like 5 times in this topic that i didn't touch any relaying code, did I ?

This is what I am talking about the entire thread (about the devs not letting me create transaction without a fee), were you actually listening ?

A long-term fix for transaction fees (as opposed to the ad-hoc "we'll just try to guess what the 'right' fees are") is high on my priority list for bitcoin. There are only two very-high-priority things on my bitcoin wish list:  fix scaling issues and make sure we have any infrastructure in place to support ultra-high-security wallets. Fixing transaction fees is a scaling issue.

"Pick a fee and hope my transaction makes it into a block" is NOT the right answer. And we've already seen what happens when there is a mismatch between miner transaction fee policies and client transaction fees (remember the big backlog of low-priority transactions we had a couple of months ago?).

First, thank you for responding at last.
I didn't realize that i will have to make a fork to get your attention.



Of course i realize this is not the proper solution to the problem, this is only a temporary fix.

As i said earlier in this topic, there should be additional dialog saying like "Are you sure you want to do this ? Your coins may get lost forever", which perhaps only shows up when "expert mode" is selected either in bitcoin config or in preferences somewhere in the GUI.

The whole point is, forcing a fee on everybody is so very very, VERY not libertarian. I am a free man, and if i want to risk losing my money, then so be it. That is my choice.

I hate when somebody imposes something on me. I want to be given a choice. Always. Isn't this the whole point of open source ?

So I guess no mainline client developer is going to talk to me seriously about this.

Somehow, I am not surprised.

This has been discussed at length by gavin and others long before this fork.

Yes, but users are, in general, stupid and will do it anyway, and generate a ton of not-even-relayed transactions, then complain that their transactions take forever to confirm.  If you want to help, think through, suggest, take comments on, and implement a new fee system which solves the issue instead of duplicating effort on a patch that has already been done (several times).  Or, if you don't get around to that, just wait, sipa is working on a new solution which could hopefully solve the no-confirm issue, and its probably a 4.1 or 4.2 feature.

Easy. Add expert settings in config file.
So called "stupid" users usually don't know what config file is and how to use it.

Problem solved.


Already done.


Done.


Done.


Can't do.
I can diff, merge, patch, fork, compile, package, change minor things, but I cannot develop things with medium to big complexity on my own as it would be irresponsible & dangerous with my minimal C++ skill.

So I think I did all I could here.

Uh, where? As Gavin pointed out, allowing users to send no-fee transactions which wont even be relayed is not a solution, instead the fee algorithms (which currently arent very good) need to be redone into something more workable.

I am talking about thinking this whole case over, which is already done.
And my conclusion is that experts settings should be added for people who want to risk their money.

The solution is to eliminate the risk. Once 0-confirmation transactions can be reversed easily, the entire transaction fee issue can be basically forgotten about.

Until then, making it very difficult to send low-fee transactions is necessary. There are some types of transactions that will be universally rejected.

Very difficult, but not impossible.

BTW,
Because of Gavin's aggressive responses to my pointing out of an obvious bug I am now more convinced than ever that this is a typical Mining Cartel Scam™.
Not nice.

It isnt impossible, due to patches like the one I wrote quite some time ago and this one, its always been possible its FLOSS.  But its also a free market, that means if miners dont want your transaction, you are going to have to mine yourself, that the developers have no control over...period


Did you even read Gavin's response?
Seems to indicate that he is very interested in fixing the underlying problem instead of hacking up the code to make a branch that doesnt even work. Remember that Gavin is not in charge of any of the miners, and all of the largest miners run modified bitcoin daemons with custom transaction handling anyway.  There is no cartel here, just miners who will accept any transactions with fees and dont care to support transactions that create a larger load on the network as a whole without fees. This is Open-source, no one gets paid to do this, not gavin, not sipa, noone.  If you want a solution to the problem, you need to make one (and again, this is no where near a solution as the transactions it generates dont get relayed or included in blocks, so you might as well just not create the transactions) or wait until someone has time to come up with, and code a solution in their unpaid free time.

How do you know it doesn't work ? Did you even try to compile it ?


Sorry, still not convinced.

----
BTW.

Project update.

- I have merged back all of the current mainline client changes back into the fork.
- Between others, Polish translation was added by somebody into the mainline client
- Small code beauty & compatibility changes in the fork.

Oh, I have no doubt it compiles and runs, but remember transactions it creates oftenalmost always will not be relayed or confirmed.

Lol, ok have fun with that, and people here wonder why people laugh at the bitcoin community at-large.

Sorry, but you have no idea what you are talking about. I find this discussion completely useless & unnecessary.

EOT.

Yes, I have no idea what Im talking about, after having written a more full-featured version of this patch a month ago.  Also, the fact that theymos and Gavin agree with me seems to indicate that you are absolutely right and the entire world is a conspiracy to defraud you of your bitcoins.  I'm sorry I wasted my time trying to explain the actual solution and problem to you.  Can we get this thread locked?

Paranoia will destroy ya.

The fact is, i have been using 0.3.20 all the time now, and no coins were lost.
So i think you are talking jibberish nevertheless.



Nobody is saying anything about conspiracy.
It is just a "common ground" of most prominent miners & developers. They all invested money in mining, so why would they act differently ?

Too bad the side effect is normal users are completely unnecessarily ripped off (for small money but still).


And what would be the reason for that ?
Can't you just stop talking instead ?

0.3.20 is different than this patch in that 0.3.20 doesnt force fees based on the same ruleset as later releases, but does still force fees in some cases.  This patch doesnt ever force fees and can thus often generate transactions which wont relay.

Actually quite the opposite.  All the lead developers aren't miners at all. They are just users of bitcoin like everyone else, and have to pay the same fees to miners like everyone else.

Because you are spreading FUD and making ridiculous claims.

Today I have merged back the commit (https://github.com/bitcoin/bitcoin/commit/b6d19aefa0cf455dca57ca74eeb75e158a9390d0) 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 (https://github.com/ShadowOfHarbringer/bitcoin-nftf/tree/), 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 from mainline client:
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tree/

There it is, will this broke the bitcoin transaction_fee_collection_business ?

Since this is back on the top of the forum— it's time for the regular reminder:

This is a terrible patch that puts you at risk and no one should run it.   The overwhelming majority of transactions with the stock reference client do not pay fees, the average _total_ fees per block are about 0.02 BTC— pointing out the lie that miners give a crap about collecting fees from you— the reference client only adds fees to transactions when it would not mine or relay them had they come from someone else, when they are objectively indistinguishable from a DOS attack.  When it does add fees they are usually only 0.0005 BTC.

Recovering from stuck transactions is a major pain and requires careful editing of the wallet binaries.  When a transaction is stuck it may lock up far more than its value.

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)

It's also the case that no one actively involved and informed in Bitcoin's development is reviewing these patches.  If ShadowOfHarbringer was actually competent do this this work he would not be making misleading claims and would instead be working on code to help users safely recover from stuck transactions.  I would not run code released by him.

Completely untrue, at least it was few months ago (i am not sure if current state is similiar, because i didn't have time to test it lately).
The official client adds fees, even when they are completely unnecessary - meaning they get relayed and confirmed without any fee.

Do some testing before you make claims such as this. I did such tests on my fork with only 2 confirmations (and small sums - like 0.02, 0.10) , and guess what. Fees were NOT necessary. Ever.

Also, there is a proper warning at the start of this topic.


You miss the point.
I want to have freedom to choose whether i want to pay fees that may or may not be necessary.
This is MY FREEDOM, not developer freedom to decide what to do. This is the exact reason i created this simple patch.

Also, as i already stated somewhere in this topic, **this is not a "proper" fork, just a simple 2 line - patch ** for people who value freedom of choice the same as I do.

The **proper** fork/patch should implement a dialog saying "Are you absolutely sure that you do not want to include fee ? Your money may be lost in the process".


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.


Unfortunately, I do not posess enough C/C++ skill (as i already mentioned above), but i do posess the skills to read&understand C/C++ code (to a certain degree) and do pretty advanced git patchwork.
This is all I am doing here, nothing more is really required to maintain a 2-line patch for God's sake.


This is your choice. Because you see: It is all about choice. My choice was to create this fork for myself and other people who value individual freedom and are willing to take some risks to achieve that freedom.

Yes, and they are also seldom added in those cases. Moreover, The amount of the transaction itself isn't whats relevant for the fee calculations (unless it goes under 0.01 BTC).

I'm just stating a simple fact: The bitcoin software uses the _same_ code to determine if fees are required for relay as it does when adding fees to a transaction.  If it decides to add one, it's only if other nodes wouldn't have relayed (much less mined) the transaction without them.

Yes, I'm sure you tested and found it worked fine. I expect that in those cases the unmodified reference software also would not have applied a fee.


And freedom you have, there is nothing I could do to take that away from you even if I wanted to, though I don't.
Your promotion on your signature, "Getting robbed by miners", however isn't just about providing a choice. As far as I can tell it's about spreading misinformation, fear, uncertainty, and doubt.  It reduces choice by clouding people's judgement with the fear that they'll lose money and may cause them to run your fork when under a rational analysis they would not.

Your change is also not a 2 line patch. Diffing your RC tag and the reference client RC tag gives me a 289 line diff.  You appear to be missing at least one random patch from mainline in December. I'm sure this was a simple mistake, but what happens when such a mistake introduces a data corruption bug?

In any case, I didn't post for your benefit, we've gone over this before.  I was just making a regular cautionary post so that people who are just seeing this thread for the first time won't jump to the end and miss the earlier discussion.

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


Well, actually i think you may be at least partially right here.
I will remove the "getting robbed by miners" ad, and replace it with something "lighter".


This is interesting.
Gitk shows that my branch is fully merged with master, except for my little patch.

I will diff it myself now and show you the results in a few minutes.


There is a "cautionary" big, red warning in the first post, shouldn't that be enough ?

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.


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.

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

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.

I'm not quite happy with that, why not eliminate forced transaction fees altogether?

Here's the patch I use:

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:

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.

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 can be IS dangerous (network would not relay such transacactions or other weird errors could happen) so i dumped that idea.


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.

Shadow,

I wanted to follow up on a recent conversation I had with you concerning Armory (https://bitcointalk.org/index.php?topic=56424) 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 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.

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.

This might work, but using NFTF fork would probably be much easier & quickier solution.

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.

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.

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.

i see what you did there

:3

Could everybody please stop derailing this topic ?

I kind of wanted to use it to inform people about releases of NFTF.

https://github.com/bitcoin/bitcoin/pull/570

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.

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.

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 (https://github.com/bitcoin/bitcoin/pull/946)).

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

Steve, that's the best friggin' idea I've read in this forum at least in the last 6 months ;)
And I'm serious!

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.

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.

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.


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.

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.

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. 

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.

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.

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.

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.

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.

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.

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.

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/

Please do not tell people that it is 100% safe. This is not true and the whole concept of thinking users can tell which money they're resending is wrongheaded, the client has free run to pick from whatever inputs it wants in the wallet. I have helped users unstick their wallets several times as a result of this patch.

I've cautioned you about this in the past— and you responded by pointing out that you were direct about the risks and consequences. Now you violate that by claiming that it's 100% safe.

Yes, it's usually not problematic— after all the overwhelming supermajority of transactions do not need to pay a fee in any case. So yes, in any case where a fee wouldn't have been applied this is safe— but also pointless.  In cases where waiting a few hours would have made it no longer need a fee then this is safe enough (at worst you'll need to leave your client running for a few hours before your transaction goes)... but in cases where weeks would be required your funds will end up unusable for a long span of time unless someone helps you effectively hex edit your wallet.

This is a misunderstanding.

I said:


I i wanted to say that I am certain that it is 100% safe, i would say that "IT IS 100% SAFE" or "I AM CERTAIN THAT IT IS 100% SAFE".

If that is not clear enough, i don't know what is.

I just get spammed with errors. Am I missing something?
http://pastebin.com/dpnDMAAj

Try compiling the mainline version and tell me if it produces the same error.

Yes it does :(

So you will be better off asking about this the core developers (Gavin Andresen etc).

But perhaps it is a common error. Try google first.

Will do, thanks

The sender can add fee by re-sending the change.

It wouldn't be a big deal to make transactions always have change. There's usually change anyway.


I agree.

What if there were different tiers of difficulty - if you only include transactions without fees, your difficulty is 'x', if you include transaction fees, it's 'y'. Dedicate one of the 2016 blocks to transactions without fees, so that if someone F's up, they definitely get processed within two weeks. There would be some shifting / weirdness until the difficulty of the 50+fees vs. 50+0 evened out between the two different tactics, but it should eventually police itself such that it's reasonably equally profitable.

If there were a transaction with a lot of single satoshi inputs, and a 0.0005 fee, would it ever confirm?

Haven't tried that yet, you are welcome to be the first :)

I may have to try it soon, i have tens of thousands of single satoshi inputs, if it works i could make a satoshi dice single satoshi cleaning client that only see's single satoshi inputs and inputs the size of the fee (0.0005 would be good) and sends with whatever minimal fee will work

How did you end up with that?

The rule nodes apply is MINFEE per KB, so no a single 0.0005 fee wouldn't help you. A single fee works when creating many tiny outputs.

losses from satoshi dice

Thats what i thought may happen, some of the transactions before i built a modified client where 90+kb with a ~5 bitcent fee to send less than a bitcent, so i would need to figure out how many inputs to each kilobyte and make transactions accordingly, the client i will make if i end up with too many single satoshi's tied up before there is a way to handle them "built in" could still work with the normal fee calculation, but it would be nice if there we're nodes that followed different rules to maybe pay less... for now the satoshi's can sit in scattered wallets (and hopefully making new wallets is a thing of the past...) if it gets to the point that the dust is worth collecting, there will probably already be a solution

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

----
BTW, since i got bored, here is a picture of grandma roaming the skies on a dolphin (which is kind of not related to the topic, but who cares):
http://www.titaniumteddybear.net/wp-content/uploads/2010/07/pic-unrelated-granny-dolphin.jpg

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

I'm confused by this thread. I thought the fee was always voluntary anyway... ?

Nope, it is not voluntary if the mainline client's algorithm decides so.

This is why i created this fork, because i dislike some decisions of the client. If I want to send money without fee and risk losing it (but the risk is very very low), that should be MY decision, not developer's decision.

Why didn't the devs simply make an advanced configuration setting for that is beyond me.

Hi, could you please change "2012-01-27" Update: to 2013 ?

Of course, they try to subtly nudge us to pay miners fee.
Good we have folks like youself, who give people choice :)

The min tx fees are tiny and make up a negligible portion of miners revenue (not to be confused with optional fees on high priority txs).

If a sufficient number of nodes are running code which doesn't enforce the anti-spam rules it would allow an attacker to trivially cripple the Bitcoin network in both bandwidth usage and storage requirements for a token amount of money.  So that is a "good thing" I guess.  Also this fork allows noobs to create transactions which may takes days or weeks to be included in a block leading to all kinds of confusion and frustration.  Worse when that happens the tx will seem to "Disapear" as it can't be seen by the receiver due to other nodes enforcing the rules.

I personally (as a merchant) have experienced the "fun" of this.  A noob with little understanding of Bitcoin saw the "no fees" fork and figured it must be better.  I mean those evil miners trying to force him to pay a fraction of a penny only on massive bloated spammy transactions.  Can't have that right?  He created an order with us and our site gave him a payment address.  He sent coins but of course with no fee nodes between him and us dropped the transaction so our processing node couldn't even see the tx.  Anyways long story short the customer is freaking out, thinking we are scamming him.  He can "see" he sent the coins but we can't see the coins being sent, it isn't getting include in any block.  Try explaining that concept to a noob.  Before the tx is included in a block 16 hours later, the order expires and the price drops massively so when the funds do finally clear we can't honor the price and refund the order.  Of course the uninformed noob thinks this is our fault and we are trying to scam him because the price dropped but we can't honor coins we don't have access to.

So yeah... this is a wonderful fork which will greatly help increase adoption of Bitcoin.

I second that.
The only utility in NFTF fork for me is testing my 0-confirmation payment platform against double-spending attempts.
But again, I guess I always could roll my own build.

EDIT: I take it back, since we have createrawtransaction API, 0-fee transactions can be sent from a regular build. So, no, there is probably no utility in this fork for me :)

Lately I've been having issues getting high priority transactions sent to me confirmed when there's no optional fees paid. It's a pain in the ass when I'm waiting for these coins that I would very much like to bundle with some of my own, slap a fee on, and make a purchase in anything resembling a timely manner.

Ever since the block halving, which is part of a planned process to gradually move from  a subsidy to fee supported mining paradigm, omitting or underpaying fees seems to become increasingly less feasible for any transaction that is the slightest bit time sensitive. As gmaxwell pointed out many times, the people who stand to suffer the most hurt from a no fee client are the people who are new, playing with the idea of bitcoin, and don't have coins of sufficient size or age to be useful if they are sent without fees.

The double spending mitigation done by Satoshidice, even just the parts they talk about, is going to make no fee transactions even more futile in the long run as merchants dealing in low value transaction start to adopt similar measure to mitigate the risk of double spends while still accepting healthy looking (attractive fee containing) transactions.

You are incorrect, my fork does enforce anti-spam rules. This has already been brought up before.

It does not relay invalid transaction without enough fees. The code i changed applies only to sending your own coins, not to relaying any coins.


Done, sorry for the mess.

This "fork" is just a simple patch i made for historical purposes.

I want to remember and always have access to sending 0-fee transactions easily. That is all.

*BUMP*

Anyone got win32 binaries for this?

Also any plans for 0.8.0 version ?

0.8.0 is coming slowly, probably this week.

However i do not use Windows at all and have no interest in it, so you will have to build it yourself.

It builds exactly the same way as mainline version does. Instructions for building mainline version are here:
https://bitcointalk.org/index.php?topic=5851.msg86700#msg86700
http://bitcoin.stackexchange.com/questions/587/how-do-i-build-bitcoin-source-in-windows-7

Can we have a fork where someone is hit by lightning every time they decide to sit in the middle of traffic to express their freedom?

Let me get your point straight: Who should be hit by lightning specifically ?

PS.
Unfortunately that would be a fork of reality, which is not easily done unless you are the creator.

I think he means those people who manifest themselves by occupying roads, bridges, etc., so that would be something like 80% or 90% of the population of my country, where almost everyone done it at least once in life lol

People who occupy to protest are fine. Nothing wrong with resistance. It's the aimless granulated freedom which puts all its money on leaves in the forest vs trees debate.

The leaves want to choose!

I've no issue with enforced fees, but using the standard windows client, doing some testing with bitcoin, have paid more than 5 times the transaction value in fees - somewhat disproportionate - makes it just like a bank ;)

the solution then should be options for both minimum and maximum and broadcast intent to transmit (of course this could blow up and cause people to refuse to mine certain amounts or certain addresses)

Anyone got binaries of this? I was spread them around like hot cakes! This could easily overtake official client that still adheres to broken tx fee system

You've tested a bank's open source software and chosen to attach a fee that ended up going to a peer? Interesting for sure ;-)

I'm not saying we should have NO TX FEE at all. But at the very fucking a least a tx fee proportionate to the input value of the transaction!

after copying C:\boost_1_43_0-mgw\boost to C:\bitcoin-nftf-master\src

you should properly install boost and openssl on your mingw/msys environment.. maybe you want to try this:
http://nuwen.net/mingw.html

and then read this:
https://qt-project.org/wiki/Compiling-OpenSSL-with-MinGW

The cost in storage, bandwith, and CPU is relative to the number of inputs and outputs not the value of the tx.  A fee based as a % of value would provide no DOS protection. 

Ok, but couldn't we get my topic any more derailed ?

dammit! Now 0.8.1 comes out and its a hard fork from 0.7.2 and lower! So this wont even work anymore.

Can you make a 0.8.x No Forced TX Fork ? Running a BitCoin Faucet/PTC site I desperately need this.

I will make a fork, however be wary that now that we may be reaching block limit soon, so the transactions you make may never confirm.

This fork is kind of dangerous until the block size issue is not solved.

block limit for 0.7.2 or ?

Block limit for prior to 0.8/0.8.1... The issue with 0.7.2 is a bit more archane.

I was talking about the fixed 1MB block size.

Once we start getting close to it, low priority transactions (low amounts, multiple small outputs etc) without any fee may never confirm.

I dont mind paying a fee. I just dont want to be paying 300% of the input of my transaction :P A fee absolutely proportionate to the input of my transaction is what I'm aiming for. Running a BTC Faucet like site I tend to have large transactions to many addresses for very small amounts. I've been experimenting trying to get the lowest fees. But I still cant seem to beat just sending them in bulk to about 2000 addresses at a time. Thou sending to 232-314 Addresses seems to be a bit of a sweet spot in terms of transaction size.

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


https://i.imgur.com/84jmq7O.png
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.

https://i.imgur.com/84jmq7O.png

Binaries anyone!?

Building a binary from source isn't some magic limited to developers.

Would be much easier to everyone, if anybody will provide compiled binaries for Windows...  ;D

Well that surely won't be me. I don't use "legacy technologies from twentieth century" as somebody stated on this forums.

Each lawyer will tell you:
All these ARBITRARY and UNFORESEEABLE enforced transaction fees are ILLEGAL.

It cannot be down to miners whim, what at all and even HOW MUCH they want to claim.
A claim of fees must at least clearly be declared before a transaction is definitely mandated by users.

Otherwise there is no agreement.
No agreement, no fee.
And no other chicanry like delays or denial of service (seems also applied - illegally).

Wut ?

Seriously, this topic is not related to what you said and this is not a place for such discussion. Please start a new topic and stop derailing this one.

Miners have the right to choose whom they provide service to or not.

http://www.meh.ro/thumbnail/2010_03/meh.ro3728.jpg

Start a new topic. This is not the right place.

???
The law could not be closer related to what you call/ed "No Forced TX fee", "Freedom", "Getting robbed by miners".

Example
in Block 237507 of what they seem trying to avoid by (illegal) fees.   

FROM
  1GfV8CBz6rhKAzPRVt4jYiJLdghmvWptfR: 0.03297843 BTC
TO   
    141QGt4Jdv6E9LfLZiit7apEMH4oMZyPhr: 0.00001284
    1FKa4kXa9Md1aHhdv69sr4kxax5Lq4h5zd: 0.0000056
    1BigfdEypPZhwJUNzczxpxnQo9zYD6csx9: 0.00001503
    1Fr615TbhJkm7XyUstLZsCw6SvvVnTR54t: 0.00002004
    1FjtGtUKthUeCQCiGk6Lb53oLiQ5TVNEAt: 0.00000084
    1NpFcfEASDb37NKHKVq7BgcLQ4zEfRg5Hw: 0.00002
    19sZFk65dcx5qromyMf2kiB6ZWiY8u4Fad: 0.00000933
    1KnkAj8ZdfwfzbGXBCE6rXeXfPo2e7GkxD: 0.00001244
    1Mz8YUzuQxmHsfzBTbuJWa94d9GgpU2TxZ: 0.000008
    189NhDqUik7xZjmAsyQu6oKenkiZdW8Taj: 0.0000128
    18ZabaHrk9vN4PmeeHdv6aAwiGRQJBe2r5: 0.00000844
    1J3fJNEV44KEsNUAdiezgf8j4JMsjreMSL: 0.0000063
    18nCk22gaDdoYMLSQeWniJzKSjXY9HyGpt: 0.000004
    1BX99EyvTvuppuzCGNbazUSaZY2SseyW6g: 0.0000168
    16GP7fynpDwZ5oJzxoaBgSznPXqffNpNdt: 0.00007593
    12RcTF6ctVP5X8eyUgFjYT2jCH9x5tctB8: 0.000016
    19hQVhYWrfEA556SwUCusPniRbmVP1eGFk: 0.000024
    12u5yY61jKB69kPFNJ5X2oteToqvRmBPac: 0.03084699
    1B3n6VrdEL6wAkazQiJyQURr9MmghBxUEy: 0.00000696
    1LYruivHBrytSpTCc5D5yNyCnjbu44ZTRf: 0.00000928
    1JUHUfAHp5MC4j5AYTDGKqjCgx8aKHwit7: 0.0000124
    17y73HGotoaTqkHTGzPz3FLjxKNqhf4BXH: 0.0000052
    1KpwLakFPPqWWdzZzCBMnFsMvJYRMrNhYr: 0.00001233
    186S2y3KohhntZ3haQoJSFN7Sf9Z5tCkYx: 0.00002
    13PuBaRxigpaGukx7v13Bdv7Vaq8gSiEvn: 0.000012
    1GgMNzdtdVUUdfzL9PyDDudcKTYQaUeS9F: 0.000016
    16JKP7btSgSuUH5tF79AJbBYdcnrtDyNxs: 0.000027
    1FfpPLJjcvqnf4WLsrQCKifyn45bbvmp9j: 0.000008
    1NdkCfxSyHdiVumZGEy28axi2GiWHfuUf4: 0.00000084
    1CM1UJ3Esm4ahkZrLk8fFQZ9wkQSeoCaef: 0.0000044
    1PFeyR5Xu2y9XwFME6437SkfrW9G3RNrkk: 0.00002
    1G74ncDur2aXvdbg99fhKte7BfP9fGeqLJ: 0.0000004
    1DeP5PdKuqv7SsFSezsJtfzRJ2YfFW5zFY: 0.000004
    1DZECBjBY3kPV4PrEzWn5DhExSr21ixT7E: 0.00002
    17nzCMQUsC6sWGDrWNEpiCjeKb33pFEZ5L: 0.0000044
    1JhBeo6ndvHJocEaTy4Ejco358xg9THaQD: 0.0000039
    1AzUHRmX3yLt3Zw3BSSXtQ5yoo1dHDHTGv: 0.0000052
    1MxMu8DoZeVttGBAX4Cg66oU6U4KiaFtVV: 0.0000069
    1CxyTQtVomgAFput7WRQ6Hz2m9AeBz71zD: 0.0000092
    1KT9EbpRYkKs9mxDuq1SQEB6BdoagnkjSp: 0.000016
    15VMbYAbWVYr3RDyX8rVUUjY21ByoL8zqt: 0.000009
    17FBHiYCHzEpCEE8spTbiz4rBAXa8ApNqo: 0.000012
    1NhDUhtUWiKSgFaYNg4XHfnoB36MyPC5gA: 0.000024
    1Ci375gcXKHSQv1gJ4LoeY6g6LzKZvHPXQ: 0.0000006
    1EM8pxA3SjRivyG8JwS11kPhvECtbPxgJU: 0.0000008
    1A4tii76NcMFLPdqNNqMgb8hN9U3QjMu1m: 0.00000003
    15yEbm1Q2jfNJHv1ss2AJjZVZbohpp4ron: 0.00000004
    1L76YBttyLiYPQdTFoASh3MfD2iXvatmLn: 0.000016
    1APYYHeQjCNMtPnPyYAEW7f6BxZCvkGfcs: 0.000004
    1FdcBichMwFx6C3zjWqgC96j6FTeFocj9L: 0.0000123
    1KdqLDhXP7zAS9VMYXicy18z8Mkv8Hddsr: 0.0000164
    1aDKbe5jqCqSdCS2AEstqVUcMLxUjnKyV: 0.0000004
    19H8pB4BFf9SM1ora1warRskDtuyQm6NZf: 0.000006
    18ZWZXUvykZJY8t8gdAqYjvLLqYvNvt5f3: 0.000008
    1HFFFW7LWp9io3vd8BeBbK3zi7vVtiMBNG: 0.00000003
    1LmKT6jpszN8UMbbZYeQkZnqGdmTm2VdrV: 0.00000004
    1FMaqG2VSvzeSgxaLPbP3mwUdPch6UgivU: 0.000004
    13JnZ4mdzUhsSLuYn6HaPzzADUVWQhQS5w: 0.000003
    1BMhZFKJ2r1kp3GLNn8WZ6YougYrRfCziE: 0.000004
    15puRzRCezrM8PcJppiNGyNdyjBXCfgMtw: 0.000004
    19xVTYRoShy1KNPr1EmHHJtCZ4zF8bFwdo: 0.000003
    1FfuFv2X8pUxXmxBZXGN27m38FBKET2f4a: 0.000004
    1FfT8vQDCo6sA2uwh3mn8EjkyVRgy1ZARc: 0.000004
    19pTAoU9EG93PA9hw6CQjhg4iV5GvTUBFu: 0.000003

64 transactions! Overall sum just 0.03297843 BTC!
SIZE 2.333 kB for almost nothing !!
Fee 0.0015   
http://blockexplorer.com/b/237507
http://blockexplorer.com/address/1GfV8CBz6rhKAzPRVt4jYiJLdghmvWptfR

A system taken seriously should not allow (or enforce??) such obvious nonsens at all.

And how is that related to this topic ?
If you haven't noticed, my fork takes LESS fees than the standard client.

Please discuss this in a thread dedicated to the STANDARD Bitcoin-Qt client, not NFTF client.

This topic is for discussion & support for the NFTF client fork.

My attempt at a Windows build:
https://mega.co.nz/#!PoY2WRra!EdDJ-Sx50lnlyMsKcp95dD7xHPgQW5pBys2jG30v29o

This was built using Gitian with sipa's build script on a VMWare Ubuntu VM, running on a Windows 7 host machine. Audits are always welcome.

Can you provide more details? I tryed to compile on a VMWare Ubuntu myself, but got errors :(

This fork builds exactly the same way the normal client does. So just follow instructions on building the mainline client.
https://github.com/bitcoin/bitcoin/blob/master/doc/build-msw.md

sipa's build script: http://bitcoin.sipa.be/builds/bitcoin-build.sh.txt

1. install: https://github.com/devrandom/gitian-builder (install dependencies, then "git clone git://github.com/devrandom/gitian-builder.git")
2. git clone git://ShadowOfHarbringer/bitcoin-nftf/
3. rename folder "bitcoin-nftf" to "bitcoin-build"
4. follow the instructions to set up the gitian virtual machine
5. place dependencies in the input folder of gitian
5. ./bitcoin-build.sh nftf-v0.8.1

How would this work with a sendmany rpc json transaction?

It will work with everything that the mainline client works with.

Well, except paying more fees of course.

Well it dosnt work when i use the debug console. It still is sending the default .0005 fee per 1kb.
Using a sendmany transaction.

does this have atopic location at all? I want to see comments on this style of thread

Wut ?

Also, please stop derailing this thread.

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

https://i.imgur.com/84jmq7O.png

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.
PLEASE MAKE SURE YOU KNOW WHAT YOU ARE DOING BEFORE USING THIS FORK.

Isn't this a configurable option in 0.8.2?  Or do we need your client for your forked chain?

Nope.

- Chain is not forked
- Transaction relaying is unaffected
- Everything except amount of fees when sending **your own money** is unaffected

This is a minor patch, nearly identical to official client.
You can simply send money paying less fees, but with higher risk of transaction not making it into a block (fees might not be enough).

I created this fork, because i didn't like the decision of the devs to raise fees some time ago without giving user any choice (a configuration option for God's sake !).

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

any update to 0.8.5?

Soon. In progress.

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
EDIT: Sorry, mistake. I did not update master this time.

There can be multiple reasons. Like:
- You have received money from a lot of inputs
- The coins do not have enough confirmations

FYI, this fork does not remove fees completely, it only relaxes the fee requirement algorithm. If it does not allow you to send without fee, probably very high risk of losing the coins exists. You can still send them using RAW transactions API, but i wouldn't go for it if I was you.

Also, recheck 3 times if you are using binary built from my code. You may be using other binary.

yep! it works for me for 0.01 BTC without fee but takes for 2 hours approx. for confirmation. But good at all. Thanks for developer!

Yep, it takes longer but it works. That is the exact reason I've built this fork - because i think that the default algo sucks donkey's balls as it requires fee for coins that could be easily sent without.

This worries me. Not because I think there is any chance of loosing coins but because you don't know that there is no chance of loosing coins. Spend transactions are either mined into a block or not. If they are not being mined you can just stop broadcasting that transaction and mining pools will eventually forget about it and you can send those coins with a fee. How exactly is there a risk of "loosing" coins, then?

Ask the core Bitcoin developers. The code which asks you for a fee in that case has not been changed in my fork.

This fork is merely 3 lines of code which turn off a single limitation which forces you to pay a fee even when it is not absolutely necessary. That is not rocket science.

You seem to have misunderstood what I wrote. I just said that there is never a risk of loosing your coins just because you didn't pay enough of a fee. You just remove the transaction using pywallet and wait for the mining pools to forget it. Then you can redo the transaction again with a fee.

This is not what i referred to.
I refrerred to the part of your answer which stated that "it worries you that i don't know that there is no chance of losing coins".

Sure I don't know, because I have not studied the Bitcoin-QT code in detail - I didn't need that in order to create my fork.

Are you sure about that ? Won't some other nodes keep relaying the transaction so it will be forever stuck in a limbo ?
Is there a time limit for how long a transaction can be kept in memory before it becomes obsolete & is removed ?

[Citation needed] Actually i would like to see a citation (or a snippet of code) for that. I don't have time to study the whole code.

I don't have a citation for you. It was asked on this forum and I learned from that. nodes aren't fond of keeping around transactions that can't be mined because the fee is too small. The only reason it sticks around is because -qt keeps broadcasting it over and over again in vain. I can tell you that pywallet supports removing transactions from wallet.dat file for this very reason:

https://bitcointalk.org/index.php?topic=35214.0

What I am worried about is that the relaying nodes (not mining nodes) will keep broadcasting the transaction forever, and thus - it will be stuck in a limbo.

However you should be able to fix such transaction using Raw Transactions API by rebroadcasting it with a (larger) fee.

Somebody with greater knowledge of Bitcoin-QT code should step in here to clarify that.

Transactions without the minimum fee will not be relayed. They will not be stored in the memory pools of miners. They will not be included in blocks. As they are ignored, a proper fee double-spend transaction will be included promptly.

The minimum fee rules have been simplified in 0.8.6, which is the network majority. A fee is no longer required just because any one output is smaller that 0.01 BTC (dust < 5.6mBTC invalid rule takes care of spam), but the minimum fee is now required for any transaction over 1kB in size. This is in addition to the requirement that input priority less than 57.6M (1 BTC, 144 blocks old; 0.01 BTC ~100 days old) include minimum fee.

The network is currently a hybrid of old rules and new rules, and some Bitcoins may also be altered from defaults by network members.

If users are inclined to throw caution to the wind and try this out, please back up your wallet.dat immediately before transmitting a transaction. It is much easier to restore a wallet backup than to repair your wallet to remove the will-never-confirm spent coin transaction.

Well, it would seem i have to retest my fork for these new conditions.
For now, i will keep updating. When majority is already using new rules, i will check if there is a point in continuing my fork.

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

Love your efforts. I stopped using wallets, except for mining, so this is great.

You can't "lose" coins... They either send, or expire.

If your wallet does not see them after they expire, it needs to be "repaired".

However, unless blocks become "full", there should not be any discrimination for "free tx's", ever. That defeats the purpose of the whole network. There is no excuse for discrimination like that. Saying it is for security is like saying you won't allow large transactions, to stop theft. It is not a solution, it is not the purpose of the "transaction processor". Bitcoin is not a business, it is a service. The ones doing the processing should be rejected for blocks, if they fail to "fill a block", when there is ample transactions waiting to fill the block. Free or paid.

If the point comes, at the end of the cycle, when TX-fees MAY be required... Then they should ultimately be enforced. However, difficulty could be zero, so any open wallet could use CPU power for a transaction, and miners would not actually be needed. Why would they do it for free... Because if they want to be able to spend what they earned, they will do it at a cost. Miners are NOT needed for the future of bitcoins and processing.

Fees are already essentially worthless, unless you have a full block full of thousands of $10 fees.

They should have simply made the minimum fee 0.00000001 for all transactions, and then just made bigger blocks as needed. That would have simply solved everything. Well, that and faster block-times.

No, it does not.  That is the original intended design of bitcoin whether you want it to be or not. Bitcoin is a voluntary system.  You are not forced to use it, nodes are not forced to relay, miners are not forced to confirm.


You have a better suggestion on how to prevent denial of service attack?


Mining (transaction processing) IS a business.


There is no way to guarantee that the rest of the network knows about every transaction that your node knows about.  There may not have been "ample transactions" at the time that the block was created, but there may be "ample transactions" by the time your node receives the block.  How will your node know how many transactions existed at the time of block creation?  More transactions may come in after the miner starts mining the block, how would you handle such a situation.  Platitudes will get you nowhere. You need to come up with real solutions to real problems, otherwise all your pontificating is just useless noise.


Without a high enough difficulty, blocks will be created too fast, and there will be a rediculous number of orphaned blocks.  Less than a few hundred confirmations will become meaningless since there will be so many forked chains and orphaned blocks.


Right, just like everyone will pay transaction fees right now to be able to spend what they earned?  You want others to pay for what you want to use now, why would it be any different in the future?


Mining is transaction processing.  If you want transactions processed, then miners (transaction processors) are needed.


Block limit is currently 1 MB.  Given average transaction size, I think we can fit about 4,200 transactions per block.  Are you suggesting that fees are worthless unless you have $42,000 in fees per block?  Maximum block size may increase in the future.  If maximum block size is increased to 10 MB, then bitcoin would be able to fit about 42,000 transactions per block.  Are you suggesting that fees are worthless unless you have $420,000 in fees per block?


I think you are mistaken on that.  Have you even tried the math behind it, or are you just spouting off numbers that you like and assuming that because you like them they must fix all problems?

Hi Shadow,

This is an interesting fork and I'm going to read through the thread in more detail.  I have an interest in forwarding small bitcoin amounts between addresses where low fees are more important than timeliness.

If I understand correctly, there are typically currently more transactions spots available per block than are currently being used, so is there any reason that a transaction with the minimum fees will not get incorporated in to the next block?  I'm not sure why there would be any delay if this is the case, and from blockchain.info, all the blocks appear to be under 1M in size.  Any insight here?

Anyways, please correct me if I'm wrong, but I guess I have to find some way to have a huge number of small, old coins in reserve to both keep the minimum priority for each transaction above 57.6 M and each transaction under 1 kB in order to have the network process a transaction with a 0 fee.

Cheers,

Erik

So wait, this is called "No Forced TX Fee" but it still forces TX fees in some cases? Is there any client that REALLY doesn't force transaction fees?

As far as I know, this forked client doesn't force you to include a fee.  What makes you think that it does?

This:
But maybe I'm misunderstanding, the wording is a little bit confusing.

I hadn't noticed that.

You're right, it is a bit confusing.  Apparently there are still some conditions where the fee is still required by this wallet.  That's probably a good thing, since all peers would just ignore the transaction anyhow, but I suppose it would be better to call this the "reduced conditions for TX fees" wallet.

Actually nowadays fixing a transaction potentially(still, low probability) broken by using my fork is getting easier and easier.

For example, you could probably undo a broken transaction (with not enough fees included) using Bitundo:
http://www.reddit.com/r/Bitcoin/comments/234iem/bitundo_allowing_you_to_undo_bitcoin_transactions/

Of course, you can always do it using raw transaction API, but that's complex.

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

Great idea. I will test this out, just to see how it works.

If BTC reaches really high price lower fees might be crucial when choosing clients.

If Bitcoin becomes REALLY expensive, the developers will have to lower the fees in the core client anyway (or finally create a dynamic fee calculation/voting algorithm).

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

I'm a question : in Windows XP 32 bits SP3 + all available updates ... the v0.9.2.1 crash before 24h of use.
I use bitcoin core only for RPC server and node (-disablewallet).

Can this version have a modification for this (crash) ?
Or only the fees strategy is modified ?

Thanks :)

NFTF fork causing crash ? Well, this is highly unlikely. There is no significant change in the code that could cause the crash.

Please compile the standard client (without the patch) and do a test in *EXACTLY THE SAME CONDITIONS* to find out if it is really the fork causing the crash.

no, no ... your product don't crash (i don't have tested).
it's the official 0.9.2.1 that it crash (0.9.1 work rock stable).

that why i ask "if" your product have found somes bug added corrected with the (added of) modification of the fee strategy.

Nope, unfortunately NFTF is a very minor patch, only changing one small aspect of client's behavior.

Hey Mr. Shadow, you can update your sig now. You are no longer a Hero member. (And I'm on my way there too.)

OMG, I am now a ★LEGENDARY★ member !!

That feels great man !

 ;) thanks for this specific mention.

Bump. Some people might be looking for version 0.9.3.

Yep, coming (this weekend probably).

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

Is work still being done on this fork?

=squeak=

The latest official v10.0.0 makes 0 fee txs easy. I think this was the only difference on this fork?

Yeah, but it doesn't let me set "paytxfee" to 1 satoshi anymore... ended up downgrading back to 0.9.3 official.

=squeak=

I am currently reviewing if it is still necessary to maintain this fork as Bitcoin Core 0.10 has a new, improved fee selection UI.
Perhaps i will request my code being merged into the Bitcoin Core mainline, since now it could be easily done.

Stay tuned.

1 satoshi fees don't really have much of an effect on the entire network. All the nodes will not relay that unless it satisfies some other minimum threshold requirement (like bitcoin days or time.)

I'm aware of that, but at the same time, I don't like sending transactions with no fee whatsoever.

With the setting I had for the 1 satoshi, it was added onto transactions that needed a fee, as well... so if a transaction needed a 0.005 fee, it ended up having a 0.00500001 fee on it.

It isn't necessarily the amount of the fee, but that the new release, enforces the setting to be at a particular value.

If I want to set the fee to X by default, then that's on me, and let the network prioritize it (or not) accordingly when processing transactions.

My choice what fee I want to add, and the consequences of that, comes with the choice I made.

It seems like the core devs, while often claiming otherwise, still want to impose their ideas of what we should do, rather than us choosing for ourselves.

In any event, I've been wanting to write something that would do raw transactions to handle my dust management in my wallet (which is getting pretty bad by now) by always including the oldest 1 or 2 pieces of dust as inputs to another send I'm doing, to make sure that the 1 piece of change I end up with is larger than the dust that was included... 0.10.0 is just going to make me actually do it instead of think about it. :)

=squeak=

edit: the 1-satoshi fee I was mainly using for transactions that were very low priority... when I didn't care if it took a couple/few weeks to confirm. mainly for coin I was sending to cold wallet.

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

Would this fork still be needed if/when the block size changes?

As stated in the first post, probably not.

Also, the fee calculation algorithm drastically changed in 0.10, so it may be needed much less than before. I am going to do some testing Soon™ to check what exactly are the current benefits of using it. If there is very little difference between Core and this then I may stop supporting this patch.

Are there any binary downloads for this?

Nope. And not planned, really.

If you want to compile/build it, check this out:
Ubuntu:
http://bitzuma.com/posts/compile-bitcoin-core-from-source-on-ubuntu/

Windows:
https://bitcointalk.org/index.php?topic=149479.0

My version builds exactly the same way as normal version, so these instructions should work.

EDIT:
Also, because of latest transaction spam attacks, i would advise against using this fork anymore. I am actually updating it because I do not want to forget and lose this code. So kind of for historical reasons.