current situation with transaction fees (???)

[killerstorm]

Wiki (https://en.bitcoin.it/wiki/Transaction_fees) described how version 0.3.20 works, apparently something have changed in 0.3.22:

Client will accept and relay TX's with 0.0005 BTC fee schedule (users still pay 0.01 BTC per kb, until next version)

but I have no idea WTF it means. Where can I find information on how exactly _current_ version works, aside from reading source code?

I'm concerned with this because I'm making a service where people can send coins to their accounts and later withdraw from them (among other things). I definitely do not want to lose my money when user withdraws his, so I'd like to pass transaction fees on users or something like that.

As I understand from a few forum discussions here fees can be pretty much arbitrary and there is no way to tell how much it costs until client makes one and there is no way to limit fees. Is it still relevant for new version?

I see a following potential attack against service owner: customer will send his money to his account slowly, over time, in tiny transactions like 0.01-0.02 BTC. Then when significant sum is accumulated, say, 100 BTC he will withdraw it. I'm lazy to calculate how much it will cost, but I guess easily fee can be larger than 1 BTC.

So at current exchange rate one can easily rob a service owner for $20, which sucks. Then he can repeat this attack until service will have no money left. This would destroy a business because other users won't be able to withdraw.

Maybe I'm a bit paranoid, but if attack described above is possible I'm kinda afraid to run a service which allows withdrawals. It's a horrible bug in software IMHO.

[1713257861]

1713257861

[killerstorm]

Unless there is a way to do it with current software, something like this would work:

1. Pay txn fee from sum sent. E.g. new RPC function sendupto(<address>,<amount>) Let's say amount is 100 BTC. Client estimates that it will incur fee of 0.50 BTC. Then it sends 99.50 BTC and a 0.50 BTC fee. Ideally it should find optimal amount/fee ratio: if sending 99.50 BTC takes only 0.45 BTC in fee it should try sending 99.55 BTC. Then fee goes up to 0.46 BTC and it tries 99.54 BTC and so on. At some point it will converge.

2. Limit/estimate transaction fee. E.g. new RPC function maybesend(<address>,<amount>,<maxfee>). You start by calling it maybesend(<address>, 100.00, 0.0). If it can send 100 BTC without a fee it does this, otherwise it returns estimated fee size: 0.50 BTC. Then  I check whether I can pass 0.50 BTC fee on a customer, if he has >100.50 BTC in his account I call it again like maybesend(<address>, 100, 0.50). If situation hasn't changed since last call and it still costs 0.50 BTC then transaction is sent. Otherwise it returns new value, say, 0.51 BTC and I repeat the process. If customer does not have enough funds I will notify him in GUI with an option to send smaller amount (e.g. 99.50 BTC).

3. Bitcoin client should try to find a way how to send an amount within a certain maximum txn fee window. E.g. if amount is large it should try to use bigger 'coins' to limit size of transaction. If it is not possible it should try to break transaction into small pieces and send them slowly over time. As far as I understand it is always possible as long as amounts I've received are multiples of 0.01 and might be not possible otherwise.

4. If anything unconditional transaction fee limit is better than noting, at least it can be handled manually.

And finally I think fees are too damn high, they should be totally negligible (and, well, they were when BTC exchange rate was lower). But if network needs these fees for whatever reason I'm ok with this as a service-owner as long as I can pass them on users . As a user I'd be very angry being slapped with exorbitant fee     , but what can I do with that...

[killerstorm]

Option 3 looks kinda complicated to implement, it can be replaced with a simple RPC API function, let's say, sendlowfee(address, amount) which will send coins one at a time.

Let's say it was called as sendlowfee(address, 100). Now if we have coin >= 100 BTC it will be sent in full.

If we don't have big sum coin but we have, say, 69.75 one it will send one transaction with 69.75 amount, and this amount will be returned as RPC result.

Now service using bitcoin server should note that there are 30.25 BTC to send and then, say, after 10 minutes it will do sendlowfee(address, 30.25).

As I understand single input, single output transactions can be send for free, so this way you can send any sum for free unless you have money in tiny (<0.01 BTC) coins which cannot be sent without fees.

Optionally it can also include a fixed fee with each small txn.

So options 2 and 3 I've described are easy to implement in bitcoind (as far as I understand) but they require complex handling in applications. They are flexible, though.

With option 1 it is send&forget, but it is not flexible and requires complex implementation in bitcoind.

[Gavin Andresen]

If you're worried about a "fund account with tiny bitcoins" attack, you should charge users that fund accounts with gazillions of tiny transactions an "excess account activity fee."  I've been thinking about writing code for ClearCoin that does that, but at least so far it doesn't make sense for me to spend time doing that.

And see:  https://github.com/bitcoin/bitcoin/pull/285   for the current thinking on how to handle fees at sending time.

[killerstorm]

There is a simple way to make sure that txn fees are passed on users: check for fund availability in sendfrom should include transaction fee. (I.e. forbid negative account balances.)
I guess it is not made this way for convenience reasons: this way sendfrom can just use SendMoneyToBitcoinAddress function.
But it isn't hard to rewrite it a bit to use CreateTransaction instead and do a check before committing, right?

estimatetxfee might be useful, but it doesn't solve anything because it provides no guarantees.

BTW now reading the code I see that it is possible to write a send-transaction function which would cram as much as possible into a free (or minimal-fee) transaction. Is anybody interested in this?

[adaman]

My programming skills are more than low so i did not read the code. But as far as i understand the fee is an reward and an motivation for users to calculate hashes to keep the network up. And the amount of the fee is calculated by the transactions/calculation power needed for this singel transaction. Is this correct ?

Maybe i am already completely wrong at this point.

But does it make sense to let each user who is running the client and keep calculating hashes decide how much fee he will get for an transaction managed from his client?

On the other hand users who want to start an transaction can enter maximum fee value what they want to accept for an transaction.

So maybe an self-regulating system will grow automatically. If someone setup to high fee´s in his client the "customer" will refuse it and switch to someone with lower fee. It is like an stock exchange, the market decides what is an reasonable fee.

But there is still a little risk that all transactions are forwarded to just some clients with really low fee's. But if you pay less or nothing you get low performance. I could live with low transaction times. Other people would maybe spend more for faster transaction.

But as i already mentioned maybe i completelly missed the point ...   

[killerstorm]

My programming skills are more than low so i did not read the code. But as far as i understand the fee is an reward and an motivation for users to calculate hashes to keep the network up.

Currently fees are used mostly to discourage 'spam' transactions which could flood the network. They are negligible compared to number of bitcoins mined.

For example, here is one of larger blocks: http://blockexplorer.com/block/00000000000010636a97e1aa823a6b2d60b5a964f087448857190093e014a5d5
Block 12931 has 99.155 kilobytes and it got 0.581 in fee (compared to 50 BTC generated).

Let's compare it to a smaller block: http://blockexplorer.com/block/0000000000000035d573e3a205d166de752a540dd30d59477d3526ec30d9006a
Size: 15.5 kilobytes
0.2 total fees

And the amount of the fee is calculated by the transactions/calculation power needed for this single transaction. Is this correct ?

As block size goes larger fees required by miner go large as well, so at some point if there are too many transactions they won't get into a current block (but they can go into a next one). So fees received by miner can be roughly proportional to block size, and so amount of computations needed to verify it.

But I think computational power required for verifications is negligible compared to computational power spent on mining.

A quick estimation: there would be like 4000 small transactions in 1 MB-large block. Let's say 3 msecs is spent on one verification (number from wiki). This means that one CPU core would verify the whole block in 15 seconds.

But it would take many _years_ for one CPU core to solve proof-of-work challenge. So it doesn't matter much until we'll get much larger blocks.

(It is not as simple because verification also requires IO operations, but you get the idea... At least with current block sizes like ~100 KB top it doesn't matter.)

But even if amount of CPU time required for verification is tiny miners could skip it altogether for whatever reasons. So fees, whatever tiny they are, still encourage miners to run official client but not something else.

On the other hand users who want to start an transaction can enter maximum fee value what they want to accept for an transaction.

The way it works now: client assigns a fixed fee. Miner sorts transactions by priority and goes through the list, verifying whether they have enough fees. (As block gets larger fees get more expensive.) If transaction is not accepted into block it might be accepted in some other block mined by another miner. So if you pay no fees or fees too small it would take more time until you'll get a confirmation.

So maybe an self-regulating system will grow automatically.

Definitely it will, when there will be larger number of transactions it would make sense to make fees configurable.

In a limited way it is now -- if you want your txn to be included into a larger block you might need to configure higher fee in your client (there is an RPC call for it now).

There is also a miner who accepts lower than default transaction fees and also non-standard transactions:
https://en.bitcoin.it/wiki/Free_transaction_relay_policy

[mai77]

Currently fees are used mostly to discourage 'spam' transactions which could flood the network. They are negligible compared to number of bitcoins mined.

your knocking down the straw man.
fees are clearly not negligible compared to many tranfer sums, which is what counts.

a 0.0005 btc fee is a bloody rip-off. that's 3 €cent and counting ... for a 200 byte transfer. that is immoral.

[🏰 TradeFortress 🏰]

There is a simple way to make sure that txn fees are passed on users: check for fund availability in sendfrom should include transaction fee. (I.e. forbid negative account balances.)

Not a straightforward change - after checking the account has enough balance, it just calls

Code:

pwalletMain->SendMoneyToDestination(address.Get(), nAmount, wtx);

which calculates the fee and pushes the TX.

[killerstorm]

Currently fees are used mostly to discourage 'spam' transactions which could flood the network. They are negligible compared to number of bitcoins mined.

your knocking down the straw man.

Are you retarded? You comment on two year old thread, completely miss the point, and claim it was a straw man.

I was talking about significance of transaction fees for miners. Not about costs of fees to users. THIS IS what we were talking about, not what you imagined. Read what I was replying to.

Fucking retard. Do you even understand what "straw man" means? It doesn't mean "people are talking about things I do not understand".

fees are clearly not negligible compared to many tranfer sums, which is what counts.

Yes.

a 0.0005 btc fee is a bloody rip-off. that's 3 €cent and counting ... for a 200 byte transfer. that is immoral.

You do not understand how it works, do you?

It isn't just a data transfer, these 200 bytes will be stored FOREVER on thousands of systems. (And it will be transferred millions of times... So we are talking about gigabytes of transfer.)

Absolutely nothing immoral about it... If anything, it is too cheap.

Yes, Bitcoin is not suitable for microtransactions. If you think there is a need for microtransactions, try to design a system which works better.

[DannyHamilton]

You comment on two year old thread, completely miss the point, and claim it was a straw man.

Wow, I completely missed that mai77 was responding to a 2 year old thread.  That's ridiculous in the context of his complaint.  Had I seen that I never would have bothered responding to him, and would have just put him on "ignore" instead.

Deleting my response and adding mai77 to my ignore list now.  Thanks for pointing out what I failed to notice.