< jonasschnelli> sipa: what do you think about "address:<addr>/b<timestamp_uint64>/w|p<pkey_wif>" or "script:<script_hex>" or "p2wpkh:<pub|xpub>/r0-2000/..."?
< jonasschnelli> pub/xpub is autodetect, first char r | b | w | p is for (r)ange, (b)irthday, (w)atchonly, (p)rivatekey
< A4L> Php/python/linux bash: send.bitcoin(privatekey, publickey, amount); how to??
< jonasschnelli> A4L be more specific in your question and use #bitcoin-dev (this channel is for Bitcoin Core development)
< Arvidt> Is it possible to force bitcoind log messages to be in English, while system language ($LANG) and so GUI are in another local language?
< Arvidt> export LC_MESSAGES=C leads the GUI to be also in English
< bitcoin-git> [bitcoin] marcoagner opened pull request #13381: [WIP] RPC: creates preserve parameter for importprivkey call (master...feature_preserve_labels_on_import) https://github.com/bitcoin/bitcoin/pull/13381
< bitcoin-git> [bitcoin] practicalswift opened pull request #13382: util: Don't throw in GetTime{Millis,Micros}(). Mark as noexcept. (master...dont-throw-in-GetTimeMillis-and-GetTimeMicros) https://github.com/bitcoin/bitcoin/pull/13382
< bitcoin-git> [bitcoin] practicalswift opened pull request #13383: bench: Use non-throwing ParseDouble(...) instead of throwing boost::lexical_cast<double>(...) (master...remove-dependency-on-lexical_cast-which-is-boost-and-also-throws) https://github.com/bitcoin/bitcoin/pull/13383
< sipa> jonasschnelli: you cannot correct more than 2 errors in bech32, ever
< sipa> this is not a question of efficiency
< jonasschnelli> sipa: is the assumption wrong, that you can -try- to correct the possible 4 detected errors if you know a derived address?
< sipa> oh, sure
< sipa> even more
< sipa> there is no limit to that
< jonasschnelli> with a 4^32 trial and error
< gmaxwell> "-try- to correct the possible 4 detected errors" thats not how it works.
< jonasschnelli> I think the proposal says it can detect 4 for WIF and 3 for xpriv where it is possible to correct those if a derived element is available
< sipa> none of that has anything to do with correction
< sipa> you can always try all combinations of N changes to the input, and see if they work
< sipa> that's not limited to 4
< sipa> and isn't called correction
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #13384: qa: Remove polling loop from test_runner (master...Mf1806-qaTestRunnerConcurrentFuture) https://github.com/bitcoin/bitcoin/pull/13384
< jonasschnelli> I guess I used the wrong term then...
< gmaxwell> you could examine the (length choose 4)*(31^4) candidate distance 4 entries, and see which of them are checksum valid, there will be many. (and there are more computationally efficient ways of doing that than just trying them all)
< sipa> jonasschnelli: my point is that there is no limit of 4 errors for that
< jonasschnelli> I see
< sipa> you can try all combinations of 6 changes to the input too, and see which one work
< sipa> if you have enough computational power
< sipa> jonasschnelli: what does "P2WPKH P2WSH nested in P2SH" mean?
< jonasschnelli> sipa gmaxwell: is there a possible calculation on how much chars (%) could be reconstructed with a top cap of computational power?
< sipa> jonasschnelli: all of them, obviously
< sipa> you try every possible private key
< sipa> this has nothing to do with the encoding
< gmaxwell> sipa: he wants a function on cpu usage vs distance.
< sipa> ah, sorry!
< jonasschnelli> I mean efficient
< jonasschnelli> what gmaxwell said. yes
< sipa> the checksum just gives you a fixed speedup
< sipa> larger checksums give you a better speedup
< jonasschnelli> P2WPKH: the P2WSH part should be removed there (paste error)
< gmaxwell> (length choose num_changed_chars)*(31^num_changed_chars) is the function for the number of operations, the use of a smart checksum reduces that some. e.g. bech32 basically takes 2 out of the number of characters you're considering (though makes the inner operation slower)
< sipa> jonasschnelli: if you want a way to represent the current bitcoin core behaviour, it also needs P2PK
< jonasschnelli> I thought of that... but undefined is probably okay to set in this case
< sipa> there shouldn't be undefined IMHO; you can use the existing xprv encoding for that
< gmaxwell> ignoring he speedup from the checksum, there are 2^38.7 candidate keys with 4 errors, on a length 60 payload. 2^47.1 for 5, 2^55.3 ... so already at 4 if checking involves computing public keys, it's probably already computationally intractable for most users at 4.
< jonasschnelli> do you think bech32 & derived element is acceptable for reconstructing extended keys?
< sipa> bech32 of what?
< jonasschnelli> chaincode&privatekey
< sipa> ah, i see
< gmaxwell> private key material ends up being too long for bech32 and it loses its checking properties, so then even the speedup goes away and the 4character search is not tractable.
< sipa> i really think for private keys you want stronger error detection
< gmaxwell> Also that kind of "search" implies you have some external way to detect if a key is right or not... which could help if you're recovering lost funds, but not if you are entering in a safely stored private key to derrives public keys to send funds to for the first time.
< gmaxwell> which is also important, since if users mess up generating their public keys for a secret they'll send funds off into space.
< jonasschnelli> So your saying the bech32 error detection is not sufficient to check the entered extended key before deriving subkeys?
< jonasschnelli> (since 512bit exceed the bech32 90 chars limit?)
< sipa> jonasschnelli: if you either have a vast amount of computation power, or only 1 error... sure
< sipa> but bech32 is really the wrong choice here
< jonasschnelli> Yes. Maybe a new cycling could would make sense...
< sipa> I'll comment on the list
< jonasschnelli> thanks.
< jonasschnelli> reusing bech32 for keys instead of using Base58check is such a low hanging fruit..
< jonasschnelli> I hope we identify a code as soon as possible
< jonasschnelli> Bech32 is currently available in most (all?) modern bitcoin software and a support of the bech32 keys proposal would be simple to implement
< jonasschnelli> but I guess strong error detection is more important then simple implementation properties
< sipa> i think you underestimate the difficulty of implementing a try-all-combinations-of-errors approach which compares with addresses/utxo set
< jonasschnelli> sipa: yes..perhaps.
< bitcoin-git> [bitcoin] practicalswift opened pull request #13385: build: Guard against accidental introduction of new Boost dependencies (master...lint-boost) https://github.com/bitcoin/bitcoin/pull/13385
< sipa> jonasschnelli: sent
< jonasschnelli> sipa: reading...
< jonasschnelli> and writing code to exploit 4 invalid chats in a encoded key. :)
< jonasschnelli> sipa: can the code have a variable checksum size (runtime)? Would it make sense to delegate the reconstruct-probability to the user?
< sipa> jonasschnelli: that sounds hard
< jonasschnelli> ok
< jonasschnelli> sipa, gmaxwell: guess how long it takes to compute m/0 for possible 4 invalid chars (bech32 decode & bip32 pckd, hash160 base58check)?
< jonasschnelli> 923520 attempts
< jonasschnelli> real1m0.189s
< jonasschnelli> And that is with -O0 :)
< jonasschnelli> Oops.. I missed the char. So it is 1048575 attempts... resulting in 1.5m computation power on my Core i7
< jonasschnelli> With -O0 and parallelized
< jonasschnelli> not parallelized
< sipa> what length?
< jonasschnelli> xpriv... 555 bits
< jonasschnelli> Hacked down very quickly... mistakes are possible
< sipa> there should be 3743128125 combinations to try
< sipa> for length 111
< jonasschnelli> sipa: Yes. There is a misstake...
< jonasschnelli> sipa: It may result then in ~60h...
< jonasschnelli> (assume 1048575 takes ~1min)
< jonasschnelli> sipa: My code does assume that there are 4 characters detected as erroneous, I try to replace all 4 chars with all possible 32-bech-chars in a brute force way. Shouldn't that result in 32^4 attempts?
< sipa> jonasschnelli: you don't know where the 4 errors are
< sipa> you also don't know there are 4 errors
< sipa> you only know whether (A) there are no errors OR more than 4 or (B) something else
< jonasschnelli> sipa: I see. That is my mistake... I assumed Bech32 allows to point to the erroneous chars.
< sipa> jonasschnelli: nope, that requires error correction
< sipa> under the assumption that there are at most 4 errors, this translates to (A) there are no errors or (B) there are 1-3 errors
< sipa> if you know where the errors are, you also know what the errors are
< jonasschnelli> sipa: I see.
< jonasschnelli> I guess a BCH that can correct 4 errors (15 checksum characters) is probably a good tradeoff
< jonasschnelli> But for 111chars.. (512bit & metadata), that is only 3.6%).
< sipa> it's 126 characters
< sipa> the errors can be in the checksum too
< jcorgan> there are four lights
< * jcorgan> ducks
< jonasschnelli> Even with correct up to 28 errors = 102 checksum would then result in "only" 13.1%.
< luke-jr> sipa: more than 4 errors is only *sometimes* indistinguishable from no-errors, I would hope?
< gmaxwell> jonasschnelli: I gave the formula for the number of attempts above: (length choose 4) * 31^4 (31 not 32 because 32 would mean no error. :P )
< sipa> luke-jr: of course
< jonasschnelli> gmaxwell: what is (length choose 4), then length of the encoded payload & checksum?
< gmaxwell> length is the length with the checksum, "choose" means use the binomial formula https://en.wikipedia.org/wiki/Binomial_coefficient
< gmaxwell> so length! / (4! * (length-4)!) though you'll run out of precision if you compute it that way. :P
< gmaxwell> (because length! will be enormous)
< jonasschnelli> I see
< gmaxwell> jonasschnelli: here are some useful concepts. You can imagine every input string as a point in a many dimensional space. When we have a checksum we make it so not every point in that space is a valid input, only some have valid check values. When we say the code can correct up to N errors we mean that if you pick any point (valid or invalid) in that space, and draw a N error wide ball aroun
< gmaxwell> d it, there is only a single valid string inside that ball. We also usually mean there is an efficient algorithim for finding that solution.
< gmaxwell> That is called a unique solution. It's also possible to do whats called list error correction, where you draw a ball >N in size, and there are multiple solutions, but hopefully not many (esp if the code is good).
< gmaxwell> (or rather there are _sometimes_ multiple solutions... when we say we can correct N errors it means that the N ball of _any_ point always has only a single valid input inside of it... but maybe the N+1 ball has only a single valid one in it 10% of the time)
< jonasschnelli> Great explanation...
< gmaxwell> For recovering an already used private key it would be totally plausable to list decode a little bit-- just if the list is small enough, since pubkey derv is slow.
< gmaxwell> But if the private key is not already used-- e.g. the first time reentering it after transcribing it on durable media), list decoding is not so helpful. :)
< jonasschnelli> I guess what it may should be optimise is an error correction where computational costs could be very high with the assumption we can compare against an existing derivation element (an address)
< gmaxwell> Sipa and I actually do have a list decoder for bech32 that goes a little further then the normal check radius, e.g. it can enumerate all the 4 error solutions even though the code can't uniqely correct that many. I was intending to use it to eventually make better GUI hints for misentry.
< jonasschnelli> My core i7 can do 31’775 operations per seconds where an operation is bech32-decode->bip32-ckd->hash160->base58check
< gmaxwell> jonasschnelli: yes, so that favors supporting a small amount of list decoding, but probably not more than a half million entries or so.
< gmaxwell> You'd only need CKD and a used-address-table lookup in the inner loop.
< jonasschnelli> Probably the child key index is also required
< gmaxwell> it would certantly be faster if you could hint an index, but my guess is that it would CKD the first 100 keys or something like that, and check each of them.
< jonasschnelli> Yes.
< gmaxwell> in any case these things mean that the correction radius for a used key when you're willing to accept a very slow search might be in practice maybe 2 or so errors more than the numbers in pieter's post.
< drexl> it seems like microsoft just bought github
< midnightmagic> ... whaa?
< midnightmagic> just in discussions, looks like.
< jonasschnelli> (rumors)
< midnightmagic> Bloomberg sources..
< midnightmagic> lol gee, I wonder what will become of the platform we all depend on.
< jonasschnelli> Integrate Skype for code-review...
< * midnightmagic> shudders.
< gmaxwell> like skype, first they'll get rid of the git supernodes and centeralize it on their own server farm..
< gmaxwell> wait.
< midnightmagic> they're not profitable. that means microsoft will try to make it profitable; also it'd be hilarious to watch them embrace-and-extend git itself with features that integrate it more tightly with their OS (same as they did for every other acquisition they've ever made, ever.)
< drexl> they didn't really touch linkedin, you can't even login with a microsoft account
< midnightmagic> linkedin was already too riddled with spyware and anti-user features. they couldn't possibly have made it worse, so why not leave it alone.
< intcat> drexl: i don't think you used to need a linkedin account to view profiles etc
< Varunram> intcat: those changes were relatively recent
< bitcoin-git> [bitcoin] sipa opened pull request #13386: SHA256 implementations based on Intel SHA Extensions (master...201806_shani) https://github.com/bitcoin/bitcoin/pull/13386