Topic: Bitcoin dev IRC meeting in layman's terms (2016-01-21) (Read 406 times)

Thanks, this is nice. Unfortunately, no one here actually wants to know and understand the real issues. They'd rather pretend to know what's happening and then just make shit up.

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

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

## Logs

- link to this week logs 
- Meeting minutes by meetbot

## Main topics

- 0.11 backport release for chainstate obfuscation 
- C++11 update 
- EOL Policy / release cycles

## Short topics

- Recently a configuration option "-permitrbf" has been merged, which allows nodes to choose whether to replace opt-in RBF transactions or not.
Some discussion ensued to change the default behavior of 0.12.0 and set it to false. As most participants voiced their opinion on the relevant pull-requests (#7386 & #7388) this wasn't discussed further in the meeting.

- There are some issues being filed concerning database corruptions in bitcoin core. Although the problem hasn't been pinpointed to LevelDB, the long-term plan is still to switch to a new, well maintained database.

## 0.11 backport release for chainstate obfuscation

background
As some windows users might have experienced in the past, anti-virus software regularly detects values in the bitcoin database files which are false-positives. Thereby deleting those files and corrupting the database. 
To prevent this from happening developers discussed a way to obfuscate the database files and implemented it last year. 
While downgrading after upgrading is possible, if you start from a new 0.12 installation or you've done a -reindex on 0.12 it's impossible to downgrade to 0.11 (without starting from scratch).

meeting comments
The proposed pull-request detects the obfuscation in 0.11 so it throws a relevant error message. 
To avoid this in the future it would be good to have versionnumbers for the chainstate.

meeting conclusion
Release a 0.11 backport release right after the 0.12 final release to avoid confusion.

## C++11 update

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
All changes needed for C++11 have gone in and it's ready to switch. 
Cfields talked to the travis team and all the features needed (trusty, caching) will be ready by the end of the month, so he proposes to wait until then to flip the switch. 
Wangchung from f2pool indicated he would not run code that required a C++ compiler. Noone knows what his exact concerns are. Wumpus notes the gitian-built executables don't need any special OS support after the C++11 switch.

meeting conclusion
Wait for Travis update to switch to C++11. 
Talk to wangchung about his concerns.

## EOL Policy / release cycles

background
In general bugfixes, translations and softforks are maintained for 2 major releases. btcdrak proposed to makes this official into a software life-cycle document for bitcoin core in order to inform users what to expect and developers what to code for.   
Pull request for this document. 
Given the huge 0.12 changelog jonasschnelli asks whether shorter release cycles might be a good idea. Currently there's a +/- 6 month release cycle.


meeting comments
Gmaxwell notes he doesn't know how useful the backports are given there's no feedback about them, but thinks the current policy is not bad. "I am observing the backports appear to be a waste of time. From a matter of principle, I think they are important, but the industry doesn't appear to agree." 
If no one is using the backports, it might not see sufficient testing.
People generally agree with the 2 major releases approach. 

The cyclelength also contributes to frustration and pressure to get features in, as it won't see the light of day for 6 months if it doesn't make the new release. 
For users it's not really better to have more frequent major releases, as upgrading may not always be a trivial process. There's also a lot of work going into releases. 
If the GUI and wallet where detached there could be more frequent releases for that part.

meeting conclusion
Policy will be: final release of 0.X means end-of-life of 0.(X-2), which means a 1 year support on the 6 month cycle.

## Participants
## Comic relief