IRC meeting summary for 2016-08-18
Notes / short topics
- The binary releases of Bitcoin Core are still signed with ‘The Bitcoin Foundation’. Jonasschnelli wonders whether we should try and get new certificates in the name of “Bitcoin Core”. Cfields was looking into this, but got nowhere. His best suggestion was to see if MIT would be interested in helping with a certificate.
- core internal binary signing and verification tool
- 0.13.0 Final
core internal binary signing and verification tool
After Cobra-Bitcoin posted a safety warning on the bitcoin.org website more people have been asking how to safely verify the Bitcoin Core binaries.
Jonasschnelli proposes to to add a command line interface tool in the Bitcoin Core package for verifying Bitcoin Core. Btcdrak thinks a GUI would bring a wider adoption. It would be a separate executable within the Bitcoin Core distribution. The elliptic curve signatures should be placed in bitcoin/bitcoin, otherwise it would need to be hosted elsewhere, which is a change in the release process. Wumpus notes the GPG keys are already in the repository.
Kanzure thinks “next” is important to include in the name, to make clear the verification tool is to verify the next release. Making it so that once you have a good release you’ll have good releases forever.
It would be a N-out-of-M scheme so there’s some room to tolerate revoked or compromised keys.
Jonasschnelli notes the tool would allow hardware wallets to sign the binaries, though you can already do this with GPG smartcard. A number of people use GPG via yubikey3. Btcdrak notes Ledger Nano S could be programmed to do signing and it also has a GPG module coming, he thinks everyone should be using some kind of smartcard/hardware device for GPG signing.
Btcdrak suggests to mirror downloads elsewhere, like Github and bitcoincore.org. Wumpus notes we already provide torrents for people that don’t want to download from bitcoin.org and extra mirrors doesn’t solve the verification problem. Hosting the binaries on Github also gives another incentive to compromise our Github.
Zooko explains a project called “binary transparency”, which lets you submit your hash to append-only servers. (google-group) Wumpus notes this doesn’t solve the problem of users not verifying the binaries at all, unless the OS would build in support for it.
- Jonasschnelli will work on a short design and post it to the bitcoin-core-dev mailinglist.
- Start adding the sha256 hashes with the release announcement as it will ensure a wider distribution of the hashes.
There have been no critical issues reported with RC3, so it could be tagged as final at any time now.
MarcoFalke ran into an issue on testnet, which may be a release blocker. (after the meeting the problem was detected and deemed not a release blocker)
The gitian builds could start over the weekend.
Given 0.13.0 is delayed Wumpus wonders whether we should delay setting up the 0.14 release schedule. Everyone agrees the current 6 month schedule is fine and 0.14 should be scheduled right after the 0.13.0 release.
- review the 0.13.0 blog post on bitcoincore.org
- Start gitian building
BIP146: Dealing with signature malleability. LOW_S and NULLDUMMY have been non-standard on the network for a long time, and do not appear on the chain. As they are both trivial BIP146 proposes to do this softfork together with segwit. Low_S was discussed in last weeks meeting.
The BIP proposal was sent to the mailinglist (after official meeting time:) Bluematt still runs a node which malleates high-s transactions automatically to low-s and he still gets a lot of high-s transactions (about 1 per hour). This could also be someone malleating originally low-s transactions though.
- Do BIP146 together with segwit
|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.