IRC meeting summary for 2016-06-30

• Link to this week logs
• Meeting minutes by meetbot

Notes / short topics

• A number of people are testing segwit + BIP152 on testnet. There’s no PR for this yet as this allows for testing interactions with non-segwit-BIP152 and it needs some BIP changes (in BIP144, BIP152 or a separate BIP). It would be good to have it in before the activation of segwit, as otherwise compact blocks will suddenly disable.

Main topics

• Mining related changes for 0.13.0
• Segwit
• Dbcache

Mining related changes for 0.13.0

background

Sdaftuar mentions a few mining related things in an issue that he thinks should be addressed for 0.13.0. PR #8295 is created to solve these issues.

meeting comments

Blockminsize, which sets the minimum block size, is not supported by segwit’s package selection code. Since this feature isn’t relevant to anyone anymore it makes sense to just remove it. The current reason for keeping blockminsize and blockmaxsize is that the new algorithm does not work due to missing accounting. Sdaftuar notes this is addressed in the first commit of #8295. When the blockminsize argument is given, it shouldn’t result in failure, but give a warning.

AddScoreTxs, the old transaction selection algorithm, can be removed as the new package selection algorithm is strictly superior. Sdaftuar notes that if we do this, mining_score could be removed from the mempool multiIndex, which would give us a small memory saving in the mempool. However this is not a priority and can wait until 0.14.

The release notes need a bunch of writeups for all the mining changes.

meeting conclusion

• Remove -blockminsize and give warning when the argument is given
• Update release notes with the mining changes

Segwit

background

Developers are working on a soft fork to introduce segregated witness onto Bitcoin mainnet. Segregated witness (segwit) allows transaction signature data to be stored outside of the data hashed to produce transaction identifiers, removing all known forms of third-party malleability, allowing full nodes to compile the current UTXO set without downloading all signatures, and laying the groundwork for fraud proofs that can allow lightweight (SPV) clients to help enforce more of the consensus rules. The segwit soft fork also allows miners to substitute 1 byte of block space with 4 bytes of segwit data, increasing transaction capacity for wallets that use segwit. segregated witness BIPs: BIP141, BIP142, BIP143, BIP144 and BIP145

meeting comments

During his review petertodd found a potential mempool DoS risk due to malleated transactions (issue 8279).

Gmaxwell proposes to make low-dos-score a ranking criteria in the eviction protection logic, which would make running with a very high DoS threshold more reasonable. Sipa notes the DoS score should also attenuate over time if such changes are made, otherwise longer-lived connections will accumulate a score they don’t deserve.

Petertodd would like to see different thresholds periods for some nodes, so that while you won’t waste bandwidth on everyone a few peers are connected regardless. Gmaxwell notes such a thing could turn those peers into blockonly as that’s all we care about for anti-partitioning and it almost completely eliminates DoS concerns.

Sipa thinks there may be reasons to introduce something like a “resource usage score” which is distinct from “misbehavior”, which gets used to decide which peers to disconnect in favor of others, but never causes a ban.

Gmaxwell notes bitcoinXT recently started making only outbound connections to other XT nodes, which in combination with segwit will partition them. An issue has been made in the XT repo for it.

meeting conclusion

• Brainstorm about connection management stuff

Dbcache

background

Gmaxwell noticed very slow reindexing while testing with default dbcache, which got confirmed by sipa who saw similar behavior. This was brought up in last weeks meeting.

meeting comments

Wumpus created PR #8273 to bump the default dbcache to 300 MiB and cap the allocations for the leveldb specific caches to 32 MiB, which is the current default for 100 MiB. Gmaxwell’s testing confirmed the leveldb cache size doesn’t have a lot of effect, however they have more effect with txindex enabled. He also noticed that even the 300 MiB dbcache is really not big enough to give a good reindex performance and proposes to think about giving mempool memory to dbcache during a reindex/initial block download for 0.14.

Jonasschnelli tests showed him that a reindex of master was almost twice as long as a normal initial block download from scratch. He ran the tests with -debug enabled so it might have skewed the benchmarks. He also noticed the error potential_deadlock_detected that stops his node every couple of minutes. He made a issue for that.

meeting conclusion

• Further benchmarks

Comic relief

gmaxwell       <meme text="Delete all the code."/>

wumpus         sipa: attenuating theDoS score over time makes sense, a very slow DoS attack isn't really a DoS attack
sipa           theDos? sister of [GLaDoS](https://en.wikipedia.org/wiki/GLaDOS)?
wumpus         the cake is a lie

gmaxwell       Hurrah we ended early. :p
jonasschnelli  1min! :)
gmaxwell       May your usage of the remaining minute be productive.

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.