implement transaction fees

[GoogleCodeExporter]

Just a reminder issue so it doesn't get lost.

Transaction fees are even an issue on testnet nowaways. Although blocks really 
do not contain many transactions on testnet, many of my non-fee transactions 
are left pending for several blocks.

Original issue reported on code.google.com by andreas....@gmail.com on 8 Jul 2011 at 7:58

[GoogleCodeExporter]

This is really nuts. The Satoshi client throws away non-fee transaction even if 
the recipient is an address in its own wallet!

accepted connection 192.168.1.26:45377
MainFrameRepaint
sending: addr (31 bytes) 
received: verack (0 bytes)
received: getaddr (0 bytes)
received: addr (31 bytes)
received: version (106 bytes)
sending: version (85 bytes) 
Added time data, samples 18, offset -21 (+0 minutes)
sending: verack (0 bytes) 
version message: version 31800, blocks=137082
received: addr (61 bytes)
received: verack (0 bytes)
received: getblocks (101 bytes)
getblocks 137083 to 00000000000000000000 limit 500
sending: inv (73 bytes) 
DelayedRepaint
sending: addr (31 bytes) 
received: tx (405 bytes)
ERROR: AcceptToMemoryPool() : not enough fees

Original comment by andreas....@gmail.com on 19 Jul 2011 at 6:46

[GoogleCodeExporter]

How difficult is it to implement fees? Can we maybe already set up the 
interface, so I can start implementing the GUI?

Since the StackOverflowError seems to be successfully worked around, this is 
the next pressing problem. People can't send their BTC out due to not being 
able to set a fee.

Original comment by andreas....@gmail.com on 19 Jul 2011 at 6:51

[GoogleCodeExporter]

If they wait a while their transactions should be accepted anyway as the coins 
age. I think, anyway. I'd have to read the code again to see what the current 
rules are.

The stack overflow issue has been delayed, not really worked around. I think 
the issue is the chaining of transactions via fromTx and spentBy. It makes one 
of those linked lists the documentation warns about. IMHO that is still the 
next highest priority as it can crater the wallet. If somebody wants to 
implement tx fees, go right ahead.

Original comment by hearn@google.com on 19 Jul 2011 at 7:04

[GoogleCodeExporter]

I'll have a look at this today. From what I can read on the Bitcoin Wiki, fees 
seems very trivial to implement.

Original comment by andreas....@gmail.com on 23 Jul 2011 at 7:56

[GoogleCodeExporter]

I have now implemented tx fees. It was much easier than I thought. This is my 
diff to Wallet.java:

http://code.google.com/p/bitcoin-wallet/source/diff?spec=svn265&r=265&format=sid
e&path=/trunk/src/com/google/bitcoin/core/Wallet.java

I also have released a fee-supporting Testnet client (v1.15) to Android Market, 
for those who'd like to test.

Original comment by andreas....@gmail.com on 23 Jul 2011 at 9:48

[GoogleCodeExporter]

This is fine if you want to always set a specific fee. The Satoshi client 
calculates (and requires) fees based on a formula that takes into account the 
age of the inputs and the size of the transaction. Your patch just forces the 
API user to guess at the fee size, which isn't going to fly - BitCoinJ needs to 
figure it out as it builds the tx and include the fee automatically, possibly 
letting the API user check afterwards the fee isn't too large so it can inform 
the user.

For what you're doing, you could as well just forbid the user from creating 
sends of <0.01 BTC at the UI level.

Original comment by hearn@google.com on 23 Jul 2011 at 8:09

[GoogleCodeExporter]

The problem with fee rules is - if I understand correctly - BitCoinJ would need 
to keep all pending tx and accumlate sizes which it isn't doing right now.

However, sending fees is just the first step and fee rules can follow.

Can you elaborate on why forbidden sends < 0.01 BTC should be equivalent?

Original comment by andreas....@gmail.com on 23 Jul 2011 at 8:37

[GoogleCodeExporter]

How about if we add a FeeHandler to Wallet?  For now we can just let the API 
user implement it . In the future create our own reference implementation that 
matches the Satoshi client.

Adjusting priority to high because this can cause uncomfirmable transactions.

Original comment by mi...@google.com on 14 Oct 2011 at 8:48

