Topic: Bitcoin dev IRC meeting in layman's terms (2015-12-17) (Read 449 times)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms.  
Link to last weeks summarization  

Disclaimer

Please 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 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

[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

 

( °_°)  
( °_°)>⌐■-■  
 (⌐■_■)  
YYYYYYYEEEEEAAAAAAAAAAHHHHHHHHHHHH