< 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>
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?
< 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
< 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)?
< 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/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
< 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.
< 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
< 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