IRC meeting summary for 2016-02-11

Logs

• link to this week logs
• Meeting minutes by meetbot

Main topics

• BIP68 review
• Softfork logic (BIP9)
• squash/rebase recommendations

Short topics

Cfields is still working on an overhaul of the networking stack, he hopes to have it ready by next week. The best time to merge a change like that is at the beginning of the release window, so around now. Otherwise we’ll have to postpone it to 0.14

Petertodd is working on an article/paper/blog-post on fraud proofs along with some data structure work for them. Maaku would like to work with him on the fraud proofs and prev-block proofs as he has done his own explorations on that.

BIP68 review

background

BIP 68 Consensus-enforced transaction replacement signaled via sequence numbers.
BIP68 implementation mempool-only
Is merged after the meeting.

meeting comments

BIP68 and 112 don’t need mempool deployment before being safe as a softfork, however we’ve always merged the policy-only implementation before the softfork logic.
The softfork needs more scrutiny and unit tests.

meeting conclusion

Merge the mempool-only implementation to master, backport mempool + softfork to 0.12.x when the softfork ready.
Review/test BIP112 #7524 (rebased version)

Softfork logic (BIP9)

background

BIP 9
Currently softforks have been done by the isSuperMajority mechanism, meaning when 95% of the last 1000 blocks have a version number higher than X the fork is deployed.
A new way of doing this is currently being worked on and that uses all bits of the version number, appropriately being called versionbits. So instead of a fork happening when the version is larger than (for example) 00000000011 (3), a fork happens when (for example) the 3rd bit is up (so 00100000011).
This way softforks can be deployed simultaneous and independent of each other.

meeting comments

BIP 9 is needed since there are so many outstanding softforks that it might delay them all. However, we shouldn’t be holding up valuable soft-forks due to the delay in BIP9 development.
We can do deployment via BIP9 while an other isSuperMajority softfork isn’t yet finished.
The problem with current BIP9 implementations is: Codeshark’s version was a lot of code which seemed to do a lot of unrelated things, and Rusty’s version never had a caching layer on top to make it efficient.
Petertodd notes it needs a bunch of stuff added to the database to store the flags, however sipa offers a solution to compute the state for every block once, remain immutable after that, and recompute on startup. This way you don’t have to store anything in the chainstate.
Morcos withdrew from working on BIP9. jtimon will do it if there’s no other volunteer.

meeting conclusion

Do isSuperMajority softforks until BIP9 is merged.

squash/rebase recommendations

background

A pull request usually exists of several different commits (changes to the code). These commits can be squashed together into a single commit. On the previous discussed BIP68 implementation some discussion ensued on what to squash and what not.

meeting comments

commits have a logical function, you want to tell a story how you changed the code that is easy to review, not necessarily your chronological order of changes. If you have tons of ‘fix issue X’ where X was introduced in the same pull, that’s not useful.
A concern is that squashing is annoying for people who are in the midst of reviewing.
Sipa notes it would be good to have a local review script that stores the commits/trees you’ve reviewed and later on shows you the differences compared to what you reviewed before.

meeting conclusion

The general rule is: do whatever is easier to read and review.

Participants

wumpus            Wladimir J. van der Laan  
sipa              Pieter Wuille  
morcos            Alex Morcos  
maaku             Mark Friedenbach  
jtimon            Jorge Timón  
petertodd         Peter Todd  
gmaxwell          Gregory Maxwell  
paveljanik        Pavel Janik  
cfields           Cory Fields  
sdaftuar          Suhas Daftuar