IRC meeting summary for 2015-12-17
Overview
Logs
Main topics
- 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 comments
The 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
Background
C++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 comments
The 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 conclusion
- Everyone wants C++11 for 0.13
- swtich some builds to C++11
Participants
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
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
Credits
This summary was originally compiled by Stefan Gilis aka “G1lius” and posted to the bitcoin-discuss mailing list with the disclaimer, “Please bear in mind I’m not a developer so some things might be incorrect or plain wrong.” and placed copyright in the Public Domain.