19:00:19 <wumpus> #startmeeting
19:00:19 <lightningbot> Meeting started Thu Aug 18 19:00:19 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:19 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:39 <jonasschnelli> proposed topic: core internal binary signing and verification tool
19:00:40 <sipa> kanzure: its twitter handle is therealping
19:00:45 <wumpus> kanzure: it comes from gmaxwell, who the offical meeting-pinger, and he is authenticated with freenode
19:01:11 <btcdrak> how do we know freenode is still free?
19:01:30 <wumpus> because otherwise it would be renamed to restrictednode
19:01:32 <luke-jr> jonasschnelli: a tool would be nice, but there is no reason for it to be internal
19:01:40 <jonasschnelli> there are
19:01:50 <jonasschnelli> (to be covered under gitian)
19:01:57 <wumpus> #topic core internal binary signing and verification tool
19:02:01 <luke-jr> you can gitian-build things besides Bitcoin
19:02:26 <jonasschnelli> I propose to add to cli tools to the bitcoin-core package
19:02:34 <kanzure> off-topic, but does anyone know the status of deterministic debian efforts?
19:02:34 <jonasschnelli> bitcoin-core-verify and bitcoin-core-sign
19:02:44 <jonasschnelli> The later will not be shipped
19:02:47 <jonasschnelli> bitcoin-core-verify <folder-or-file> -> 1) hashes file(s) 2) download gitian assets files together with ECDSA sigs 3) verify hashed against downloaded assets files 4) verify assets ECDSA sigs against in-binary-pubkeys (dev-name/pubkey)
19:02:51 <jonasschnelli> bitcoin-core-verify will list valid signatues of devs by listing devs name.
19:02:55 <wumpus> I suppose it will be a separate executable within the bitcoin core distribution, other software can also include it if they want, but that's not initially very important
19:02:57 <btcdrak> jonasschnelli I think it needs to be GUI for wider adoption.
19:03:07 <jonasschnelli> Yes. It would be a Qt tool for one major reason
19:03:08 <gmaxwell> Please don't do design in the meeting.
19:03:10 <jonasschnelli> https downloads
19:03:25 <jonasschnelli> gmaxwell: okay. fair enought...
19:03:29 <gmaxwell> I'm planning on having someone work on that.
19:03:49 <btcdrak> jonas is already building something afaik
19:03:51 <wumpus> yes it needs https support to get at the signatures from github
19:03:56 <jonasschnelli> Yes. But happy to pause.
19:04:06 <gmaxwell> If it does https I will nak it so hard keys will fall  of the keyboard.
19:04:07 <jonasschnelli> Qt would have https support built in
19:04:21 <jonasschnelli> the gitian sigs come over https
19:04:22 <gmaxwell> We _cannot_ ship some downloading tool that is going to require frequent CVEs itself.
19:04:27 <wumpus> it's not a downloading tool
19:04:28 <jonasschnelli> either with git or with https
19:04:29 <MarcoFalke> So how do you verify bitcoin-core-verify?
19:04:30 <wumpus> just a verification tool
19:04:41 <wumpus> MarcoFalke: it'd be part of the distribution
19:04:45 <btcdrak> no need for https when you have cryptographic verification
19:04:51 <gmaxwell> What btcdrak said.
19:04:58 <jonasschnelli> I guess even if https is broken, nobody can upload valid EC sigs
19:05:05 <btcdrak> https _is_ broken
19:05:12 <jonasschnelli> https is required to download from github I guess
19:05:16 <wumpus> well if you can get information from github through http that would work too
19:05:39 <jonasschnelli> Yes. TLS is not required for security.
19:05:46 <luke-jr> the git protocol isn't encrypted I think
19:05:55 <btcdrak> actually I think it's impossible to fetch from github without https, you'd have to use the git:// ptrotocol
19:05:59 <wumpus> you seriously wouldn't want to implement the git protocol
19:06:02 <cfields> wumpus: distribution == our release? Or OS?
19:06:10 <jonasschnelli> he. yes. no git:// please
19:06:10 <wumpus> cfields: yes, our releases
19:06:46 <jonasschnelli> The only concern is – and this is why i borugh it up – the ec-pubkeys together with dev-name should be placed in bitcoin/bitcoin
19:06:55 <wumpus> otherwise you'd have to host the signatures somewhere else than github, which is possible of course, but is a change in the release process
19:06:57 <jonasschnelli> somewhere where it could be used in cpp source code (probably in a header)
19:07:24 <wumpus> well the gpg keys are already in the respository
19:07:25 <jonasschnelli> this would allow to build a "trusted-chain" of bitcoin-core binaries
19:07:27 <cfields> mm. Can we back up then and address what this is aiming to solve? What protects against someone re-packaging a malicious release along with a clone "verification tool" that always passes?
19:07:40 <kanzure> an email to the mailing list about verification procedures seems prudent at some point, as a general reminder. i'm sure there's existing content somewhere that can be copied for these purposes.
19:07:44 <jonasschnelli> cfields: Sure. Thats always possible
19:07:54 <btcdrak> just confirmed github forces https redirection
19:07:58 <MarcoFalke> So bitcoin-core-verify checks the release, but is part of the release... Isn't this circular?
19:07:58 <wumpus> cfields: yes, it only works for chaining, if the first link in the chain is broken it solves nothing...
19:08:05 <jonasschnelli> But not if you have verified the first download (assume with gitian verify), then verify with the new tool
19:08:10 <gmaxwell> cfields: well if something competent were being done, the setup would be the last version you got provides a tool to get/verify the next version.
19:08:14 <wumpus> MarcoFalke: it'd be used to check the *next* release downloaded
19:08:32 <kanzure> bikeshedding for a sec, but "next" seems important enough to be part of the name ;)
19:08:33 <jonasschnelli> people could still gitian-verify our new verification tool
19:08:36 <wumpus> MarcoFalke: having it verify itself would be sillly
19:08:37 <cfields> right.
19:08:44 <gmaxwell> cfields: so if you previously got a good release, then you'll have good releases foreverafter (or at least until the signing keys were compromised :) )
19:08:47 <MarcoFalke> ok, I see
19:08:55 <kanzure> s/compromised/revoked?
19:09:00 <kanzure> +revoked, at least?
19:09:16 <cfields> kanzure: +1. that wasn't clear to me until now :)
19:09:17 <jonasschnelli> key revoking is possible over our release-management
19:09:23 <wumpus> kanzure: well it be N-out-of-M ,so could tolerate some revoked or compromised keys Iguess..
19:09:26 <gmaxwell> kanzure: without an uncensorable communications medium or expiration there is no sense for revocation.
19:09:33 <kanzure> hm.
19:09:41 <wumpus> then they'd just be removed in the next release
19:09:59 <jonasschnelli> I just wanted to hear if it's ackable to continue to work on this... if so, I'll come up with something for 0.14.
19:10:25 <gmaxwell> n of m is close to an uncensorable communicatoins medium subject to an honest threshold assumption.
19:10:29 <luke-jr> gmaxwell: well, if you're looking at the list of people/keys who *didn't* sign, it might help to know they revoked their key rater than simply didn't-sign
19:10:32 <btcdrak> gmaxwell: what if you got a good release, but were later infected with malware which changed the verifier tool?
19:10:43 <gmaxwell> btcdrak: oh well.
19:10:50 <wumpus> btcdrak: if you are infected, it's end of story really
19:10:55 <wumpus> btcdrak: it can already steal your coins
19:10:55 <jonasschnelli> indeed
19:10:55 <gmaxwell> btcdrak: if you're infected with malware you're hosed at that point.
19:10:57 <sipa> btcdrak: you are eaten by a frue
19:11:00 <sipa> *grue
19:11:03 <jonasschnelli> you can't protect from malware on that layer
19:11:11 <kanzure> perhaps the malware would be kind enough to at least inform you of your infection
19:11:20 <wumpus> that's another story entirely (hardaware wallets / security modules)
19:11:20 <jonasschnelli> impossible
19:11:47 <jonasschnelli> At least, the EC binary sig tool would allow hardware wallets to sign the binaries
19:11:58 <wumpus> that's an interesting idea
19:12:03 <jonasschnelli> (though you can do this with GPG smartcard)
19:12:13 <wumpus> there are smartcards running GPG?
19:12:20 <jonasschnelli> Yes.
19:12:22 <wumpus> is there some micro-gpg implementation?
19:12:22 <btcdrak> yes
19:12:34 <jonasschnelli> but a big mess
19:12:39 <gmaxwell> A number of people around here use gpg via yubikey3.
19:12:39 <wumpus> yeah...
19:12:41 <btcdrak> petertodd has one with pin entry. sounds like he's at the cash register when sending emails
19:12:50 <gmaxwell> wumpus: it's not really gpg on the smartcard, it's a rsa signer on a stick. :)
19:13:20 <btcdrak> Ledger Nano S could be programmed to do signing. It also has a GPG module coming. It uses an ST31 secure element afaik
19:13:34 <wumpus> gmaxwell: oh right, just the rsa signing, the ugly thing about gpg is all the packet parsing and interpretation etc
19:13:52 <instagibbs> btcdrak, I have a pgp key from mine
19:14:04 <instagibbs> (just playing around with it)
19:14:19 <gmaxwell> There is a terrible complex standard for supporting it. In any case, it's a good thing to have.
19:14:22 <wumpus> same problem as TLS really, the crypto algorithms themselves are reasonably elegant and bug-free, but all the parsing mess around it...
19:14:47 <kanzure> should we move on?
19:14:49 <wumpus> anyhow, I think we agree that we'd want to use secp256k1 signatures
19:14:55 <wumpus> if we can agree on one thing
19:15:00 <btcdrak> Just a separate note, I think everyone here should be using some kind of smartcard/hardware device for GPG signing. There are plenty inexpensive options like Yubikeys and etc.
19:15:14 <jonasschnelli> Okay. I'll work on a short design and post it to bitcoin-core-dev ML
19:15:29 <wumpus> btcdrak: I just use old computers, but I agree that's the more practical option :-)
19:15:34 <kanzure> should we be complaining about hkp to the bitcoin.org people?
19:15:44 <gmaxwell> jonasschnelli: can you spend some time and talk to mr or sipa before you post?
19:16:03 <jonasschnelli> gmaxwell: Yes. Will do... thanks for offering that.
19:16:35 <wumpus> kanzure: hkp?
19:17:19 <kanzure> HPKP
19:17:52 <kanzure> public key pinning
19:18:18 <btcdrak> they also dont enforce HSTS
19:18:29 <kanzure> does bitcoincore.org?
19:18:32 <btcdrak> yes
19:18:35 <kanzure> both?
19:18:36 <jonasschnelli> Another short topic proposal that is near to the signing: code-signing (OSX/WIN).
19:18:48 <wumpus> sure, why not, if anything can be done to improve site security we should encourag that
19:19:00 <btcdrak> no, just HSTS and certificate origin
19:19:37 <gmaxwell> HPKP is pretty easy to mess up. TBH it's a lot more useful for parties that are their own CA.
19:20:02 <btcdrak> sorry, i mean authenticated origin pulls
19:20:25 <btcdrak> HSTS is important to prevent https downgrade attacks imo
19:20:27 <kanzure> okay well i'm eagerly awaiting for the delivery of the complimentary ips containers
19:20:35 <wumpus> yes, HSTS is important, and trivial to implement
19:20:57 <wumpus> never even heard of HPKP before
19:21:09 <kanzure> jonasschnelli: iirc there was some detail about code signing and windows - something about a buggy state?
19:21:17 <kadoban> HPKP is key-pinning. It's to prevent attacks like rogue CAs
19:21:21 <wumpus> #topic code-signing (OSX/WIN)
19:21:32 <jonasschnelli> We still sign with "Bitcoin Foundation"
19:21:32 <btcdrak> while we are on the topic of releases and so on, wumpus could you please start posting the hashes with the release announcement too. that will ensure wide distribution of the hashes.
19:21:42 <jonasschnelli> On OSX, its not very visible... on Windows I guess a bit more.
19:21:51 <wumpus> kadoban: then gmaxwell's comment makes sense - sounds like a risky thing to do if you're depenent on someone else's CA
19:22:04 <jonasschnelli> Question: we should try to get new certificates for OSX/Win in the name of "Bitcoin Core".
19:22:18 <gmaxwell> (I'm not saying that it shouldn't be done for that site, just that it's not a no brainer.)
19:22:20 <jonasschnelli> The question is, if we should. :)
19:22:23 <instagibbs> jonasschnelli, that's a statement :P
19:22:27 <btcdrak> jonaschnelli: that would be great. do you have a company that can do it?
19:22:29 <kadoban> wumpus: It's a little risky. You can pin any piece of the chain, like you can pin *your* private key(s). But then if you do it and screw it up ... you're *really* screwed.
19:22:33 <kanzure> re: posting hashes, i also suggest we consider posting hashes and maybe sigs on bitcoincore.org -- we can also ask bitcoin.org to do the same if they feel up to that
19:22:34 <wumpus> btcdrak: sure, I could paste sha256sums.asc into the announcement email
19:22:39 <luke-jr> jonasschnelli: cfields was looking into this, but I am not sure his status
19:22:47 <kadoban> Like, your website is unusable for 6 months screwed.
19:22:47 <btcdrak> wumpus: thank you.
19:22:57 <wumpus> kadoban: right - what if you want to switch CAs for some reason
19:23:16 <wumpus> #action sha256sums in release email
19:23:19 <jonasschnelli> btcdrak: I have serval code signing certificates.. but we don't want to use these company names...
19:23:24 <gmaxwell> kanzure: I think thats not going in a useful direction. Posting hashes and stuff is fine, if people want to do it-- but its mostly security theater because virutally no one will check, and you can tell they don't check.
19:23:28 <kadoban> wumpus: You can, if you do it right. You can reuse the same private keys with a different CA (and you can set multiple possible pins, so you can have backups)
19:23:35 <cfields> luke-jr: didn't get anywhere with it. My best suggestion was to see if MIT would be interested in helping with a cert
19:23:36 <wumpus> (do note that release emails are signed with *my* key, not the release signing key)
19:23:59 <sipa> sorry i fell asleep
19:24:47 <gmaxwell> Thats a sign to move on. :)
19:24:51 <btcdrak> wumpus: We should also publish the hashes on bitcoincore.org with the release announcements there. Tempted to suggest we aim at mirroring downloads somewhere as well, like the github repo which supports release binaries and maybe bitcoincore.org
19:25:06 <instagibbs> brainstorming can continue later imo
19:25:08 <kanzure> wasn't github sunsetting hosted release binaries?
19:25:16 <luke-jr> is there some organization name that people would be comfortable having sign both Core and Knots releases? would be nice to consolidate in that regard
19:25:20 <wumpus> btcdrak: we already provide torrents for people that don't want to download from bitcoin.org - it solves nothing of the verification problems ofc
19:25:29 <luke-jr> kanzure: I think they re-introduced them
19:25:42 <kanzure> yes it makes sense to not use "Bitcoin Foundation" -- perhaps chaincode would be a good org to blame instead? :D (kidding- let's be nice)
19:25:48 <wumpus> yes, github has the option to host release binaries
19:25:53 <kanzure> luke-jr: got it
19:26:04 <wumpus> but having the binaries in more places means more places to check wether they are compromised too
19:26:05 <anchow101> Why not host binaries on GitHub and move completely off of bitcoin.orgs system
19:26:16 <btcdrak> wumpus: we should do it there as a mirror at least.
19:26:25 <wumpus> also it gives another reason to want to compromise our github
19:26:59 * jonasschnelli is not sure if we should place the binaries on the same host at the source code
19:27:00 <wumpus> I'm not comfortable with everyting in one place
19:27:15 <sipa> let's use sourceforge *ducks*
19:27:16 <wumpus> yea, exactly, feels like putting a lot of eggs inone basket
19:27:20 <wumpus> hah
19:27:23 * jonasschnelli stabs sipa
19:27:27 <warren> The more mirrors, the better.  Although the value of mirroring for diversity is wiped out by automated rsync which is how most people demand to keep mirrors updated.
19:27:29 <gmaxwell> you don't think github isn't fully compromised already, come one? :)
19:27:34 <gmaxwell> er come on
19:27:46 <btcdrak> regarding bitcoincore.org I have a promising offer of sponsorship for around 5 years of hosting/infrastructure from Pindar, so we could setup a download server for example.
19:27:54 <wumpus> well at least sudden code changes are fairly detectable
19:28:07 <wumpus> (and we sign all top-level commits)
19:28:16 <gmaxwell> please can we move on?
19:28:18 <anchow101> What about Amazon s3 for binary hosting?
19:28:18 <wumpus> so there is very little gain in compromising our github right now
19:28:20 <btcdrak> The issue is less about being compromised and more about early warning.
19:28:30 <wumpus> any other topics?
19:28:41 <instagibbs> 0.13.0 final?
19:28:42 <sipa> 0.13.0?
19:28:45 <btcdrak> having multiple places makes it more likely a compromise would be spotted earlier
19:29:02 <wumpus> btcdrak:  I disagree; it doesn't solve the problem of peopel not verifying at all
19:29:07 <wumpus> #topic 0.13.0
19:29:12 <kanzure> does anyone have details about the large quantity of revoked 'malicious' (fake) gpg short id matching keys from the other day? i saw this somewhere but didn't keep a reference.
19:29:31 <instagibbs> kanzure, greg told me it was some academic paper's work
19:29:32 <wumpus> I have only one thing to say on this topic: there have been no critical reported issues with rc3, in principle it could be tagged final at any time
19:29:35 <MarcoFalke> I think the last doc change was merged. We can start gitian after the meeting?
19:29:50 <kanzure> instagibbs: well i didn't hear it from greg. i did hear somewhere that it was a 'researcher'. but i have no idea where i saw this.
19:29:54 <MarcoFalke> Or did anyone hear of critical problems?
19:30:09 <btcdrak> MarcoFalke: it's all good from what I can see.
19:30:17 <gmaxwell> kanzure: I'll provide citations after the meeting.
19:30:18 <instagibbs> there was one report of stalled segwit ibd on testnet
19:30:20 <sipa> kanzure: https://twitter.com/bcrypt/status/765615853488316416
19:30:29 <wumpus> however the announcement of cobra this morning felt like someone dropped a bomb on the release process, and 'infected' 0.13.0 in people's minds before it is even released, so I feel really grumpy about this topic right now
19:30:30 <instagibbs> but not sure if that's one-off or what
19:30:42 <gmaxwell> instagibbs: I've been trying to reproduce marco's stalls with testnet. synced and caught up a few hosts.. so far nothing.
19:31:07 <jonasschnelli> wumpus: agree, that was a imprudent move..
19:31:07 <sipa> gmaxwell: do you have multiple header chains extending your active branch?
19:31:08 <btcdrak> wumpus: maybe tag on Friday evening, let the gitian builders process over the weekend and we can release on Monday/tues/
19:31:16 <MarcoFalke> I can upload my 8.5 gig datadir *ducks*
19:31:33 <cfields> wumpus: tag it as 0.13.0.1 :)
19:31:34 <gmaxwell> sipa: no I've just tried varrious things. I thought we already fixed the big with multiple header chains?
19:31:39 <wumpus> cfields: lol :)
19:31:49 <sipa> gmaxwell: i thought so too
19:31:51 <btcdrak> cfields: lol
19:32:05 <instagibbs> gmaxwell, me neither *shrug*
19:32:05 <MarcoFalke> Able to reproduce consistently here, but this is something for 13.1
19:32:06 <sipa> gmaxwell: but that was something i noticed in MarcoFalke's roc output
19:32:16 <sipa> rpc
19:32:38 <gmaxwell> MarcoFalke: if you have a sync failure that is reproducably consistently it may be a release blocker.
19:32:40 <btcdrak> you mean 0.13.1
19:32:43 <kanzure> wumpus: yeah, there should be a peer review process for posts to bitcoincore.org -- and bitcoin.org would be wise to adopt a similar practice.
19:33:01 <gmaxwell> Please can we stop with the prior topic?
19:33:05 <kanzure> okay.
19:33:18 <btcdrak> last calls for review of the 0.13.0 blog post https://github.com/bitcoin-core/bitcoincore.org/pull/199
19:33:32 * btcdrak has been asking for two weeks....
19:33:43 <sipa> btcdrak: i reviewed!
19:33:45 <wumpus> yes we're slipping incredibly, for no really good reason, I know
19:33:48 <wumpus> I feel bad about it too
19:34:00 * btcdrak gives sipa a gold star!
19:34:10 <wumpus> oh you mean the blog post, I'll take a look at it
19:34:23 <gmaxwell> btcdrak: sorry, I missed that completely, will look.
19:34:25 <wumpus> #action review https://github.com/bitcoin-core/bitcoincore.org/pull/199
19:34:26 <instagibbs> I'll review today
19:35:01 <btcdrak> wumpus: so tag friday evening, and release ~monday?
19:35:11 <sipa> sounds fine be me
19:35:14 <wumpus> any rationale for friday evening, and not, right now?
19:35:21 <sipa> also fine by me
19:35:25 <sdaftuar> sipa: is marco's issue that the stalling detection doesn't make sense if there are some outbound NODE_NETWORK peers you don't download blocks from?
19:35:31 <gmaxwell> I am concerned that we have a reproducable candidate release blocker.
19:35:55 <gmaxwell> we should become confident that it's segwit only.
19:36:02 <wumpus> bah
19:36:08 <btcdrak> wumpus: to give time for the cobra announcement to fade
19:36:11 <gmaxwell> perhaps by having marco backup his state, and then disable segwit.
19:36:16 <wumpus> I'm about to give up on 0.13 completely :p
19:36:25 <wumpus> and focus on 0.14 from now on
19:36:26 <sipa> wumpus: what, and release 0
19:36:28 <btcdrak> 13 is unlucky number!
19:36:31 <sipa> qe.1 instead?
19:36:34 <wumpus> btcdrak: yes. exactly.
19:36:38 <kanzure> one rationale for not right now is to give time for review on bitcoincore.org pull 199
19:36:46 <btcdrak> ^
19:36:47 <kanzure> so maybe like... whatever average review time is. heh.
19:36:59 <wumpus> gitian building takes time too
19:37:03 <gmaxwell> If the issue is segwit only-- and only rarely triggered, then I'm fine with it being 0.13.1, but I don't know if we know that.
19:37:10 <instagibbs> wumpus, skip 0.12.1, go straight to 1.0, come on
19:37:12 <wumpus> we can delay the uploading until your blog post is finished, sure
19:37:36 <wumpus> instagibbs: skipping numbers doesn't work if we don't feel confident about the code, though
19:37:38 <gmaxwell> I don't think there is a reason to hold off from what wumpus was suggesting, but we do need to make a determination on marco's sync bug.
19:37:49 <sipa> gmaxwell: ok, i will prioritize reviewing marco's situation
19:38:09 <wumpus> no one else reported it though
19:38:21 <wumpus> I've done tons of syncs with this code
19:38:23 <gmaxwell> I reported a similar one in the past, but we thought we fixed it.
19:38:32 <kanzure> is it reproducible?
19:38:36 <MarcoFalke> locally
19:38:57 <gmaxwell> and at the time that was hit by a number of people. some of those reports might have been people actually hitting what marco is hitting now.
19:39:00 <wumpus> but ok,anyhow, I guess we'll talk about this topic again next week
19:39:12 <gmaxwell> pft.
19:39:13 <wumpus> I've given uptrying to push for a release soon
19:39:18 <warren> MarcoFalke: are you able to reproduce it on other platforms?  what kind of build are you using (gitian vs local on fedora?)
19:39:22 <sipa> i hope 0.13.0 is released next week
19:39:32 <sipa> wumpus: ok, i'll push
19:39:34 <MarcoFalke> local on fedora
19:39:41 <gmaxwell> wumpus: don't be fatalistic, in the next day or so we'll determine if marco's issue is segwit only. If it is, then continue as you suggested.
19:39:42 <jonasschnelli> Do we delay then the final 0.13.0 only because of cobras post?
19:39:43 <MarcoFalke> Can we do this trouble shooting after the meeting?
19:39:55 <wumpus> sipa: thanks. I'm done being the person chasing people peonting at his watch for one
19:40:09 <sipa> wumpus: ok
19:40:17 <MarcoFalke> gmaxwell: I never saw it on main
19:40:27 <wumpus> so should this delay setting up the release schedule for 0.14?
19:40:53 <wumpus> that's kind of in limbo now, too
19:40:55 <MarcoFalke> imo no. 0.14 can be less features. less rcs
19:41:02 <gmaxwell> MarcoFalke: yes, but in three tries so far on rc3 I have not been able to reproduce your condition. So just because you didn't hit it on mainnet doesn't mean it isn't an issue there.
19:41:38 <gmaxwell> Keep in mind the behavior you're seeing would potentially cause a consensus divergence if it happened to miners. It is a high criticality issue unless we know conditions that reduce its risk.
19:41:54 <MarcoFalke> wumpus: There is some value in doing releases regular (c.f. firefox)
19:42:03 <anchow101> Can someone link me to the issue?
19:42:11 <wumpus> we have toruble doing the releases in the currently planne dschedule
19:42:18 <wumpus> I don't even want to think about more regular releases
19:42:20 <jonasschnelli> https://github.com/bitcoin/bitcoin/issues/8518
19:42:39 <sipa> wumpus: i disagree, your pushing to stick to a schedule was very valuable
19:42:49 <wumpus> firefox has a completely different situation
19:42:56 <gmaxwell> My impression is that we haven't really suffered any delay for 0.13 related to the general size. The rcs have not been horribly buggy or anything.
19:43:11 <sipa> wumpus: i understand if you're worn out about it, but that does not make it a bad idea
19:43:12 <sipa> we are still very close to on schedule for 0.13
19:43:27 <jonasschnelli> Yes. Thanks to wumpus'es RC buffer
19:43:47 <wumpus> sipa: sure! I'm still okay with the current release schedule (try to do a release every 6 months), but not in releases more often
19:43:52 <sipa> so i would vote we schedule 0.14 as soon as 0.13.0 is out
19:43:56 <jonasschnelli> I'm normally used to delay of *1.5 in software projects
19:44:27 <wumpus> jonasschnelli: agree, it could be much worse :)
19:44:39 <sipa> wumpus: it *used to be* much worse
19:44:47 <sipa> for us.
19:44:47 <jonasschnelli> 6 month seems to be perfectly fine. Just +6 month after the (possible) delayed last release
19:44:50 <wumpus> jonasschnelli: then again, we have time-based releases, we don't wait for any feature, just for bug fixes
19:45:14 <jonasschnelli> Yes. This seems to follow most agile development practices.
19:45:38 <wumpus> in any case, any other topics?
19:46:16 <zooko> Do y'all know about "binary transparency"?
19:46:25 <jonasschnelli> tell us
19:46:41 <btcdrak> zooko: please explain
19:46:42 <zooko> https://groups.google.com/forum/#!forum/binary-transparency
19:46:54 <zooko> It's a project from Ben Laurie, as a follow-on to "certificate transparency".
19:47:25 <zooko> There is a redundant set of servers which are claiming to do append-only logging of things published to them.
19:47:53 <zooko> When you publish a binary, you submit its hash to these servers.
19:48:16 <zooko> Clients should refrain from running a binary if the hash of that binary hasn't been broadcast by those servers.
19:48:24 <jl2012> proposed topic: BIP146.
19:48:40 <zooko> This is a detection technique, more than a prevention technique, for people distributing different binaries to different users.
19:49:07 <jonasschnelli> example: https://github.com/FreeBSDFoundation/binary-transparency-notes
19:49:13 <jl2012> It is proposed to do the LOW_S and NULLDUMMY softfork at the same time as segwit
19:50:07 <jonasschnelli> thanks zooko! I think we should take a closer look at the binary-transparency project.
19:50:13 <wumpus> thanks zooko, it sounds interesting, although I'm not sure it is on topic for anything in the meeting. I don't think it can solve the concrete problem of people running binaries without verifying anything at all, unless OSes would build in support for that
19:50:35 <wumpus> #topic BIP146
19:50:38 <btcdrak> #link https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki
19:50:47 <warren> (OSX does prevent running unsigned binaries unless the user disables a default option.)
19:51:09 <zooko> wumpus: good point. I think of it as primarily for detecting if someone is replacing binaries with alternate binaries, thinking that nobody will notice.
19:51:13 <wumpus> warren: yes, but that only checks whether the binary is signed, not by whom, and not whether it's the same file other people gt
19:51:17 <btcdrak> warren: but anyone can sign.
19:51:22 <zooko> But not for preventing people from running the alternate binaries so much, because like you say…
19:51:24 <wumpus> (the latter being the point of the binary transparency)
19:51:24 <btcdrak> jl2012: speak up
19:51:25 <warren> btcdrak: true
19:51:28 <jonasschnelli> warren: In which case you fully have to trust apple
19:51:34 <sipa> idea: LOW_S and NULLDUMMY have been nonstandard on the network for a long time, and do not appear on the chain (did anyone check they really do not appear?)
19:52:10 <sipa> together they would make *normal* transactions free from known malleability in segwit
19:53:15 <jl2012> NULLDUMMY is a bigger problem than LOW_S, as an attacker may put anything as the dummy value
19:53:41 <sipa> and they are both trivial
19:54:00 <adam3us> zooko i was thinking another way to do this is by committing to a sequence of R=kG values.in the public key, so P=H(R1,R2,...,Q) and define a mapping from version numbers to R value. now signing two different binaries for the same version will likely leak your private key.
19:54:22 <sipa> adam3us, zooko: can you wait until the meeting is ove
19:54:32 <kanzure> is the request re: bip146 for more review?
19:54:34 <btcdrak> for the record there was some discussion on the ML https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013006.html
19:54:43 <kanzure> what is the request about bip146 about?
19:54:54 <sipa> please discuss :)
19:55:14 <jonasschnelli> jl2012: Would the NULLDUMMY affect current mainnet transaction
19:55:14 <jl2012> LOW_S was discussed in last meeting but not NULLDUMMY
19:55:18 <btcdrak> ha! I think we discussed LowS already, it's just the addition of NULLDUMMY that is new.
19:55:20 <sipa> do we think it is doable in 0.13.1 / together with segwit
19:55:48 <jl2012> jonasschnelli: yes in the current BIP146
19:55:49 <btcdrak> sipa: I agree. it is a trivial addition.
19:56:45 <wumpus> yes, ack on LowS already, I don't know enough about NULLDUMMY to usefully comment
19:56:55 <btcdrak> 4 minute bell
19:57:11 <luke-jr> wumpus: NULLDUMMY is just "the ignored value popped by CHECKMULTISIG must be zero"
19:57:12 <sipa> nulldummy is liteeally: the ignored input to checkmultisig has to be the eempty vector
19:57:16 <jonasschnelli> So, worst case, there are some non-NULLDUMMY producers/miners out there that would need to adjust to the new rule?
19:57:38 <sipa> we should check if they are being included in the chain
19:57:40 <wumpus> okay that seems harmless and easy to check
19:57:44 <luke-jr> jonasschnelli: nobody sends these, so it's hard to know if anyone mines them
19:57:54 <btcdrak> it's already nonstandard
19:58:09 <wumpus> makes sense to include that with the LOWS cleanup then
19:58:12 <luke-jr> oh, and since all miners MUST be on 0.12.1 now, nobody should mine these
19:58:24 <sipa> why must they be on 0
19:58:29 <sipa> why must they be on 0.12.1?
19:58:29 <luke-jr> sipa: CSV?
19:58:36 <btcdrak> last softfork
19:59:02 <sipa> ah.
19:59:03 <btcdrak> since we didnt release a 0.11.x they upgraded to 0.12.1
19:59:28 <jonasschnelli> LOW_S & NULLDUMMY seems to make sense to include in the SW SF.
19:59:30 <btcdrak> I think luke-jr's grammar has a bug or two :-p
19:59:41 <wumpus> let's not have a new thing creep into SW every week though :p
19:59:43 <BlueMatt> I'm not a huge fan of bundling them :/
19:59:43 <luke-jr> btcdrak: ?
19:59:55 <BlueMatt> though not against a separate sf that is also in 0.13.1, though thats also gross
20:00:10 <btcdrak> BlueMatt: it's a trivial one liner (modulo tests)
20:00:10 <luke-jr> the only reason to bundle IMO is if we want to add new non-VERIFY opcodes to segwit.
20:00:19 <BlueMatt> btcdrak: I'm aware, doesnt mean I like it
20:00:21 <wumpus> we discussed that last week BlueMatt, the disadvantage of not bundling is that no one would care about a separete softfork for them
20:00:23 <wumpus> they're just a cleanup
20:00:27 <luke-jr> but LOWS/NULLDUMMY are just softforks, so no need to bundle IMO
20:00:35 <luke-jr> (no harm either)
20:00:47 <BlueMatt> wumpus: ok, fair enough, though in same version...anyway, I'll hold my tounge
20:01:00 <wumpus> #endmeeting