IRC meeting summary for 2016-08-25

• Link to this week logs
• Meeting minutes by meetbot

Notes / short topics

• Paveljanik asks for some more review/ACKs on his Wshadow PRs: PR#8191, PR#8449, PR#8466, PR#8468 and PR#8472
• Bitcoin Core 0.13.0 is released.
• There’s a proposal to have a standard for hardware wallets to do detached signing, which would allow decoupling the keys from the wallet. This to end the wild-west of APIs/interfaces that are currently implemented by wallets and hardware wallet vendors.

Main topics

• proposals for segwit DoS protection
• code signing

proposals for segwit DoS protection

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

meeting comments

There have been several proposed solutions, including: verifying all inputs (even if the transaction is too big or below feerate), not entering failed witness transactions into the reject table, making feefilter mandatory, …

Gmaxwell thinks all those changes are beneficial, verify all inputs was a proposal even from before segwit was imagined, the primary reason we didn’t make that change was because there was a lot of rejected stuff coming from even cooperative peers. This should be resolved with feefilter.

As an alternative to validating everything jl2012 suggested to randomly validate some percentage, as it allows you to punt a peer sending you garbage, but you only take a fraction of the cost.

meeting conclusion

• PR#8525: Do not store witness txn in rejection cache
• PR#8593: Verify all incoming txs unless too big or too much hashing

Code signing

background

Last weeks meeting discussed multiple security enhancements for signing and verifying the Bitcoin Core binaries.

meeting comments

Cfields has been working on a codesigner for OSX that runs from linux, so an OSX machine is no longer needed for the release process. He wonders whether anyone has suggestions for more complicated/distributed signing schemes, before he implements it as it was before. Gmaxwell likes see whether it’s easy to integrate multiparty signing into it.

Codeshark wonders whether 4096 bit RSA instead of 2048 bit is overkill. 2048 bit is approximately the equivalent of 128 bit ECDSA. 4096 would be better, as size and performance are basically irrelevant, but the parameters of the key are chosen by Apple.

meeting conclusion

• Gmaxwell and sipa will look into threshold signing for 2048 bit RSA to see if we can get it so that no single party holds that key.
• Cfields will try to find out if other signature types than 2048 bit RSA are possible (like a 4096 bit key).

Comic relief

paveljanik         I'd like to ask for more ACKs on Wshadow PRs
gmaxwell           too bad, we haven't started so you can't ask for that yet.
gmaxwell           :P
wumpus             #startmeeting
paveljanik         I'd like to ask for more ACKs on Wshadow PRs
paveljanik         ;-)

wumpus             anything that really needs to be discussed at the meeting?
CodeShark          no, we've already accomplished everything - there's nothing more to do ever

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.