IRC meeting summary for 2016-04-07

• Link to this week logs
• Meeting minutes by meetbot

Main topics

• How to proceed with Bitcoin Core wallet
• Dealing with RBF RPC/UI

Short topics

• 0.12.1 Release candidate 1 has been tagged (at time of writing 0.12.1 RC2 has been tagged)
• Update for the median time-past violation check: gmaxwell generated a number of violations of which none got mined. He’s still working on it, as he suspects he needs to relay those transactions harder.
• 20-22 May there’ll be a Bitcoin Core hacking convention in Zurich (Switzerland) http://coredev.tech Core developers who are interested should notify jonasschnelli before April 15.
• Jtimon would like some feedback on an experiment in PR #7829 which is aimed at helping new people to get familiar with git, the review process, etc. and get their first PR merged.

How to proceed with Bitcoin Core wallet

background

Throughout the years the Bitcoin Core wallet has undergone few changes. However many features are requested and needed for long term sustainability of the wallet.
The long term goal is for the wallet to be independent from the core.

meeting comments

Jonasschnelli proposes to extend PR #7830 which clones the current wallet into a second currently experimental wallet which then can be enabled over –enable-lightwallet. This way there is no backwards compatibility needed, so there are less constraints to be taken into account. The new wallet should remove accounts, replace BerkeleyDB with LogDB, add BIP32 and SPV.

Jonasschnelli makes a very rough timing guesstimate: “New wallet without account and without BDB could be in 0.13, stable API in 0.15, … non-beta in 0.16”.

A lot of unit tests for non-wallet features rely on having a wallet. More long term those tests should be less dependent on the wallet.

The new wallet will likely have a completely new interface as well.

meeting conclusion

• Features should mostly end up in the new wallet, the old wallet should still receive bugfixes.
• Jonasschnelli will write a proposal to more clearly document the plan of what he’ll be working on and how people can best support him.

Dealing with RBF RPC/UI

background

BIP125 Opt-in replace-by-fee (RBF) is a new feature since 0.12 which enables wallets to mark transactions as replaceable while they’re still in the mempool. This allows wallets to bump fees, add recipients, etc. There’s a great FAQ post about it on reddit. Currently the Bitcoin Core wallet doesn’t offer any functionality to use these features.

meeting comments

Petertodd: “so, I think what you actually need to do here from an RPC point of view is think in terms of what addresses the user wanted to pay, and whether or not known (confirmed) txs successfully did that - which isn’t really how the wallet works right now”

While adding outputs might be more useful, a first step should be to support fee bump. Petertodd wrote a tool to bump fees in python.

Gmaxwell would like to see a different approach, namely one of “adaptive fee” which pre-creates the bumps with locktimes and queues them. Although better, people would like to start with the simple fee-bump, as the locktime-version will re-use that code. We should be careful with automatic fee bumping, as users need to be aware of it and expect such behavior.

Lowering the change has some privacy implications, however privacy is going to be more expensive and tricky to be succesfull at. Gmaxwell notes: “the main thing to do is to get the estimate right in the first place, though right now change is so thoroughly identifiable you’re closing the barn door after the horse has left. :)”

Fee bumping could be added to the current wallet, more advanced solutions like automatic fee-bumping can be done on the new wallet.

meeting conclusion

• Work on BumpFee

Comic relief

19:14:37 * gmaxwell bangs gavel  
19:14:43 <sipa> who is gavel?  

19:24:40 <petertodd> I was in Zug for a week, and it was so beautiful that a cup of coffee cost $10

19:31:26 <jonasschnelli> petertodd: bumpfee ... yes. maybe we find a call-name that is more flexible for the future?  
19:32:10 <petertodd> jonasschnelli: AbstractRespendWithSomeThingChangedFactoryBean?  
19:32:51 <sipa> jonasschnelli: it shall be called BeeFump

Participants

Disclaimers

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.