IRC meeting summary for 2016-08-25
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.
- proposals for segwit DoS protection
- code signing
proposals for segwit DoS protection
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.
- PR#8525: Do not store witness txn in rejection cache
- PR#8593: Verify all incoming txs unless too big or too much hashing
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.
- 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).
|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.