< achow101> jhfrontz: I think it's supposed to be modifying the vm /etc/sudoers file as part of the setup. I believe that is part of whatever vmbuilder does. however I think vmbuilder had an update recently which breaks gitian
< achow101> if anyone wants to try gitian building with docker instead of lxc or kvm, I have an experimental branch for that: https://github.com/achow101/gitian-builder/tree/docker
< achow101> It seems to work, but I don't know if it produces the same binaries yet
< achow101> damnit the binaries don't match
< achow101> oh wait, I built the wrong binaries :/
< jonasschnelli> sipa: one thing that stuck with me over night,.. if the Bech32 BCH can detect 4 chars and correct two (length <=89), wouldn't it be trivial to brute-force the eventually present other 2 errors? Brute-force to fit the error-free checksum.
< sipa> jonasschnelli: i don't understand
< sipa> it's a very fundamental property that you can only correct half
< sipa> of what you can detect
< jonasschnelli> sipa: Okay. But wouldn't you know that there are two other errors (since it can detect 4) and where those errors are (index)?
< jonasschnelli> I guess I get the error correction right...
< jonasschnelli> I where under the assumption that if you have a encoded key with 4 errors, it will point out those 4 errors, ... the BCH correction can fix two errors, so decode again after correction and figure out where the other two error where made....
< jonasschnelli> (sry, no need for decode again)
< sipa> jonasschnelli: the point is that there may be multiple ways of making 4 changes to your invalid codeword to turn it into a valid one; but at most one will be the correct one
< sipa> if any two code words are at least different in 5 positions (which is the case for bech32), making up to 4 changes to a valid codeword will never result in another valid.codeword, so you'll never fail to detect
< sipa> however, if 3 errors are made, it may be possible to "correct" it by modifying two other unrelated positions
< sipa> resulting in a valid, but incorrect codeword
< jonasschnelli> I'm trying to understand if there is a more "forensic" approach of reconstructing an 4 chars error BCH codeword.. if you have an address (or another validation-indicator) of you now-invalid key, brute-forcing and comparing against your validation-indicator could be possible?
< jonasschnelli> For keys, error correction could be very cpu-intense IMO
< sipa> yes, you can list decode
< sipa> if you accept there are multiple possible decodi gs
< sipa> and you can tey all of them
< sipa> what we mean with "error correcting" power is how many errors there can be up to the point where you can uniquely identify the error
< jonasschnelli> Worst case stupid-dummy correction would brute forcing all 4 error positions with 32^4
< sipa> you can alwaus go try to make more changes and see if that ends up with valid codes
< sipa> yes
< sipa> adding a few checksum characters is generally easier :)
< jonasschnelli> Yes... I guess so. :)
< sipa> but if there is a lot of money at stake, you should totally do list decoding
< jonasschnelli> This somehow makes me convinced that the Bech32 properties are not utterly bad, maybe feasible for private key encoding.
< ken2812221> achow101: I've tested your docker method and got the same binaries. Its setup is easier than Lxc's.
< sipa> ken2812221, achow101: you reproduced the same 0.16.1rc1 binaries as others using docker?
< wumpus> at least all the signatures in the gitian.sigs repository match at this moment
< ken2812221> Yes, I built the binaries using both lxc and docker, they are the same.
< fanquake> ken2812221 Where is the docker method available?
< ken2812221> achow101 mentioned that on top, https://github.com/achow101/gitian-builder/tree/docker
< fanquake> ken2812221 thanks, will take a look
< wumpus> oh I had to patch gverify to use gpg2 instead of gpg to be able to verify ken2812221's signatures at all
< wumpus> gpg: using ECDSA key 0x4B79F986CBDF8736
< wumpus> gpg: BAD signature from "Chun Kuan Lee(ken2812221) <ken2812221@gmail.com>" [unknown]
< wumpus> ken2812221: BAD SIGNATURE
< wumpus> the other ones check out
< wumpus> (it's a ?bad signature? this doesn't imply that your build differs)
< wumpus> ken2812221: checking the assert manually - looks like your executables do match, but you need to re-sign it
< wumpus> rm bitcoin-win-0.16-build.assert.sig && gpg2 --detach-sign bitcoin-win-0.16-build.assert or something like that
< wumpus> (but first check if verification fails there too)
< ken2812221> OK, I'll check it
< wumpus> (simply "gpg2 bitcoin-win-0.16-build.assert.gpg" in your 0.16.1rc1 directory should do it)
< wumpus> (I'm only insisting on the gpg2 thing because of Ubuntu 16.04 - in 18.04, gpg is gpg2 by default,thankfully...)
< wumpus> ken2812221: thanks, that fixed it
< ken2812221> Sorry, maybe I did something wrong with my hardware key before.
< wumpus> what kind of token do you use that supports ECDSA signing in hardware?
< wumpus> seems even the most recent yubikey still does only RSA
< ken2812221> ledger-nano-s
< wumpus> thanks
< wumpus> I didn't know that could be used with gpg :)
< ken2812221> Yes it can. But the client is a third party software.
< mryandao> would it be realistic to look at an api to integrate hardware wallet usage in Core?
< mryandao> *designing an api
< wumpus> though it's nistp256 not secpp256
< wumpus> ruby is easier than I thought (patches gverify to take an arbitrary verification program) https://github.com/devrandom/gitian-builder/pull/182
< wumpus> mryandao: to make that feasible such an API should be generic, not 'just for Core'
< wumpus> mryandao: jonasschnelli has been looking into this
< jonasschnelli> mryandao: Yes.
< jonasschnelli> BIP174 is a great basepoint...
< jonasschnelli> Though its serialization format is not optimized for HWW/MCUs
< jonasschnelli> For Core&HWW, the question is what standard we would follow... we can't use proprietary vendor specific USB communication
< jonasschnelli> Ideally it would be similar to how SSH/GPG agents work
< wumpus> it's kind of frustrating how this is different enough for standard smartcard crypto APIs that it requires something entirely new
< jonasschnelli> wumpus: Yes. Those standard didn't bothered about verification...
< wumpus> yes, definitely, there would need to be an external driver, and this standard should describe how to communicate with that
< jonasschnelli> They are happy if the key is on the card...
< jonasschnelli> Extra driver is something users dislike... thats why I once proposed the URI scheme.
< wumpus> the details, such as how communication with the device happens, is up to the vendor
< wumpus> we're not going to do low-level USB stuff in bitcoin core
< mryandao> isnt there libusb?
< jonasschnelli> Yes!
< * jonasschnelli> stabs mryandao
< wumpus> (nor link against libhid or any other nightmare abominations)
< jonasschnelli> Core has already too much dependencies...
< jonasschnelli> What we want is communicate with a "bridge-application"
< wumpus> "> Extra driver is something users dislike" is there any other realistic option?!
< jonasschnelli> URI schemes would allow that an application opens "sign://<data>" where to OS would start the application that have registered sign://
< wumpus> smartcards, yubikeys etc also have their own driver, it's not like gpg2 includes low-level support for all of them.
< wumpus> so that's effectively a driver
< wumpus> what you are documenting is the communication protocol with it, which could use an URI, sure...
< jonasschnelli> It would avoid a daemon and it would be portable (probably)
< wumpus> sure, it could be a process that is launched on demand, it dosn't have to be an always-on daemon
< mryandao> it wouldn't be that painful to install an agent like gpg i'd imagine
< wumpus> I also dislike things that have to run always, especially if it concerns the wallet, you want to be able to remove the device at any time anyway
< wumpus> on the other hand, to be honest, at this point I'd prefer *any* standard for HW wallets to the jungle there is now, can always optimize the details later
< mryandao> but the agent that's up 24/7 wouldnt be holding the keys no?
< wumpus> it could, but for a HSM it wouldn't hold the keys itself, at most identifiers.
< wumpus> though there could be a agent that uses, say, a CPU secure enclave instead of a real hardware wallet, that's up to the vendor
< mryandao> sounds like the painpoints alone warrant a workshop on integration of HSMs with Bitcoin
< wumpus> (or if, say, TPM3.0 standard would include cryptocurrency wallet support, could use the motherboard TPM module)
< wumpus> in any case, the wallet software shouldn't need to care about those details at all
< mryandao> i thought the community as a whole finds TPMs to be distasteful
< wumpus> smartcards, security tokens, etc are essentially pluggable TPMs
< wumpus> and in my opinion there are certainly distasteful uses of them, such as OS vendor lock-in and DRM, but this is getting off topic, I was just illustrating that there is a large range of possibilities.
< wumpus> < mryandao> sounds like the painpoints alone warrant a workshop on integration of HSMs with Bitcoin <- I agree, it's something that could use more concentrated effort
< wumpus> I've always been surprised how little the hardware wallets vendors care about this, they just carve out their little space with their own proprietary protocols and software, instead of starting some bitcoin HSM working group
< wumpus> even if you don't care about "use of Bitcoin Core as wallet" (like Trezor), it seems that other wallets would benefit from the same
< wumpus> anyhow </soapbox>
< * sipa> hopes bip174 will help
< * wumpus> hopes so too
< bitcoin-git> [bitcoin] harrymckinnon86 opened pull request #13338: Test (master...test) https://github.com/bitcoin/bitcoin/pull/13338
< bitcoin-git> [bitcoin] harrymckinnon86 closed pull request #13338: Test (master...test) https://github.com/bitcoin/bitcoin/pull/13338
< jonasschnelli> roasbeef: have you considered hardware wallet during your aezeed specs? Is scrypt(n=32768, r=8, p=1) something that works on a tiny MCU (like those ones used by Trezor, Ledger, Bitbox)?
< promag> thoughts on #13160?
< gribble> https://github.com/bitcoin/bitcoin/issues/13160 | wallet: Unlock spent outputs by promag · Pull Request #13160 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/a315b79ad2b8...56fe3dc235a0
< bitcoin-git> bitcoin/master 6d714c3 Pieter Wuille: Make coincontrol use IsSolvable to determine solvability
< bitcoin-git> bitcoin/master 4e91820 Pieter Wuille: Make IsMine stop distinguishing solvable/unsolvable
< bitcoin-git> bitcoin/master b5802a9 Pieter Wuille: Simplify IsMine logic
< bitcoin-git> [bitcoin] laanwj closed pull request #13142: Separate IsMine from solvability (master...201804_separate_ismine_solvable) https://github.com/bitcoin/bitcoin/pull/13142
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/56fe3dc235a0...3fd0c2336a12
< bitcoin-git> bitcoin/master 13c3a65 João Barbosa: Qt/Bugfix: fix handling default wallet with no name
< bitcoin-git> bitcoin/master 3fd0c23 Wladimir J. van der Laan: Merge #13273: Qt/Bugfix: fix handling default wallet with no name...
< bitcoin-git> [bitcoin] laanwj closed pull request #13273: Qt/Bugfix: fix handling default wallet with no name (master...2018/05/loadwallet_fix) https://github.com/bitcoin/bitcoin/pull/13273
< wumpus> promag: lgtm
< wumpus> promag: so I think removing spent UTXOs from the locked set automatically is a better solution than the other PR, also the code change is cleaner, but it seems not many people weigh in
< promag> right
< promag> I also think other should give feedback there
< wumpus> I disagree with the opinion in the other PR that yours is 'a breaking change', I mean this is the behavior already, the only change is that the UTXOs don't linger around forever
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/3fd0c2336a12...70d354131379
< bitcoin-git> bitcoin/master fe16dd8 Wladimir J. van der Laan: net: Add option `-enablebip61` to configure sending of BIP61 notifications...
< bitcoin-git> bitcoin/master 87fe292 Wladimir J. van der Laan: doc: Mention disabling BIP61 in bips.md
< bitcoin-git> bitcoin/master 70d3541 Wladimir J. van der Laan: Merge #13134: net: Add option `-enablebip61` to configure sending of BIP61 notifications...
< bitcoin-git> [bitcoin] laanwj closed pull request #13134: net: Add option `-enablebip61` to configure sending of BIP61 notifications (master...2018_05_optional_bip61) https://github.com/bitcoin/bitcoin/pull/13134
< bitcoin-git> [bitcoin] promag opened pull request #13339: wallet: Replace %w by wallet name in -walletnotify script (master...2018-05-walletnotify) https://github.com/bitcoin/bitcoin/pull/13339
< bitcoin-git> [bitcoin] laanwj closed pull request #13281: test: Move linters to test/lint, add readme (master...Mf1805-qaLint) https://github.com/bitcoin/bitcoin/pull/13281
< bitcoin-git> [bitcoin] fanquake opened pull request #13340: doc: remove leftover check-doc documentation (master...move-check-doc) https://github.com/bitcoin/bitcoin/pull/13340
< fanquake> wumpus #13340 is a trivial follow up to fix the doc nit
< gribble> https://github.com/bitcoin/bitcoin/issues/13340 | doc: remove leftover check-doc documentation by fanquake · Pull Request #13340 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2ac6315f44a8...e08c130c25ed
< bitcoin-git> bitcoin/master f44a0eb Jeff Frontz: Ensure gitian-build.sh uses bash...
< bitcoin-git> bitcoin/master e08c130 Wladimir J. van der Laan: Merge #13320: Ensure gitian-build.sh uses bash...
< wumpus> fanquake: thanks!
< bitcoin-git> [bitcoin] fanquake closed pull request #13320: Ensure gitian-build.sh uses bash (master...patch-1) https://github.com/bitcoin/bitcoin/pull/13320
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e08c130c25ed...3a8e3f480612
< bitcoin-git> bitcoin/master 93843f6 fanquake: doc: remove leftover check-doc documentation
< bitcoin-git> bitcoin/master 3a8e3f4 Wladimir J. van der Laan: Merge #13340: doc: remove leftover check-doc documentation...
< bitcoin-git> [bitcoin] laanwj closed pull request #13340: doc: remove leftover check-doc documentation (master...move-check-doc) https://github.com/bitcoin/bitcoin/pull/13340
< jnewbery> wumpus: I'm out for this Thursdays's meeting. Now that 0.16.1rc1 is out and the high priority list is a bit shorter, can we consider adding #13058? It's the next in the dynamic wallet load/unload series.
< gribble> https://github.com/bitcoin/bitcoin/issues/13058 | [wallet] `createwallet` RPC - create new wallet at runtime by jnewbery · Pull Request #13058 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] krab closed pull request #12783: macOS: Disable AppNap (master...macos-disable-appnap) https://github.com/bitcoin/bitcoin/pull/12783
< wumpus> jnewbery: sure
< bitcoin-git> [bitcoin] krab reopened pull request #12783: macOS: Disable AppNap (master...macos-disable-appnap) https://github.com/bitcoin/bitcoin/pull/12783
< wumpus> added
< promag> wumpus: we could hash(wallet.name) and use that in listwallets, -walletnotify etc..
< promag> looks like mempool_persist.py is flaky
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3a8e3f480612...f8a29ca823fb
< bitcoin-git> bitcoin/master 59e9688 Chun Kuan Lee: Travis: Build tests on Ubuntu 18.04 with docker
< bitcoin-git> bitcoin/master f8a29ca Wladimir J. van der Laan: Merge #13215: Travis: Build tests on Ubuntu 18.04 with docker...
< bitcoin-git> [bitcoin] laanwj closed pull request #13215: Travis: Build tests on Ubuntu 18.04 with docker (master...patch-1) https://github.com/bitcoin/bitcoin/pull/13215
< roasbeef> jonasschnelli: likely to high of params (actually a real kdf) to be feasible on hardware wallets, idea was to add an additional external version w/ lighter weight params
< jonasschnelli> roasbeef: yeah. real KDF for HWW is hard. Especially memory based like scrypt
< jonasschnelli> I just tested PBKDF with 20k rounds on a Bitbox. Takes 30 seconds
< jonasschnelli> acceptable IMO for seed and recovery... but not for a device PIN KDF.
< sipa> outsourcable hardening would be nice
< jonasschnelli> sipa: yes. but imo that concept needs to be specified and analysed further more
< sipa> absolutely
< jonasschnelli> I think it's acceptable to wait 30s on a HWW during encrypted seed backup (seed with optional encryption) as well as during a wallet restore
< jonasschnelli> 30s PBKDF results in acceptable 40ms on my Intel corei7
< jonasschnelli> optional, the rounds could be flexible and make it into the seed serialization format
< jonasschnelli> wait longer == better KDF / brute force / wordlist resistance
< bitcoin-git> [bitcoin] achow101 closed pull request #13289: [Qt] Re-setup args after translator setup to translate help text (master...qt-help-translations) https://github.com/bitcoin/bitcoin/pull/13289