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.