Topic: [UPDATE: 2015-05-10] Bitcoin Core soft-fork "No Forced TX Fee" v0.10.1 available - page 11. (Read 59296 times)

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.

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?

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.

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?

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.

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.

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?

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 and https://github.com/bitcoin/bitcoin/pull/289 and http://forum.bitcoin.org/index.php?topic=10923.0
sgimenez updated it to Wallet Class at 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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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.