IRC meeting summary for 2016-10-13

• Link to this week logs
• Meeting minutes by meetbot

Notes / short topics

• Jtimon has posted a libconsensus completion plan on the mailinglist.
• Some people complained about testnet being unreliable as it’s not consistently mined. Some like to see a signed testnet, similar to what elements alpha runs, so that it would have perfectly predictable blocks and reorgs.
• There is a segwit development guide out for downstream developers. There should be a segwit deployment guide as well with more details on for example how to set up a perimeter node.
• Achow101 will write a post about the alert system for bitcoin.org, which has been discussed previously in the 2016-09-22 meeting.

Main topics

• 0.13.1 & BIP 9 parameters
• sybil attacks

0.13.1

background

Bitcoin Core 0.13.0 was released on 2016/08/23. The next point release 0.13.1 will probably include the segregated witness softfork activation logic, among other bugfixes and optimizations.

BIP9 is the mechanism that uses individual bits of the ‘version’ field in bitcoin blocks to deploy softforks. BIP68, BIP112 and BIP113 have been simultaneous deployed using this mechanism.

meeting comments

There’s only one PR (#8499) remaining for 0.13.1, which adds policy limits and disables uncompressed keys for segwit scripts. Jl2012 has been writing tests for it, as there are a lot of edge cases, but they’re all identified and fixable now.

BIP 9 recommends the start date to be set roughly a month after software release. BlueMatt proposes to not set a date in the first release candidate, but set it on the final one. As this would complicate things it’s better to just set a date far enough in the future in RC1. The fact BIP9 requires 4-8 weeks to activate realistically, makes the date less of an issue.

meeting conclusion

• make a mailinglist post concerning the segwit softfork to decide on the activation time with a proposal of 1 month after RC1.

sybil attacks

background

There’s currently an attack going on which is mass connecting many times in parallel to all reachable nodes pretending to be a mix of different spv clients.

meeting comments

Gmaxwell notes he’s seeing 60+ connections within seconds of starting a node. There have been abuse complaints made about this user towards Amazon, however they are unresponsive.

Because of the connection management implemented a few versions ago this attack doesn’t disrupt the network much, but it’s assumed their motivation is to undermine user’s privacy through observation as it would otherwise be a very ineffective DoS attack.

This privacy leak can be reduced by implementing already planned relay improvements, which isn’t finished yet due to other priorities. It’s very likely they’ll stop the attack if we reduce the privacy leak.

Btcdrak wonders whether we can ban multiple connections from the same IP, however that would harm many institutions who use the same IP. They also already use multiple IPs which they’ve changed once people started circulating banlists.

BlueMatt notes several people now ban AWS (Amazon Web Services) nodes, which is a shame because they’re useful due to its built-in DoS protection.

meeting conclusion

• Work on reducing the privacy leakage.

Comic relief

(selective quoting for comic effect)

morcos               so use 2 months after the time you issue the first RC for instance?
BlueMatt             so set parameters to 1.5 months for rc1? or 2?
wumpus               just estimate 2 months for the RC process
btcdrak              most releases take 3 or 4 rcs, so if we set the date for 5 weeks on rc1 that would cover it I am sure.
morcos               is wumpus saying 3 months?
wumpus               no, two months is fine
BlueMatt             i mean I'm ok with 1.5 months, too
achow101             I think two months after rc1 is fine
gmaxwell             I think it would be fine to set start date 1 month after RC1. 
BlueMatt             for now lets recommend 1.25 months from rc1
michagogo            BlueMatt: perhaps 50 days for roundness
michagogo            Or 55
sipa                 nov 15.
michagogo            That's good too
btcdrak              this is like an auction.
achow101             nov 15th sounds good (at 00:00 AM?)

Participants

Disclaimer

This summary was compiled without input from any of the participants in the discussion, so any errors are the fault of the summary author and not the discussion participants.