Notes / short topics

A few developers and miners met eachother in San Francisco where they went to Standford university to meet with Dan Boneh, a researcher in applied cryptography and computer security. Although not short term development related, the transcript made by kanzure has a very high signal-to-noise ratio.

NicolasDorier made an IRC ##libconsensus bikeshedding room about how to handle libconsensus. The design will be presented to the bigger group for feedback.

Main topics

0.13.0

segwit mempool malleability dos

0.13.0

background

The Bitcoin Core team is working towards the 0.13.0 release (full schedule) and RC2 is available since 2016-07-31.

Sipa noticed we forgot to backport PR #8438/#8365 (Treat high-sigop transactions as larger rather than rejecting them). #8438 can wait for 0.13.1

Luke-jr remarks the release notes are still inappropriate regarding blockmaxsize/blockmaxweight, wumpus replies he should adjust his PR to only change the release notes. Gmaxwell and sipa still have to add something to the release notes as well.

Luke-jr wonders what the failure mode for downgrading from 0.13.1 should be and if changes are needed for it. It should give either a hard error or reindex. If it doesn’t do that already, it might be worth it doing another RC including a fix for this and #8438

meeting conclusion

Check if downgrade protection is really needed

segwit mempool malleability dos

background

While reviewing segwit petertodd noticed an attacker may be able to blind a node to a transaction by sending transactions with malleated witness data. Further discussed in issue #8279

Sipa prefers removing the “invalid witness does not cause insertion in rejectioncache” rule, with the rationale that all it does is prevent an attacker from hiding a valid transaction from you but it doesn’t prevent it entirely as they can announce and just never send the transaction.

Bluematt wonders what the rational is to inv’ing with txid instead of wtxid for segwit nodes. Sipa clarifies it would duplicating a lot of logic (mempool, orphan, caches, …), and causes at least a potential doubling anyway as you could be inv’ed the same tx from a pre-segwit and post-segwit node once with txid and once with wtxid, without being able to tell they’re the same. Inv’ing with both txid and wtxid is a solution, but if we go that way, we should also adds resource information to all invs (fees, size, sigops, …), sipa adds.

Morcos proposes to make feefilter mandatory, fully validate txs so we can punish peers who send us invalid stuff. Don’t put any witness tx in the rejection cache, then evaluate how useful rejection cache continues to be or whether we have policy violating segwit txs bouncing around. Sipa likes it, but thinks it’s a big change for 0.13.1.

There’s no clear cut solution for this.

meeting conclusion

start with “don’t put any witness tx in the rejection cache”

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.