Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms.
Link to last weeks summarization DisclaimerPlease bear in mind I'm not a developer so some things might be incorrect or plain wrong.
There are no decisions being made in these meetings, but since a fair amount of devs are present it's a good representation.
Copyright: Public domain
link to this week logs Meeting minutes by meetbot Main topics discussed where:
Replace-by-fee handling in wallets
C++11 for 0.13
Replace-by-fee (RBF) handling in wallets- background Currently when a node sees a transaction that spends the same output it ignores it. With RBF it replaces the current transaction in the mempool if it has a higher fee.
This allows for things like spending "stuck" transactions, adding more recipients to a transaction in order to prevent chaining, etc.
Since there are people that accept 0-confirmation transactions and this would make it extremely easy to double spend them, this is made opt-in.
The sender can choose to opt-in to RBF by changing the nSequence field of all inputs.
This is a mempool policy for the upcoming 0.12 release.
There's a good
FAQ-ish post on reddit about it.
- meeting commentsThe feature freeze for 0.12 is in effect since December 1, outside of bugfixes, what's in the 0.12 branch now will be released.
#7219 to make RBF policies optional (0 = never, 1 = always, 2 = opt-in) probably won't make it in 0.12.
jonasschnelli and harding request good ideas for RBF wallet policies and ways to handle this.
Android wallet bumps the fee via a click-to-bump UI (via CPFP).
Adding bumping fees is fairly simple, doing more like adding in-and outputs probably hugely complicates the current wallet.
For including in-and outputs you'd want to prepare a signed transaction with A+B and another signed transaction with just B spending from a change output created in A.
For 0.13 we like to see at least a fee bump option and some raw transaction commands to alter a wallet transaction.
- meeting conclusion Take a look at
#7062 Fix mempool limiting and replace-by-fee for PrioritiseTransaction for 0.12
Take a look at
#7132 Add option to opt into full-RBF when sending funds
C++11 for 0.13- BackgroundC++11 is an update of the C++ language. It offers new functionalities, an extended standard library, etc.
Zerocash had to be written with some c++11 libraries and some IBLT simulation code was written in c++11, which they want to recycle for the eventual core commit.
- Meeting commentsThe outstanding build issues are dependencies compatibility and Travis' compiler.
There are concerns about the boost library as it's consensus critical. Removing boost usage (in consensus) before 0.13 removes that concern.
A risk is that we get entrenched in C++11 irreversibly and find out when 0.13 is released a large part of the userbase can't handle it.
Backports are also harder if the code starts to diverge too much.
More testing would be good, but the travis pull tester is already slow, so adding more configurations might not be good.
Possibly a 2nd free alternative to build more configurations in parallel.
Both the zero-cash and bitcoin core team want automated testing of this stuff on many platforms, which can be done by buildbot.
We can also reach out to distros for help.
Wumpus is ready to switch builds to std=c++11 as soon as travis is building/passing.
- Meeting conclusionEveryone wants C++11 for 0.13
swtich some builds to C++11
Participants[nfo]wumpus Wladimir J. van der Laan
cfields Cory Fields
sipa Pieter Wuille
jonasshnelli Jonas Schnelli
petertodd Peter Todd
Luke-Jr Luke Dashjr
nwilcox Nathan Wilcox
zookolaptop Zooko Wilcox-O'Hearn
sdaftuar Suhas Daftuar
harding David A. Harding
jgarzik Jeff Garzik
btcdrak btcdrak[/nfo]
Comic relief 19:03 petertodd wumpus: is the RBFhandling in the v0.12 branch what's going to be released? IE, have we feature frozen?
19:04 wumpus yes, we have feature frozen at dec 1
19:04 petertodd cool
19:04 petertodd or I should say, frozen
( °_°)
( °_°)>⌐■-■
(⌐■_■)
YYYYYYYEEEEEAAAAAAAAAAHHHHHHHHHHHH
