IRC meeting summary for 2016-10-13
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.
- 0.13.1 & BIP 9 parameters
- sybil attacks
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.
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.
- make a mailinglist post concerning the segwit softfork to decide on the activation time with a proposal of 1 month after RC1.
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.
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.
- Work on reducing the privacy leakage.
|wumpus||Wladimir van der Laan|
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.