< phantomcircuit>
wumpus, is there anything blocking 8704 ?
< BlueMatt>
phantomcircuit: yes, lack of review
< phantomcircuit>
i can fix that
< BlueMatt>
not by yourself
< phantomcircuit>
BlueMatt, plz review 8704
< bitcoin-git>
[bitcoin] benma opened pull request #9895: Turn TryCreateDirectory() into TryCreateDirectories() (master...appinitmain) https://github.com/bitcoin/bitcoin/pull/9895
< phantomcircuit>
BlueMatt, you think 8704 needs an rpc test?
< BlueMatt>
probs
< phantomcircuit>
im thinking it doesn't beyond something that tests for true/false and 0/1/2 all not returning an error
< phantomcircuit>
like not something that checks the output more than it's being checked already
< BlueMatt>
i dunno i havent looked at it
< phantomcircuit>
the only thing crazy about it is that it's allowing the second parameter to be any of
< phantomcircuit>
true/false/0/1/2
< phantomcircuit>
iono
< luke-jr>
phantomcircuit: 3+ are valid too IIRC? :P
< phantomcircuit>
luke-jr, true
< phantomcircuit>
but maybe it shouldnt be?
< * luke-jr>
shrugs
< luke-jr>
some day we'll wish we did what I originally suggested with {"block": "description level", "txn": "description level"} ;)
< luke-jr>
(back in 2012 or something, dead and buried topic now)
< phantomcircuit>
luke-jr, description level?
< phantomcircuit>
oh you mean so you can specify how verbose you want an individual transaction to be?
< luke-jr>
phantomcircuit: iirc it was either "hex" or "object". maybe one other option I forget
< cfields>
wumpus: for backlog, i re-ran my gitian build until my results matched yours and jonasschnelli's. I've submitted a PR to (I belive) fix the determinism issue. See #9891.
< cfields>
Since everyone is getting one of those two results, I'm going to go ahead and push sigs for one of them. fanquake/achow101, You guys should be able to build a few times and eventually get the same result. Sorry :(. Got to choose one of 'em.
< sipa>
cfields: so you suggest we don't do an rc4 but instead iterate building until everyone matches?
< achow101>
cfields: which hash are you using?
< cfields>
sipa: since everyone's getting one of two results, and that's been the case ever since rc1, I have no problem with calling it deterministic-ish
< cfields>
sipa: granted, I'd feel much better with confirmation that 9891 actually fixes the issue.
< cfields>
achow101: !Hash(achow101)
< achow101>
cfields: I can probably have my machine just run the build 50 times with 9891 applied and see what the results are
< cfields>
achow101: yea, that would be fantastic if you could
< sipa>
cfields: demideterminstic :)
< cfields>
achow101: see the commit message. I managed to produce differing results while manually hammering ld over and over. The change fixed it for me. If I found the right issue, it's basically tied to the amount of cpu's in your machine
< cfields>
achow101: it was a social engineering trick to find out what hardware everyone's running. The fact that I always got the same result is sad for me, i guess :)
< cfields>
sipa: hah
< achow101>
cfields: so you have hardware with less cpu :)
< cfields>
achow101: it's not the size of the cpu, it's the tdp...
< cfields>
achow101: obviously if you build a branch with that commit you won't match either result, but as long as it's self-consistent, that's enough
< achow101>
ok. I'll pull it into another branch and just run it overnight and see what the results are
< cfields>
achow101: that would be really helpful. Thanks!
< cfields>
gitian builders: detached sigs for 0.14.0rc3 have been pushed. Note that there are 2 possible build results for osx. A PR has been submitted to (hopefully) fix that.
< cfields>
just repeating in case anyone missed the above. Headed to bed, nnite.
< fanquake>
cfields nice job figuring that out!
< luke-jr>
^ +1
< bitcoin-git>
[bitcoin] benma opened pull request #9897: AppInitMain: split initialization of Connman into a new function (master...connman) https://github.com/bitcoin/bitcoin/pull/9897
< * luke-jr>
wonders which signed OSX actually verifies
< wumpus>
should probably send a notification to the mailing list this time
< wumpus>
for rc2 I didn't bother as there was a critical issue so soon after tagging it
< luke-jr>
I assume we'll have a rc4 with the determinism fixed (and ideally manpages too)?
< wumpus>
just fixing the determinism doesn't require a rc4 imo, as it just normalizes what some gitian builders were already doing
< wumpus>
not sure what you mean about manpages, is there an issue open about that?
< wumpus>
anyhow if no new critical issues come up with rc3 I'd be strongly for marking it 0.14.0 final
< wumpus>
we've spend too much work crunching to fix issues last minute for this release, and we can almost make the projected March 1 release date, it'd be a waste to let it slip on small issues
< wumpus>
I mean the network issues were looking quite hopeless at some point and we managed to squash them all in time, that's neat
< wumpus>
luke-jr: indeed it's not, just a makefile change and only affecting the selection of files to be installed at that - it will have zero influence on the packages as there we install everything. seems like something we can slip in without a new rc
< bitcoin-git>
bitcoin/master 48faf0b Pieter Wuille: Abstract out BlockAssembler options
< bitcoin-git>
bitcoin/master 277b472 Pieter Wuille: Run miner_tests with fixed options
< bitcoin-git>
bitcoin/master cbdb473 Wladimir J. van der Laan: Merge #9868: Abstract out the command line options for block assembly...
< bitcoin-git>
[bitcoin] laanwj closed pull request #9868: Abstract out the command line options for block assembly (master...assembleroptions) https://github.com/bitcoin/bitcoin/pull/9868
< bitcoin-git>
bitcoin/master 224e6eb Wladimir J. van der Laan: util: Specific GetOSRandom for Linux/FreeBSD/OpenBSD...
< bitcoin-git>
bitcoin/master aa09ccb Wladimir J. van der Laan: squashme: comment that NUM_OS_RANDOM_BYTES should not be changed lightly
< bitcoin-git>
bitcoin/master 7cad849 Wladimir J. van der Laan: sanity: Move OS random to sanity check function...
< bitcoin-git>
[bitcoin] laanwj closed pull request #9821: util: Specific GetOSRandom for Linux/FreeBSD/OpenBSD (master...2017_02_osrandom) https://github.com/bitcoin/bitcoin/pull/9821
< cfields>
wumpus: heh.. i wonder if that's somehow related to travis and the aws outage
< cfields>
considering that travis was happy with it in the PR, and gitian builds are fine
< wumpus>
yes exactly, the PR was fine
< wumpus>
is the qt compilation somehow dependent on the architecture it's compiled on? (would be unlikely, but ok)
< wumpus>
I don't understand where the avr mess suddenly comes from. Could also be that trusty updated their compiler/toolchains
< wumpus>
avx*
< cfields>
wumpus: yea, it does cpu detection, and there were bugs up until 5.8 about using the wrong toolchain for that
< wumpus>
I hope we override the cpu detection for gitian, at least?
< cfields>
wumpus: not saying that's the cause for sure, only that it's possible
< wumpus>
...I'm sure we do already, otherwise we'd have different gitian results based on the CPU it's compiled on
< cfields>
wumpus: the tests are just for what extensions (intrinsics) the compiler understands, they're still tested at runtime regardless
< wumpus>
ohh it checks what the compiler understands, not what the cpu understands
< wumpus>
yes, thanks, that makes it seem sane again :)
< cfields>
right
< wumpus>
I imagining something like -march=native, that would be a good way to mess up gitian determinism
< cfields>
(i can't see the travis log now, it won't load. that's why i'm just speculating instead of trying to fix it :)
< cfields>
ah, heh
< cfields>
grr... is 1/2 of the net still down due to aws? Or travis just backlogged and wonky?
< cfields>
wumpus: ooh, i see. Those are just configure checks. They're supposed to fail. The error there was just that the build took too long.
< bitcoin-git>
[bitcoin] jonasschnelli opened pull request #9899: Add jonasschnellis new NIST-P 256 signing key (master...2017/03/key) https://github.com/bitcoin/bitcoin/pull/9899
< achow101>
cfields: it looks deterministic. All 50 builds resulted in the same hash
< cfields>
achow101: great news, thanks for testing!
< cfields>
BlueMatt: have you been able to reproduce your qt crash at all?
< BlueMatt>
not since that night
< cfields>
BlueMatt: and you didn't have any tx's that had confirmed within ~a day?
< gmaxwell>
what a bizarre question.
< BlueMatt>
no, no relevant txn at all
< cfields>
gmaxwell: eh?
< sipa>
what does 'having a transaction' mean?
< sipa>
in the mempool?
< cfields>
sipa: yea
< cfields>
just trying to decide if i should keep poking the mempool reload theory, i don't have much else to go on
< MarcoFalke>
BlueMatt: I need to add my new subkey to trusted-keys, it seems?
< BlueMatt>
MarcoFalke: no
< BlueMatt>
shouldnt need to
< MarcoFalke>
hmm, it fails locally.
< MarcoFalke>
Any pull that is ready for merge right now. :P
< BlueMatt>
verify-commits.sh fails locally?
< BlueMatt>
are you sure you're signing with the right subkey?
< MarcoFalke>
Ahg, my mistake. I delkey the old one.
< jonasschnelli>
BlueMatt, MarcoFalke: so I think is then remove my NIST-P key and make a RSA4096... to bad.
< sipa>
jonasschnelli: i did the same
< jonasschnelli>
I though NIST-P would be the more-broad-usable method then Ed25519... but seems we still need to stick with RSA
< sipa>
seems support for EC keys in GPG isn't sufficiently rolled out yet
< jonasschnelli>
I though to have one of many keys that is new/different shouldn't matter... but if the verification fails,.. this is probably not ideal
< sipa>
it's just a question of EC or not, I think P256 and Ed25519 were introduced at the same time in GPG
< sipa>
in 2.1.0
< jonasschnelli>
No current available bitcoin HWW supports RSA,... NISP-2 and Ed25519 is supported though,...
< jonasschnelli>
And I don't want to use one of these crappy CCID smart cards
< jonasschnelli>
sipa: I have chosen P256 over Ed25519 because of the github support.. but meh
< sipa>
jonasschnelli: well i assume github doesn't support P256 either
< sipa>
i didn't mean to be specific
< jonasschnelli>
sipa: it does
< sipa>
oh
< jonasschnelli>
But not secp256k1 (while GPG does) and not Curve25519
< jonasschnelli>
Or at leat github accepted my P256 key while my Seck256k1 and Ed25519 key was rejected during upload
< jonasschnelli>
(and they state to have ECDSA an EdDSA support)
< sipa>
good to know
< MarcoFalke>
jonasschnelli: Maybe not revoke the old key, if you planned to do that.
< jonasschnelli>
MarcoFalke: I have no plans to revoke them,... just not to have them in the main Bitcoin Core repository anymore... because it seems that they are no longer relevant for newer releases.
< MarcoFalke>
I think as long as your root key is in the repo, there won't be any added security/trust by updating in the repo.
< MarcoFalke>
Sure, we need to add all keys at least once, but after that there is no harm in fetching from keyservers.
< MarcoFalke>
Only maybe when you prefer not to connect to the net
< jonasschnelli>
MarcoFalke: Yes. My stupid thinking was that we can verify new binaries within the old binaries without GPG.. but this would require everyone at least provide a secp256k1 key and sig for gitian... which we are far away from,.
< gmaxwell>
man, github could have avoided this snafu by adding some simple language "to the maximum extent that the uploader is legally able", rather than leaving the document in a state where the TOS appears to require users to do things they can't do.
< Micheal_PVR>
Hello everyone, is there anyone that can help me with the core secp256k1 lib? I'm trying to generate the key pair, but can't seem to find the API for private key generation.
< sipa>
secp256k1_ec_pubkey_create
< sipa>
or secp256_ec_seckey_verify
< sipa>
pass it a random 32 bytes
< sipa>
if it succeeds, it's a valid private key
< sipa>
otherwise, generate another and try again
< Micheal_PVR>
Awesome, thanks.
< Micheal_PVR>
Sorry for my lack of understanding, but in order for it to then go on to be imported as a mainnet bitcoin wallet, I would have to add a 5 infront?
< Micheal_PVR>
basically concatenate the string so that it is in the proper format for import?
< waxwing>
Micheal_PVR: this is for core development, use #bitcoin or maybe #bitcoin-dev