< phantomcircuit>
gmaxwell: things have been a bit lax on that front recently actually
< phantomcircuit>
personally i strongly prefer that each commit in a pr is itself functional
< phantomcircuit>
we've had a few where that's a commit at the end which fixes a bug in the first commit
< jcorgan>
it is nice to have all commits compile nicely to be able to use git bisect
< instagibbs>
I kind of like to see changes as they are worked on personally, with cleanup at the end. Often force pushes means I can't really track what has changed super easily. But I'm sure that's my lack of foo
< cfields>
phantomcircuit: looking at the rpc tests, i'm not seeing how the caches don't stomp eachother
< phantomcircuit>
instagibbs: the idea is that you do the normal thing with cleanup and then before merge rebase such that the overall change is identical
< sipa>
phantomcircuit: every commit must compile and run tests
< sipa>
phantomcircuit: that's not something a manually verify when reviewing, but i won't ack a PR if i know it isn't the case
< phantomcircuit>
sipa: sure... but there's things where they compile and pass tests and we know them to be broken
< jonasschnelli>
For the binary verification problem, we should have a verification process in Bitcoin-Qt/bitcoin-cli (or maybe an additional tool) that can verify a downloaded binary by downloading the gitian.sigs
< jonasschnelli>
It would require to also produce ECDSA sigs per assets file
< jonasschnelli>
And store ECDSA pubkeys of each gitian builder in our bitcoin/bitcoin git
< wumpus>
the idea with adding ecdsa signatures in addition to gpg signatures, which can be easier to verify by an external program that doesn't want to embed the entire gpg shebang
< wumpus>
yes
< wumpus>
a user friendly gitian verifyer could be useful
< jonasschnelli>
Built into an already verified binary would be nice
< wumpus>
well it doesn't so much need to be part of the binary, could be a separate tool part of the distribution
< jonasschnelli>
Once you have verified with the gitian-verifier, you have a trusted chain of updates
< jonasschnelli>
Yes. Could be seperated...
< jcorgan>
it would also be useful to have the current release signature depend on the previous one, to form a hash chain of sorts
< jonasschnelli>
but should be built from the git repo where the ECDSA pubkeys are and also built over gitian
< wumpus>
jonasschnelli: agreed
< wumpus>
jcorgan: does that improve security? attackers can just as easily include a link to the previous signature
< jl2012>
I suspect that's related to the low s patch by sipa
< wumpus>
"Looks like with the reduced delay from fa2d68f, the nodes sync up before the txns all make it into the wallet"
< wumpus>
according to cfields
< sipa>
that failing segwit test was introduced in #8489 iirc
< btcdrak>
i think Cory nailed it
< jl2012>
Without his patch, bip164-p2p.py will fail
< sipa>
btcdrak, wumpus: but if shorter delays trigger errors, the tests are wrong
< sipa>
they shouldn't rely on timings
< wumpus>
that's a good point, but we need to do something to make the travis failures go away, that could be fixing the tests, but reverting the timeout change may be quicker
< wumpus>
if fixing the tests is straightforward (it's always those two) then I'm all for fixing them immediately, of course
< wumpus>
the alternative would be temporarily disabling them in travis
< jl2012>
By the way, they never fail on my mac
< wumpus>
but I prefer reverting the timeout change to that, as at least something gets tested then
< wumpus>
jl2012: I can't reproduce it locally either
< MarcoFalke>
wumpus: Agree on temp. revert. I will try to look into this now but there is no eta for tha acutal fix
< GitHub68>
bitcoin/master 35f64e4 Wladimir J. van der Laan: Revert "[qa] Adjust timeouts for micro-optimization of run time"...
< MarcoFalke>
Thanks
< GitHub32>
[bitcoin] MarcoFalke opened pull request #8536: [WIP] [qa] Adjust timeouts for micro-optimization of run time (master...Mf1608-qaOptSync) https://github.com/bitcoin/bitcoin/pull/8536
< GitHub188>
bitcoin/master b213535 Wladimir J. van der Laan: Squashed 'src/secp256k1/' changes from 6c527ec..7a49cac...
< GitHub188>
bitcoin/master 0237096 Wladimir J. van der Laan: Merge commit 'b2135359b3ad37cf2ac09b008079ddb237eff2c9'
< GitHub188>
bitcoin/master 8250de1 Pieter Wuille: Merge #8453: Bring secp256k1 subtree up to date with master...
< GitHub62>
[bitcoin] sipa closed pull request #8453: Bring secp256k1 subtree up to date with master (master...2016_08_update_secp256k1) https://github.com/bitcoin/bitcoin/pull/8453
< GitHub103>
[bitcoin] laanwj opened pull request #8540: qt: Fix random segfault when closing "Choose data directory" dialog (master...2016_08_qt_choosedatadir_crash) https://github.com/bitcoin/bitcoin/pull/8540
< cfields>
jonasschnelli: ping. what's the easiest way to atomically retrieve the NodeId for the selected row in the peertable?
< cfields>
jonasschnelli: for context, I'm moving the ban functionality around a bit, and to prevent ambiguity, i'd like to ban based on NodeId rather than address
< cfields>
as a quick hack, I impelemented it by adding the NodeId as the first column in the table, so there's a quick path for lookup. But I'm not sure everyone would agree with the usefulness there.
< btcdrak>
Regarding MS/APPL codesigning certificates. What about getting one issued in the name of MIT DCI?
< Chris_Stewart_5>
In a merkle block it says we should never have two nodes with the same child hashes, however in a merkle tree if we have a an odd amount of txs we duplicate the last txid
< Chris_Stewart_5>
isn't this conflicting?
< Chris_Stewart_5>
'However, if you find a node whose left and right children both have the same hash, fail. This is related to CVE-2012-2459.' wrt to Merkle blocks
< sipa>
Chris_Stewart_5: if you have *two* subnodes, their hashes should be different
< sipa>
because if that was the case, it would be indistinguishable from the case where there was only one subnode
< jonasschnelli>
cfields: could you solve the Qt table nodeid problem?
< cfields>
jonasschnelli: no further along, wanted to get your preferred approach first
< jonasschnelli>
okay... let me have a loog
< jonasschnelli>
look
< cfields>
jonasschnelli: great, thanks
< cfields>
jonasschnelli: i can point you to my changes, if you'll promise to ignore the stuff happening around it :)
< cfields>
(i'm trying to break out this part for its own PR)
< sipa>
kanzure: its twitter handle is therealping
< wumpus>
kanzure: it comes from gmaxwell, who the offical meeting-pinger, and he is authenticated with freenode
< btcdrak>
how do we know freenode is still free?
< wumpus>
because otherwise it would be renamed to restrictednode
< luke-jr>
jonasschnelli: a tool would be nice, but there is no reason for it to be internal
< jonasschnelli>
there are
< jonasschnelli>
(to be covered under gitian)
< wumpus>
#topic core internal binary signing and verification tool
< luke-jr>
you can gitian-build things besides Bitcoin
< jonasschnelli>
I propose to add to cli tools to the bitcoin-core package
< kanzure>
off-topic, but does anyone know the status of deterministic debian efforts?
< jonasschnelli>
bitcoin-core-verify and bitcoin-core-sign
< jonasschnelli>
The later will not be shipped
< 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)
< jonasschnelli>
bitcoin-core-verify will list valid signatues of devs by listing devs name.
< 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
< btcdrak>
jonasschnelli I think it needs to be GUI for wider adoption.
< jonasschnelli>
Yes. It would be a Qt tool for one major reason
< gmaxwell>
Please don't do design in the meeting.
< jonasschnelli>
https downloads
< jonasschnelli>
gmaxwell: okay. fair enought...
< gmaxwell>
I'm planning on having someone work on that.
< btcdrak>
jonas is already building something afaik
< wumpus>
yes it needs https support to get at the signatures from github
< jonasschnelli>
Yes. But happy to pause.
< gmaxwell>
If it does https I will nak it so hard keys will fall of the keyboard.
< jonasschnelli>
Qt would have https support built in
< jonasschnelli>
the gitian sigs come over https
< gmaxwell>
We _cannot_ ship some downloading tool that is going to require frequent CVEs itself.
< wumpus>
it's not a downloading tool
< jonasschnelli>
either with git or with https
< MarcoFalke>
So how do you verify bitcoin-core-verify?
< wumpus>
just a verification tool
< wumpus>
MarcoFalke: it'd be part of the distribution
< btcdrak>
no need for https when you have cryptographic verification
< gmaxwell>
What btcdrak said.
< jonasschnelli>
I guess even if https is broken, nobody can upload valid EC sigs
< btcdrak>
https _is_ broken
< jonasschnelli>
https is required to download from github I guess
< wumpus>
well if you can get information from github through http that would work too
< jonasschnelli>
Yes. TLS is not required for security.
< luke-jr>
the git protocol isn't encrypted I think
< btcdrak>
actually I think it's impossible to fetch from github without https, you'd have to use the git:// ptrotocol
< wumpus>
you seriously wouldn't want to implement the git protocol
< cfields>
wumpus: distribution == our release? Or OS?
< jonasschnelli>
he. yes. no git:// please
< wumpus>
cfields: yes, our releases
< 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
< 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
< jonasschnelli>
somewhere where it could be used in cpp source code (probably in a header)
< wumpus>
well the gpg keys are already in the respository
< jonasschnelli>
this would allow to build a "trusted-chain" of bitcoin-core binaries
< 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?
< 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.
< jonasschnelli>
cfields: Sure. Thats always possible
< btcdrak>
just confirmed github forces https redirection
< MarcoFalke>
So bitcoin-core-verify checks the release, but is part of the release... Isn't this circular?
< wumpus>
cfields: yes, it only works for chaining, if the first link in the chain is broken it solves nothing...
< jonasschnelli>
But not if you have verified the first download (assume with gitian verify), then verify with the new tool
< 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.
< wumpus>
MarcoFalke: it'd be used to check the *next* release downloaded
< kanzure>
bikeshedding for a sec, but "next" seems important enough to be part of the name ;)
< jonasschnelli>
people could still gitian-verify our new verification tool
< wumpus>
MarcoFalke: having it verify itself would be sillly
< cfields>
right.
< 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 :) )
< MarcoFalke>
ok, I see
< kanzure>
s/compromised/revoked?
< kanzure>
+revoked, at least?
< cfields>
kanzure: +1. that wasn't clear to me until now :)
< jonasschnelli>
key revoking is possible over our release-management
< wumpus>
kanzure: well it be N-out-of-M ,so could tolerate some revoked or compromised keys Iguess..
< gmaxwell>
kanzure: without an uncensorable communications medium or expiration there is no sense for revocation.
< kanzure>
hm.
< wumpus>
then they'd just be removed in the next release
< 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.
< gmaxwell>
n of m is close to an uncensorable communicatoins medium subject to an honest threshold assumption.
< 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
< btcdrak>
gmaxwell: what if you got a good release, but were later infected with malware which changed the verifier tool?
< gmaxwell>
btcdrak: oh well.
< wumpus>
btcdrak: if you are infected, it's end of story really
< wumpus>
btcdrak: it can already steal your coins
< jonasschnelli>
indeed
< gmaxwell>
btcdrak: if you're infected with malware you're hosed at that point.
< sipa>
btcdrak: you are eaten by a frue
< sipa>
*grue
< jonasschnelli>
you can't protect from malware on that layer
< kanzure>
perhaps the malware would be kind enough to at least inform you of your infection
< wumpus>
that's another story entirely (hardaware wallets / security modules)
< jonasschnelli>
impossible
< jonasschnelli>
At least, the EC binary sig tool would allow hardware wallets to sign the binaries
< wumpus>
that's an interesting idea
< jonasschnelli>
(though you can do this with GPG smartcard)
< wumpus>
there are smartcards running GPG?
< jonasschnelli>
Yes.
< wumpus>
is there some micro-gpg implementation?
< btcdrak>
yes
< jonasschnelli>
but a big mess
< gmaxwell>
A number of people around here use gpg via yubikey3.
< wumpus>
yeah...
< btcdrak>
petertodd has one with pin entry. sounds like he's at the cash register when sending emails
< gmaxwell>
wumpus: it's not really gpg on the smartcard, it's a rsa signer on a stick. :)
< btcdrak>
Ledger Nano S could be programmed to do signing. It also has a GPG module coming. It uses an ST31 secure element afaik
< wumpus>
gmaxwell: oh right, just the rsa signing, the ugly thing about gpg is all the packet parsing and interpretation etc
< instagibbs>
btcdrak, I have a pgp key from mine
< instagibbs>
(just playing around with it)
< gmaxwell>
There is a terrible complex standard for supporting it. In any case, it's a good thing to have.
< wumpus>
same problem as TLS really, the crypto algorithms themselves are reasonably elegant and bug-free, but all the parsing mess around it...
< kanzure>
should we move on?
< wumpus>
anyhow, I think we agree that we'd want to use secp256k1 signatures
< wumpus>
if we can agree on one thing
< 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.
< jonasschnelli>
Okay. I'll work on a short design and post it to bitcoin-core-dev ML
< wumpus>
btcdrak: I just use old computers, but I agree that's the more practical option :-)
< kanzure>
should we be complaining about hkp to the bitcoin.org people?
< gmaxwell>
jonasschnelli: can you spend some time and talk to mr or sipa before you post?
< jonasschnelli>
gmaxwell: Yes. Will do... thanks for offering that.
< wumpus>
kanzure: hkp?
< kanzure>
HPKP
< kanzure>
public key pinning
< btcdrak>
they also dont enforce HSTS
< kanzure>
does bitcoincore.org?
< btcdrak>
yes
< kanzure>
both?
< jonasschnelli>
Another short topic proposal that is near to the signing: code-signing (OSX/WIN).
< wumpus>
sure, why not, if anything can be done to improve site security we should encourag that
< btcdrak>
no, just HSTS and certificate origin
< gmaxwell>
HPKP is pretty easy to mess up. TBH it's a lot more useful for parties that are their own CA.
< btcdrak>
sorry, i mean authenticated origin pulls
< btcdrak>
HSTS is important to prevent https downgrade attacks imo
< kanzure>
okay well i'm eagerly awaiting for the delivery of the complimentary ips containers
< wumpus>
yes, HSTS is important, and trivial to implement
< wumpus>
never even heard of HPKP before
< kanzure>
jonasschnelli: iirc there was some detail about code signing and windows - something about a buggy state?
< kadoban>
HPKP is key-pinning. It's to prevent attacks like rogue CAs
< wumpus>
#topic code-signing (OSX/WIN)
< jonasschnelli>
We still sign with "Bitcoin Foundation"
< 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.
< jonasschnelli>
On OSX, its not very visible... on Windows I guess a bit more.
< wumpus>
kadoban: then gmaxwell's comment makes sense - sounds like a risky thing to do if you're depenent on someone else's CA
< jonasschnelli>
Question: we should try to get new certificates for OSX/Win in the name of "Bitcoin Core".
< gmaxwell>
(I'm not saying that it shouldn't be done for that site, just that it's not a no brainer.)
< jonasschnelli>
The question is, if we should. :)
< instagibbs>
jonasschnelli, that's a statement :P
< btcdrak>
jonaschnelli: that would be great. do you have a company that can do it?
< 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.
< 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
< wumpus>
btcdrak: sure, I could paste sha256sums.asc into the announcement email
< luke-jr>
jonasschnelli: cfields was looking into this, but I am not sure his status
< kadoban>
Like, your website is unusable for 6 months screwed.
< btcdrak>
wumpus: thank you.
< wumpus>
kadoban: right - what if you want to switch CAs for some reason
< wumpus>
#action sha256sums in release email
< jonasschnelli>
btcdrak: I have serval code signing certificates.. but we don't want to use these company names...
< 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.
< 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)
< 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
< wumpus>
(do note that release emails are signed with *my* key, not the release signing key)
< sipa>
sorry i fell asleep
< gmaxwell>
Thats a sign to move on. :)
< 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
< instagibbs>
brainstorming can continue later imo
< 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
< 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
< luke-jr>
kanzure: I think they re-introduced them
< 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)
< wumpus>
yes, github has the option to host release binaries
< kanzure>
luke-jr: got it
< wumpus>
but having the binaries in more places means more places to check wether they are compromised too
< anchow101>
Why not host binaries on GitHub and move completely off of bitcoin.orgs system
< btcdrak>
wumpus: we should do it there as a mirror at least.
< wumpus>
also it gives another reason to want to compromise our github
< * jonasschnelli>
is not sure if we should place the binaries on the same host at the source code
< wumpus>
I'm not comfortable with everyting in one place
< sipa>
let's use sourceforge *ducks*
< wumpus>
yea, exactly, feels like putting a lot of eggs inone basket
< wumpus>
hah
< * jonasschnelli>
stabs sipa
< 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.
< gmaxwell>
you don't think github isn't fully compromised already, come one? :)
< gmaxwell>
er come on
< 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.
< wumpus>
well at least sudden code changes are fairly detectable
< wumpus>
(and we sign all top-level commits)
< gmaxwell>
please can we move on?
< anchow101>
What about Amazon s3 for binary hosting?
< wumpus>
so there is very little gain in compromising our github right now
< btcdrak>
The issue is less about being compromised and more about early warning.
< wumpus>
any other topics?
< instagibbs>
0.13.0 final?
< sipa>
0.13.0?
< btcdrak>
having multiple places makes it more likely a compromise would be spotted earlier
< wumpus>
btcdrak: I disagree; it doesn't solve the problem of peopel not verifying at all
< wumpus>
#topic 0.13.0
< 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.
< instagibbs>
kanzure, greg told me it was some academic paper's work
< 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
< MarcoFalke>
I think the last doc change was merged. We can start gitian after the meeting?
< 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.
< MarcoFalke>
Or did anyone hear of critical problems?
< btcdrak>
MarcoFalke: it's all good from what I can see.
< gmaxwell>
kanzure: I'll provide citations after the meeting.
< instagibbs>
there was one report of stalled segwit ibd on testnet
< 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
< instagibbs>
but not sure if that's one-off or what
< gmaxwell>
instagibbs: I've been trying to reproduce marco's stalls with testnet. synced and caught up a few hosts.. so far nothing.
< jonasschnelli>
wumpus: agree, that was a imprudent move..
< sipa>
gmaxwell: do you have multiple header chains extending your active branch?
< btcdrak>
wumpus: maybe tag on Friday evening, let the gitian builders process over the weekend and we can release on Monday/tues/
< MarcoFalke>
I can upload my 8.5 gig datadir *ducks*
< cfields>
wumpus: tag it as 0.13.0.1 :)
< gmaxwell>
sipa: no I've just tried varrious things. I thought we already fixed the big with multiple header chains?
< wumpus>
cfields: lol :)
< sipa>
gmaxwell: i thought so too
< btcdrak>
cfields: lol
< instagibbs>
gmaxwell, me neither *shrug*
< MarcoFalke>
Able to reproduce consistently here, but this is something for 13.1
< sipa>
gmaxwell: but that was something i noticed in MarcoFalke's roc output
< sipa>
rpc
< gmaxwell>
MarcoFalke: if you have a sync failure that is reproducably consistently it may be a release blocker.
< btcdrak>
you mean 0.13.1
< 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.
< gmaxwell>
Please can we stop with the prior topic?
< btcdrak>
wumpus: so tag friday evening, and release ~monday?
< sipa>
sounds fine be me
< wumpus>
any rationale for friday evening, and not, right now?
< sipa>
also fine by me
< 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?
< gmaxwell>
I am concerned that we have a reproducable candidate release blocker.
< gmaxwell>
we should become confident that it's segwit only.
< wumpus>
bah
< btcdrak>
wumpus: to give time for the cobra announcement to fade
< gmaxwell>
perhaps by having marco backup his state, and then disable segwit.
< wumpus>
I'm about to give up on 0.13 completely :p
< wumpus>
and focus on 0.14 from now on
< sipa>
wumpus: what, and release 0
< btcdrak>
13 is unlucky number!
< sipa>
qe.1 instead?
< wumpus>
btcdrak: yes. exactly.
< kanzure>
one rationale for not right now is to give time for review on bitcoincore.org pull 199
< btcdrak>
^
< kanzure>
so maybe like... whatever average review time is. heh.
< wumpus>
gitian building takes time too
< 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.
< instagibbs>
wumpus, skip 0.12.1, go straight to 1.0, come on
< wumpus>
we can delay the uploading until your blog post is finished, sure
< wumpus>
instagibbs: skipping numbers doesn't work if we don't feel confident about the code, though
< 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.
< sipa>
gmaxwell: ok, i will prioritize reviewing marco's situation
< wumpus>
no one else reported it though
< wumpus>
I've done tons of syncs with this code
< gmaxwell>
I reported a similar one in the past, but we thought we fixed it.
< kanzure>
is it reproducible?
< MarcoFalke>
locally
< 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.
< wumpus>
but ok,anyhow, I guess we'll talk about this topic again next week
< gmaxwell>
pft.
< wumpus>
I've given uptrying to push for a release soon
< warren>
MarcoFalke: are you able to reproduce it on other platforms? what kind of build are you using (gitian vs local on fedora?)
< sipa>
i hope 0.13.0 is released next week
< sipa>
wumpus: ok, i'll push
< MarcoFalke>
local on fedora
< 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.
< jonasschnelli>
Do we delay then the final 0.13.0 only because of cobras post?
< MarcoFalke>
Can we do this trouble shooting after the meeting?
< wumpus>
sipa: thanks. I'm done being the person chasing people peonting at his watch for one
< sipa>
wumpus: ok
< MarcoFalke>
gmaxwell: I never saw it on main
< wumpus>
so should this delay setting up the release schedule for 0.14?
< wumpus>
that's kind of in limbo now, too
< MarcoFalke>
imo no. 0.14 can be less features. less rcs
< 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.
< 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.
< MarcoFalke>
wumpus: There is some value in doing releases regular (c.f. firefox)
< anchow101>
Can someone link me to the issue?
< wumpus>
we have toruble doing the releases in the currently planne dschedule
< wumpus>
I don't even want to think about more regular releases
< sipa>
wumpus: i disagree, your pushing to stick to a schedule was very valuable
< wumpus>
firefox has a completely different situation
< 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.
< sipa>
wumpus: i understand if you're worn out about it, but that does not make it a bad idea
< sipa>
we are still very close to on schedule for 0.13
< jonasschnelli>
Yes. Thanks to wumpus'es RC buffer
< 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
< sipa>
so i would vote we schedule 0.14 as soon as 0.13.0 is out
< jonasschnelli>
I'm normally used to delay of *1.5 in software projects
< wumpus>
jonasschnelli: agree, it could be much worse :)
< sipa>
wumpus: it *used to be* much worse
< sipa>
for us.
< jonasschnelli>
6 month seems to be perfectly fine. Just +6 month after the (possible) delayed last release
< wumpus>
jonasschnelli: then again, we have time-based releases, we don't wait for any feature, just for bug fixes
< jonasschnelli>
Yes. This seems to follow most agile development practices.
< wumpus>
in any case, any other topics?
< zooko>
Do y'all know about "binary transparency"?
< jl2012>
It is proposed to do the LOW_S and NULLDUMMY softfork at the same time as segwit
< jonasschnelli>
thanks zooko! I think we should take a closer look at the binary-transparency project.
< 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
< warren>
(OSX does prevent running unsigned binaries unless the user disables a default option.)
< 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.
< 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
< btcdrak>
warren: but anyone can sign.
< zooko>
But not for preventing people from running the alternate binaries so much, because like you say…
< wumpus>
(the latter being the point of the binary transparency)
< btcdrak>
jl2012: speak up
< warren>
btcdrak: true
< jonasschnelli>
warren: In which case you fully have to trust apple
< 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?)
< sipa>
together they would make *normal* transactions free from known malleability in segwit
< jl2012>
NULLDUMMY is a bigger problem than LOW_S, as an attacker may put anything as the dummy value
< sipa>
and they are both trivial
< 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.
< sipa>
adam3us, zooko: can you wait until the meeting is ove
< kanzure>
is the request re: bip146 for more review?
< luke-jr>
wumpus: minor detail, but I noticed the RCs were "0.13.0" internally; was the previous 0.12.99-ish scheme abandoned intentionally?
< wumpus>
luke-jr: IIRC rcs have always been the version internally
< wumpus>
rcs have never been 0.X.99
< warren>
luke-jr: IIRC rc's always were internally the version with "rcX" appended
< wumpus>
yes
< sipa>
long ago rcs were literally release candidates: the latest rc binary literally became the final binary
< wumpus>
right
< sipa>
though we'vdle gone through so many schemes that i can't say i'm sure anymore :)
< wumpus>
I've been entirely consistent the last few major releases
< * luke-jr>
questions his memory
< warren>
I joined around 0.8 and it was consistent since then at least.
< sipa>
the last release i did was 0.3.23
< gmaxwell>
So part of why I was deflecting on the endless rathole of the bitcoin.org stuff is because I had more to say that that I didn't fit in the scope of the meeting, and we had other things to accomplish that unfortunately we didn't have time for. :(
< gmaxwell>
Among the other things I wanted to say was this:
< gmaxwell>
Kanzure, achow101. Regarding your public comments on the bitcoin.org notice.
< gmaxwell>
I think you've taken the wrong position, by pounding on process.
< gmaxwell>
If someone with privleged access is aware of a serious concern and believes
< gmaxwell>
they urgently need to tkae unilateral action to make a minimal statement
< gmaxwell>
simply to _notify_ people of the risk and encourage following an existing
< gmaxwell>
process to mitigate, they should do so. Pounding on procedure comes across
< gmaxwell>
as a denial which I don't believe you had the information to make.
< gmaxwell>
(and in fact, since achow101 did not talk to all the major developers, I
< gmaxwell>
_know_ you didn't have the information needed to make the claim you made.)
< gmaxwell>
And yes, someone doing something like that unilaterally is going to cause
< gmaxwell>
some pain. But that is okay, the security process should favor risk
< gmaxwell>
reduction, over creating a bit of pain here and there.
< gmaxwell>
[In fact, both of your messages could come across as expressing the view
< gmaxwell>
that we are skeptical that HTTPS MITM attacks are even a risk, when in fact
< gmaxwell>
we _know_ they are well documented to happen with some regularity.]
< gmaxwell>
We are at no real risk of tiring people out with a flood of false positives,
< gmaxwell>
otherwise I would take a different position, perhaps.
< gmaxwell>
Cobra isn't great at public relations, sure, but I notice none of the people
< gmaxwell>
complaining opened PRs to improve the language. His notice states the
< gmaxwell>
concern, the believed targets, and contains specific, conservative,
< gmaxwell>
mitigation instructions, it could be a lot worse.
< kanzure>
i hadn't considered some of that perspective, in particular that there is a benefit to being quick to make alerts. and downplaying alerts is probably not healthy either because it to some extent discourages others from making them in the future a little bit more.
< kanzure>
also, it's possible that achow101 was reading into my overly strong language. his comment was made after mine by a bit, after all.
< gmaxwell>
I don't think it's a big deal, but just like I'd encourage cobra to be more careful with presentation, I'd like to also ask y'all to try for a different handling here. :)
< kanzure>
yeah, got it.. plus, in rtrospect, it does seem a little silly that my first concern in that comment text is about process concerns... which is trivial for others to mistakenly read as "security concern denial". during incident response some other topics should probably be higher priority than that.
< achow101>
gmaxwell: sorry about that. I was mostly reacting against the conspiracy theories and other idiotic claims that r/btc'ers make
< gmaxwell>
yea, that stuff was halarious.
< kanzure>
this seems like a good opportunity to show off a favorite tool of mine, https://mitmproxy.org/
< * luke-jr>
ponders hacking his email client to refuse to send to the old MLs :|
< kanzure>
send to both
< luke-jr>
kanzure: if I knew it was to the old ML, I'd just change it to the new one :P
< cfields>
jonasschnelli: i think i've decided against banning by id, as it introduces a possible failure if a node manages to disconnect just after you click "ban".
< cfields>
jonasschnelli: i can still PR the id addition to the table though, if you'd like
< gmaxwell>
Someone in #bitcoin had 17 BTC stolen from them today because they came for tech support (their wallet was a couple years behind and they were wondering why they hadn't seen a payment yet) and someone wumpus and I were talking to, "moldish", pulled them into PM and got them to do a dumpprivkey. :(
< midnightmagic>
Is the money actually stolen?
< gmaxwell>
I believe there address was 1K35Q6BEkCvhE2k7SUeZXKDFTtZACEfNcn and its been cleaned out.
< BlueMatt>
ouch
< BlueMatt>
thats a bunch of cash, too
< luke-jr>
ugh, maybe we need more red lights on the debug window? :/
< gmaxwell>
We could make the dumpprivkey response include a # This is secret data which will allow anyone who knows it to steal your coins.
< Lauda>
+1
< luke-jr>
sounds easier than it probably is. stupid JSON has no comments
< gmaxwell>
I think that RPC doesn't return json?
< gmaxwell>
wait thats dumb, I guess it does.
< gmaxwell>
:-/
< luke-jr>
I suppose we could add some non-standard stuff to UniValue and strip it over real RPC (but not debug console)
< gmaxwell>
ugh. or make the debug console do something special.
< luke-jr>
but there's other unsafe things too - like importprivkey..
< luke-jr>
and a comment couldn't work for that case
< gmaxwell>
Yes, and I've seen someone robbed via that too. But it's less unsafe, I think.
< luke-jr>
is there anything not-unsafe normal users would ever use the debug window for? what's the downside of a generic red-flag in the initial message we have?
< gmaxwell>
lots of pure status things.
< gmaxwell>
getinfo/getchaintips/getmempoolinfo
< gmaxwell>
the only export/import privatekey and signraw transaction and sigmessage are really signficantly unsafe... and sigmessage is pretty hard to abuse, presuming the thing you have to sign is sensibly constructed.