• Added labels: Component-Logic, Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I second request #8. Implement a (singleton) ZeroFee FeeHandler to use if none 
other specified. If you don't want to support a FixedFlatFeeHandler(fee), you 
can leave that to application developers if they desire it.

Original comment by ebitc...@gmail.com on 3 Apr 2012 at 3:53

[GoogleCodeExporter]

I've had good luck just doing something simple, like 0.0005 * ((number of 
inputs + number of outputs) / 5)

So I think a FeeHandler would be great.  I was thinking the API would be 
something like:

BigInteger getFeeForTransaction(Transaction tx)

and the completeTx code would have to look something like:

while(collected - to_send - getFeeForTransaction(tx) < 0){ find inputs to add }

This allows for the fee to go up as we add inputs, which is unfortunately going 
to be required.

In other words, adding an input might increase the fee which might require us 
to add more inputs.  You keep going until you have enough for the fee with the 
transaction as is.

Then you put in the change output and hope that doesn't break it.  I guess.

Original comment by fireduck@gmail.com on 4 May 2012 at 6:38

[GoogleCodeExporter]

Any news on this feature and when will it be released?

Also, is it possible to set the fee manually by manually add a new 
TransactionInput of the 0.0005btc just to get my transactions accepted?

Original comment by HenriFri...@gmail.com on 30 Jul 2012 at 1:33

[GoogleCodeExporter]

This might not add any new technical information, but I'd like to document this 
failure case, which seems to lock non-fee transactions (and change).

Overview: Send bitcoins with no transaction fee. If the Satoshi client drops it 
with "not enough fees" then it is likely to never get relayed (not just ignored 
by miners, but never get relayed to miners). The failure case is that BitCoinJ 
never knows that the tx is dead-in-the-water, so the change can never be spent. 

Wallet.getBalance(ESTIMATED) shows the full balance, but 
Wallet.getBalance(AVAILABLE) does not have the change (because it's not 
confirmed).

Dumping transactions from Wallet.getTransactions(..) shows the tx, but 
blockchain.info has no such record (it never got relayed). Connecting to a 
local Satoshi client reveals the "not enough fees" error.

I've even tried connecting specifically to this node (to no avail): 
https://en.bitcoin.it/wiki/Free_transaction_relay_policy

The only fix is to either delete the chain and call Wallet.clearTransactions(0) 
to force full re-scan (is there a faster way?). Or, import the private key into 
another client (eg, Satoshi), where it can re-scan for the live transactions.

This situation is much worse than transactions simply languishing for a while 
before a friendly miner accepts it. Any advice?

Original comment by n.e.baughman on 2 Aug 2012 at 3:23

[GoogleCodeExporter]

By the way, Comment 6 points out what triggered the above failure: Sending a tx 
less than 0.01 btc with no fee. If it's not safe to just hard-wire a fee (when 
tx < 0.01), then I'll just have to prevent such small sends in the UI as 
suggested.

Original comment by n.e.baughman on 2 Aug 2012 at 3:38

[GoogleCodeExporter]

I created a clone (nebaughman-feeschedule) with a framework prototype for fee 
integration with the Wallet class. See the notes therein. The provided 
implementation is not complete, and is really only sufficient for fixed (or no) 
fees.

I'm using the fee implementation for http://vanillawallet.com/ (with 
BitCoinJ-0.5.2).

Original comment by n.e.baughman on 14 Aug 2012 at 4:29

[GoogleCodeExporter]

It appears that the (newer) Wallet.SendResult logic could alleviate much of the 
critical problem I documented above. Specifically, transactions being ignored 
by the network can now be detected via SendResult. I have not yet tested 
whether the wallet recovers its balance state when a transaction does not 
propagate, but at least application logic can be informed of the situation 
(rather than waiting forever for the balance to reconcile from change, etc.).

Original comment by n.e.baughman on 20 Aug 2012 at 1:38

[GoogleCodeExporter]

I implemented fees in my own fork of bitcoinj

so I though why not share it back => it's here 

http://code.google.com/p/bitcoinj/issues/detail?id=245&sort=-id

it seems to work

Original comment by k...@karelbilek.com on 20 Aug 2012 at 2:05

[GoogleCodeExporter]

This issue was closed by revision 572f2a4f4e9c.

Original comment by hearn@google.com on 6 Sep 2012 at 3:45

• Changed state: Fixed