Implement Cohen's method of handling transaction fees

[chris-belcher]

I've been reading this proposal

blog post:
https://medium.com/@bramcohen/how-wallets-can-handle-transaction-fees-ff5d020d14fb#.nqocqse01

talk at scaling bitcoin:
https://youtu.be/iKDC2DpzNbw?t=770

I think it might be a better and cheaper idea for miner fees than the status quo of using estimatefee algorithms. It could be especially useful for tumbler which is much more automated. Also it would work with SPV blockchaininterfaces which don't have a low-trust way of estimating fees.

The idea is to start from a low fee and use replace-by-fee to bump the fee up until it's confirmed or until it gets too expensive, based on the user preference (max fee paid and time preference)

It would probably result in cheaper miner fees because sometimes the low-ball fees will end up being confirmed. I've had times when I get a 2 sat/b transaction confirmed when the fee estimator sites were showing a price 20 times that.

To preserve privacy, the taker would use new destination and change addresses each time. It should connect to the same makers if possible so as to get the same inputs again.

A problem might be that I don't know how the blockchaininterface and yield-generator code handles a transaction that never gets confirmed because it was replaced with a higher fee.

Linking to #120 because this idea could form part of the solution.

[BlinkyStitt]

Since the tumbler is going to be generating many transactions, what if we just set a higher fee on the next transaction and hope miners know how to handle CPFP? That way we don't have to contact makers again.

[chris-belcher]

CPFP could be used yes. It would make the coinjoin transactions end up in the same block so would not be great for timing correlation.

For not having to contact the makers again, I had the idea that all the RBF transactions are made at the same time, and the taker only broadcasts them later slowly.

The only information needed to send to makers would be the index of the change address and the fee values, from that makers could construct all the transactions and send signatures for each one.

[BlinkyStitt]

That's a good idea to avoid contacting the maker multiple times. Think IRC rate limits will get in the way? Maybe we need a more efficient p2p layer.

…

On Mar 5, 2017, at 10:46 AM, chris-belcher ***@***.***> wrote: CPFP could be used yes. It would make the coinjoin transactions end up in the same block so would not be great for timing correlation. For not having to contact the makers again, I had the idea that all the RBF transactions are made at the same time, and the taker only broadcasts them later slowly. The only information needed to send to makers would be the index of the change address and the fee values, from that makers could construct all the transactions and send signatures for each one. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[chris-belcher]

Depends, I think right now requesting the orderbook uses more data. But we could add throttling to slow it down as a temporary measure.

You can reduce the size of signature data by skipping transmitting the pubkey, which would be transmitted many times.

Also note that bitcoin moves quite slowly, average time between blocks is 10 minutes so its okay to take a few more seconds in creating transactions... as long as it doesn't get irritatingly slow.

[chris-belcher]

Evidence of estimate fee algorithms being manipulated: https://www.reddit.com/r/Bitcoin/comments/5yjij6/someone_is_transferring_750_btc_every_5_seconds/

Fee estimation can't possibly work as well as the simple increasing fees approach, because they're using past information instead of current information.

[chris-belcher]

Made this graph because I think it helps when explaining the idea. Those parameters S, B, M define a curve of what fee rate will be used for a given block height since first broadcasting. I'll call it a "fee rate curve".

The red and orange curves have the same starting fee and waiting time, but red is more willing to pay a higher fee. So they're both hopeful to get the cheaper fee rates mined and willing to wait the same time, but red is willing to pay higher if required.

Purple and green have the same ending fee and waiting time, but purple has a higher starting fee. So they're both willing to pay and wait the same in worst case, but green is more hopeful about getting the cheap fee rates mined.

[chris-belcher]

This method has privacy issues when used with coinswap. It reveals the change address because a contemporary observer of the network can see all these unconfirmed transactions with the change output going down in value as the miner fee goes up.

A solution to that is to reduce both the output and change address when increasing the miner fee.

[chris-belcher]

An interesting article about fee estimating algorithms: https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72

I posted a comment at the bottom

[chris-belcher]

Interesting viewpoint from coin_trader_LBC (he owns about a million Bitcoin ATMs so presumably is an expert in sending transactions)

https://www.reddit.com/r/Bitcoin/comments/6jeg3q/bitpay_and_mycelium_incorrectly_estimating_fees/djdntr5/

I think the "fee estimation is bullshit" view goes a bit too far. It could still be useful to choose numbers to plug into Cohen's method.

[chris-belcher]

An interesting thing I've noticed between periods of high demand and low demand is the difference between the estimate for 1 block and 25 block confirm targets. At high demand that difference is small and at low demand the difference is really big. A high value of this difference could be used to start Cohen's algorithm off at a very low estimate.