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

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.

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.