IRC meeting summary for 2017-04-20

• Link to this week logs
• Meeting minutes by meetbot

Notes / short topics

• There are no issues reported for RC2, 0.14.1 should be released. (0.14.1 was released 2 days after the meeting)

• There has been some interesting discussion in github related to the wallets handling of address reuse and dust. Anyone interested in that subject might want to check out the discussion on PR #10233 and PRs linked from there.

Main topics

• Fee estimation
• Address reuse
• High priority review

fee estimation

background

In the Bitcoin Core wallet you can choose the amount of blocks in which you would like to see your transaction get confirmed, and the wallet will estimate an appropriate fee-rate based on the fee-rate of the transactions in the nodes mempool. The amount of transactions on the network vary a lot on a daily and weekly basis, which makes this a hard balancing exercise between making sure the transaction gets confirmed in the defined timeframe, and trying to make the user pays the smallest amount of fee.

Morcos has been working on improving the fee-estimation algorithm and, as per request in last weeks meeting, has written a high level description of the new fee estimation algorithm.

meeting comments

Morcos wrote a bunch of improvements in #10199, but there are some open questions he’d like feedback on as well. It would make sense to add another section of the improvements to the higher level description. The fee estimator is complex enough that we should maintain a seperate description of it, maybe even an actual specification like with many major protocol features.

Gmaxwell notes the writeup could use some more details about the reliability estimates and how it merges the buckets. In general a thing to keep in mind, he adds, is that we should try to make it detailed enough that if an academic showed up and wrote a paper based on only the description (which they will) the results will be useful to us.

Morcos also has a plan to decouple the estimator from the mempool that builds off BlueMatt’s CValidationInterface.

Gmaxwell thinks we should try to save more of its state in the future, as example he has nodes that don’t spend more than a few minutes down per month, but don’t make it to the needed two weeks of up-time to make the most accurate fee-estimations.

Jonasschnelli wonders how fast the estimations are available after startup and if it works with a pruned node. Morcos clarifies pruning is irrelevant and for a target of N blocks, it needs at least 2*N blocks to give you an estimate. After that it saves the data so you can restart the node and have instant fee-estimations.

meeting conclusion

• Morcos will add the new changes and clarifications to the gist document.

Address reuse

background

As there was time left in the meeting developers started talking about the address reuse issue and possible solutions.

A privacy issue, which has been actively exploited for a long time, is that people make near-dust payments to addresses once they’ve been spent from, so that you spend from them again in a new transaction, creating a snowball effect that links all your transactions together.

meeting comments

Gmaxwell notes the latest discussion is driven by a user running a gambling site who cares about this, as his customers are getting transactions that link back to him. However this is a privacy concern for everyone.

Gmaxwell’s suggestion for fixing this problem is to create a separate quarantined balance in which any address or specific TXO could be manually quarantined. Then adjust the coin selection algorithm to always spend all payments to a particular address at once. Once an address has been spent from, automatically add it to the quarantined balance.

Wumpus and BlueMatt like the idea, but are not sure about doing this as a default policy. BlueMatt gives an example of a possible issue, where a merchant receives half a payment, spends from that address, receives the other half, but doesn’t realize he got payed, as the funds would be quarantined. Morcos likes the idea of auto-quarantining, but is not sold on the idea of spending all the inputs by default.

Gmaxwell thinks the resource investment is not worth it if the end goal isn’t to do this as default. Wumpus thinks it’s worth it if we think it’s useful to have either way.

meeting conclusion

• As a first step, introduce auto-spending of all funds from a given address in the coin selection algorithm.

High priority review

• PR #10148 (Use non-atomic flushing with block replay) in its current form without multi-head just needs more review, and maybe more tests.
• Luke-jr notes multiwallet is rebased and the nits are fixed. CWalletDB still needs some serious refactoring, but that should be done in a different PR.

Comic relief

jcorgan       clearly this calls for Deep Fee Estimation
gmaxwell      die
jcorgan       tell me what you *really* think
luke-jr       no no, Xtreme Deep Fee Estimation!
gmaxwell      I have a lovely algorithim for an efficient limited memory 2D exponentially weighed moving average somewhere...
sipa          Xthin fees

morcos        ok, so this sounds like general agreement that this is a good idea and has degenerated into arguing about defaults. all development discussion in a nutshell!

Participants

Disclaimer

This summary was compiled without input from any of the participants in the discussion, so any errors are the fault of the summary author and not the discussion participants.