Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Optimize CoinJoin Fees #1457
There are 2 changes here.
Change 1: Multiply by 0.7
As described and implemented in issue #1155 we halvened coinjoin fee target based on the number of unconfirmed coinjoins. In this PR I multiply by 0.7 instead of halvening. This may be somewhat controversial in itself, but I believe change 2 justifies it.
Change 2: Optimize CJ Fee Target
The problem with optimizing CJ fee target when a round is created is that we don't know if there'll be unconfirmed coin registered in the round or not. Thus we need to optimize the fee target at transaction building phase.
Change 2, Note 1
I don't actually send RPC commands for every CJ outputs to check confirmation, rather send one RPC command (
Change 2, Note 2
As I said change 2 also justifies change 1, because change 2 will result in high number of unconfirmed coinjoins those aren't built on each other. So normally the coordinator doesn't know this and would end up suggesting high fees all the time, even though it somewhat optimizes them out with change 2, we should lowball the fees more at the beginning, because change 2 is not an individual fee optimization, but rather a communist fee optimization. It doesn't take account who should pay how much, it splits the diff between the active outputs equally.
Another problem is that the base denomination is going down way too fast, sometimes resulting with overcharging (0.7% would be change sanity limit) and often resulting in toxic change (passes the 0.7% would be change sanity limit.) It'll help slow the rate of base denomination lowering.
@lontivero I implemented what you requested about the configurability. I also figured I can make it even smarter and make sure the optimization happens even when the coinjoin would be spending unconfirmed transactions based on the number of dependants.
Can you make sure to review this commit? 24fda31
I've reviewed it and I the algorithm is okay and makes a lot of sense. However I think you can achieve the same by querying the
I take the opportunity to share here something about the RPC call. What worries me a bit is not number of RPC calls that it could performs but the frequency of those calls because I know the Wasabi backend uses to stress a the bitcoin node from time to time. That is clear by reviewing the only one log file that you shared with me time ago where the node logs a few hundreds of this warnings per day:
That is because by default the bitcoin core rpc work queue can keep 16 work items and sometimes the wasabi backend makes requests faster than the node can process them. The point is that more RPC calls at high frequency could be a problem in the future. Anyway, as the warning says, the limit can be increased (bitcoin core doesn't enforce any upper limit to that value but of course everything has a limit, right?).
I would suggest to increase the
The problem with that is we need the
Then we'd get
I wasn't aware of it. ACK for 64. Adding to the documentation in this PR.