< GitHub39>
[bitcoin] TheBlueMatt opened pull request #7206: Add "NODE_BLOOM" to guiutil so that peers don't get UNKNOWN[4] (master...2015_12_bloom_gui) https://github.com/bitcoin/bitcoin/pull/7206
< Luke-Jr>
hm, the depends cache appears to not work in gitian anymore
< GitHub4>
bitcoin/master daf6466 Matt Corallo: Add "NODE_BLOOM" to guiutil so that peers don't get UNKNOWN[4]
< GitHub4>
bitcoin/master b7c704a Jonas Schnelli: Merge pull request #7206...
< GitHub16>
[bitcoin] jonasschnelli closed pull request #7206: Add "NODE_BLOOM" to guiutil so that peers don't get UNKNOWN[4] (master...2015_12_bloom_gui) https://github.com/bitcoin/bitcoin/pull/7206
< Luke-Jr>
is cfields back from HK yet btw?
< gmaxwell>
v3 block setback, alas. :)
< jonasschnelli>
940/1000! That was quick.
< Luke-Jr>
uh oh, critical bug in CLTV. quick, downgrade all miners. J/K
< randy-waterhouse>
not funny
< Luke-Jr>
MarcoFalke: you can actually get to jonasschnelli's webserver? O.o
< phantomcircuit>
Luke-Jr, why wouldn't be?
< Luke-Jr>
phantomcircuit: because it's broken
< Luke-Jr>
has been for days
< phantomcircuit>
uh
< Luke-Jr>
An error occurred during a connection to bitcoin.jonasschnelli.ch. SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long)
< phantomcircuit>
not it's not :P
< Luke-Jr>
phantomcircuit: … it totally is, in all my browsers
< jonasschnelli>
I guess just adding "libtiff-tools" in gitian should do the work.
< Luke-Jr>
I was going to use -c none since the DMG is itself compressed?
< jonasschnelli>
Luke-Jr: Right. Compression does not make huge sense.
< jonasschnelli>
(It would be deflated anyways when opening the DMG)
< Luke-Jr>
I figure trying to compress here just adds a risk of non-determinism :P
< jonasschnelli>
But the file might be relatively height (1-2MB) when not using lzw
< jonasschnelli>
Luke-Jr: ah. Good point.
< jonasschnelli>
The dmg's size should not be different (also z compressed)
< jonasschnelli>
(slightly different, but not much)
< Luke-Jr>
jonasschnelli: pushed a tiffcp version
< jonasschnelli>
Luke-Jr: oh. Fast. Will kick the builder...
< MarcoFalke>
How do people store their pgp signing master-key?
< MarcoFalke>
dev machine or hidden box in the basement?
< jcorgan>
keep going
< randy-waterhouse>
h/ware wallet?
< Taek>
pgp hardware wallet sounds desirable
< MarcoFalke>
no, I mean the key used to sign your subkeys for email, gitian etc.
< jonasschnelli>
MarcoFalke: i'm working on a bitcoin/pgp/ssh hardware wallet
< Luke-Jr>
I refuse to disclose precisely :P
< jonasschnelli>
GPG2.1 supports ECC btw.
< MarcoFalke>
I was wondering if it's slightly more secure to create a vm on my box to do the gpg stuff instead of doing it on the host system
< gmaxwell>
a number of people around here are using openpgp smartcards. (e.g. yubikey)
< jonasschnelli>
MarcoFalke: if your host is compromised, you VM is also.
< Luke-Jr>
jonasschnelli: are you the one I had to upgrade my GPG for? :P
< jonasschnelli>
nono.. :) Not using ECC key right now.
< Luke-Jr>
someone is
< gmaxwell>
I currently use a seperate host for my gpg key, but it's a nussance, planning on trying to move at least one of the signing subkeys to a pgp smartcard.
< gmaxwell>
Luke-Jr: matt I think
< jonasschnelli>
Will do as soon as i can have a hw wallet that support bitcoin/pgp/ssh with the same device.
< * Luke-Jr>
sorts by size: Jonathan Wilkins
< jonasschnelli>
the bad is, gpg and ssh do not support the k1 curve...
< Luke-Jr>
actually, that one is Ed25519
< Luke-Jr>
jonasschnelli: any results on the DMG btw?
< jonasschnelli>
(i should have pass ONLY_OSX though)
< jcorgan>
the pgp smartcard idea is attractive, but it's not clear how you provide backup/disaster recovery/redundancy for the secrety key material
< jonasschnelli>
jcorgan: agree. And mind: smartcards are close-source.
< jonasschnelli>
A GPG/SSH hw wallet infrastructure that works together with bip32 would be a better solution.
< btcdrak>
MarcoFalke: trying to sign with a smartcard in a VM is a disaster
< jonasschnelli>
Luke-Jr: what os, browser are you using. I can verify the SSL/https connection on Ubuntu 15.05 with FF.
< Luke-Jr>
jonasschnelli: can you eliminate the side channels?
< jcorgan>
jonasschnelli: i've also been chewing on the idea a "password keeper" that generates/regenerates passwords using BIP32-derived secret keys
< MarcoFalke>
Haven't heard of the smartcard yet. Looking into this right now, but it seems a vm is not needed when using a smart card.
< Luke-Jr>
jonasschnelli: Gentoo stable x86; tested on Konqueror/KDE, Chromium, and Firefox
< jonasschnelli>
Luke-Jr: our hw wallet does eliminate most SD attacks, thanks to libsecp256k1.
< gmaxwell>
jcorgan: you generate the key external to the card, back it up, load it on the card.
< jonasschnelli>
gmaxwell: would you load the card over a PC?
< gmaxwell>
jonasschnelli: e.g. on an offline machine.
< jonasschnelli>
hmm... that's why i think a secure hw wallet needs a SDcard port (or similar)
< jcorgan>
gmaxwell: i'm not familiar; didn't know you could d/l secret key material
< Luke-Jr>
jonasschnelli: have you spoken with the Ledger guys much? they seem to know a lot about sidechannel stuff
< jonasschnelli>
Luke-Jr: Because Ledger is using close source/ patented smart cards, its had fallen out of my personal selection.
< Luke-Jr>
jonasschnelli: they're doing that because it's supposedly the only way they can do it secure
< jonasschnelli>
The trezor side channel attack was possible because of it's ecc implementation i guess.
< gmaxwell>
jcorgan: at least some pgp smartcards will let you _upload_ keys.
< jonasschnelli>
Luke-Jr: i don't understand how patents/close source can make it secure.
< jcorgan>
i will have a new laptop with smartcard reader shortly. would love to reconstruct a chain of trust through it to ssh/pgp/btc
< Luke-Jr>
jonasschnelli: not the patents/closed operative there
< Luke-Jr>
jonasschnelli: just that the less-closed stuff (nothing is open..) isn't secure
< Luke-Jr>
jonasschnelli: I don't know the details though, so if you're planning to build something, it might be good to chat with them
< jonasschnelli>
Luke-Jr: our product is build and should be ready for shipment in jan 16. But right,... will talk to nicolas soon (but more about standard for wallet integration)
< jcorgan>
gmaxwell: is there a good reference you'd receommend on learning these different smart card approaches, their vulnerabilities, and best practices?
< jonasschnelli>
Luke-Jr: still no background. :/
< jonasschnelli>
commit d5f4683 correct?
< jonasschnelli>
no wait: 209dd10
< Luke-Jr>
209dd10 is current
< jonasschnelli>
Yes. Seems up to date.
< Luke-Jr>
I wonder if the DS_Store thing doesn't work :/
< Luke-Jr>
I think I left out a few fields that seemed irrelevant
< jonasschnelli>
Hmm.. just checked the tiff file,.. contains only one image i guess.
< GitHub69>
bitcoin/master e1030dd Patrick Strateman: Note that reviewers should mention the commit hash of the commits they reviewed.
< GitHub69>
bitcoin/master ea0f5a2 Wladimir J. van der Laan: Merge pull request #7185...
< GitHub104>
[bitcoin] laanwj closed pull request #7185: Note that reviewers should mention the id of the commits they reviewed. (master...2015-12-07-contributingackcommit) https://github.com/bitcoin/bitcoin/pull/7185
< GitHub91>
bitcoin/master 979698c Jonas Schnelli: [RPC-Tests] add option to run rpc test over QT clients
< GitHub91>
bitcoin/master 5f3c670 Wladimir J. van der Laan: Merge pull request #7068...
< GitHub60>
[bitcoin] laanwj closed pull request #7068: [RPC-Tests] add simple way to run rpc test over QT clients (master...2015/11/rpc_tests_qt) https://github.com/bitcoin/bitcoin/pull/7068
< GitHub149>
bitcoin/master b6915b8 accraze: checks for null data transaction before debug.log...
< GitHub149>
bitcoin/master c611acc accraze: wallet: check if tx scriptPubKey is unspendable
< GitHub149>
bitcoin/master d812daf accraze: fix logic for error log
< GitHub92>
[bitcoin] laanwj closed pull request #7200: Checks for null data transaction before issuing error to debug.log (master...null-tx-debug) https://github.com/bitcoin/bitcoin/pull/7200
< jonasschnelli>
should be /usr/bin/tiffcp -c none dpi36.background.tiff dpi72.background.tiff dist/.background/background.tiff
< GitHub12>
[bitcoin] laanwj opened pull request #7208: Make max tip age an option instead of chainparam (master...2015_12_maxtipage) https://github.com/bitcoin/bitcoin/pull/7208
< GitHub158>
[bitcoin] laanwj opened pull request #7209: test: don't override BITCOIND and BITCOINCLI if they're set (master...2015_12_rpctests_setenviron) https://github.com/bitcoin/bitcoin/pull/7209
< instagibbs>
Does Core exclusively use openssl for secure prng?
< phantomcircuit>
instagibbs, it's my understanding that it should
< instagibbs>
thanks
< wumpus>
yes, at this point it does
< wumpus>
there's plans to move away from openssl for random generation, but not yet
< GitHub156>
[bitcoin] EthanHeilman opened pull request #7212: Adds unittests for CAddrMan and CAddrinfo, removes source of non-determinism. (master...unittest) https://github.com/bitcoin/bitcoin/pull/7212
< btcdrak>
BIP65 enforced
< cfields>
Luke-Jr: back now
< cfields>
Luke-Jr: just starting the catch-up process. Something need my attention asap?
< Luke-Jr>
cfields: probably not asap
< cfields>
Luke-Jr: well, what were you referring to?
< sdaftuar>
is there anything special that needs to be done to make travis work well on personal repos? i enabled travis on my fork of the project so i could test branches before opening PRs, but they fail a lot for strange reasons (even when the same branch succeeds as part of a bitcoin core PR)
< MarcoFalke>
sdaftuar, when did you enable travis?
< sdaftuar>
hm. does bitcoin core use the container-based environment?
< MarcoFalke>
I'd guess its using "Standard" but haven't checked that either.
< GitHub92>
[bitcoin] MarcoFalke opened pull request #7214: qt5: Use the fixed font the system recommends (master...MarcoFalke-2015-qt5monospace) https://github.com/bitcoin/bitcoin/pull/7214