1 2018-06-03 08:58:26	0|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/..."?
  2 2018-06-03 08:58:34	0|jonasschnelli|pub/xpub is autodetect, first char r | b | w | p is for (r)ange, (b)irthday, (w)atchonly, (p)rivatekey
  3 2018-06-03 09:28:55	0|A4L|Php/python/linux bash: send.bitcoin(privatekey, publickey, amount); how to??
  4 2018-06-03 09:29:53	0|jonasschnelli|A4L be more specific in your question and use #bitcoin-dev (this channel is for Bitcoin Core development)
  5 2018-06-03 14:28:17	0|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?
  6 2018-06-03 14:41:00	0|Arvidt|export LC_MESSAGES=C leads the GUI to be also in English
  7 2018-06-03 14:59:02	0|bitcoin-git|[13bitcoin] 15marcoagner opened pull request #13381: [WIP] RPC: creates preserve parameter for importprivkey call (06master...06feature_preserve_labels_on_import) 02https://github.com/bitcoin/bitcoin/pull/13381
  8 2018-06-03 17:22:33	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #13382: util: Don't throw in GetTime{Millis,Micros}(). Mark as noexcept. (06master...06dont-throw-in-GetTimeMillis-and-GetTimeMicros) 02https://github.com/bitcoin/bitcoin/pull/13382
  9 2018-06-03 18:11:38	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #13383: bench: Use non-throwing ParseDouble(...) instead of throwing boost::lexical_cast<double>(...) (06master...06remove-dependency-on-lexical_cast-which-is-boost-and-also-throws) 02https://github.com/bitcoin/bitcoin/pull/13383
 10 2018-06-03 18:20:35	0|sipa|jonasschnelli: you cannot correct more than 2 errors in bech32, ever
 11 2018-06-03 18:20:40	0|sipa|this is not a question of efficiency
 12 2018-06-03 18:21:56	0|jonasschnelli|sipa: is the assumption wrong, that you can -try- to correct the possible 4 detected errors if you know a derived address?
 13 2018-06-03 18:22:15	0|sipa|oh, sure
 14 2018-06-03 18:22:17	0|sipa|even more
 15 2018-06-03 18:22:20	0|sipa|there is no limit to that
 16 2018-06-03 18:22:22	0|jonasschnelli|with a 4^32 trial and error
 17 2018-06-03 18:23:14	0|gmaxwell|"-try- to correct the possible 4 detected errors" thats not how it works.
 18 2018-06-03 18:23:27	0|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
 19 2018-06-03 18:23:41	0|sipa|none of that has anything to do with correction
 20 2018-06-03 18:23:51	0|sipa|you can always try all combinations of N changes to the input, and see if they work
 21 2018-06-03 18:23:56	0|sipa|that's not limited to 4
 22 2018-06-03 18:23:59	0|sipa|and isn't called correction
 23 2018-06-03 18:24:03	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #13384: qa: Remove polling loop from test_runner (06master...06Mf1806-qaTestRunnerConcurrentFuture) 02https://github.com/bitcoin/bitcoin/pull/13384
 24 2018-06-03 18:24:15	0|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)
 25 2018-06-03 18:24:15	0|jonasschnelli|I guess I used the wrong term then...
 26 2018-06-03 18:24:45	0|sipa|jonasschnelli: my point is that there is no limit of 4 errors for that
 27 2018-06-03 18:24:56	0|jonasschnelli|I see
 28 2018-06-03 18:24:58	0|sipa|you can try all combinations of 6 changes to the input too, and see which one work
 29 2018-06-03 18:25:05	0|sipa|if you have enough computational power
 30 2018-06-03 18:26:57	0|sipa|jonasschnelli: what does "P2WPKH P2WSH nested in P2SH" mean?
 31 2018-06-03 18:27:12	0|jonasschnelli|sipa gmaxwell: is there a possible calculation on how much chars (%) could be reconstructed with a top cap of computational power?
 32 2018-06-03 18:27:20	0|sipa|jonasschnelli: all of them, obviously
 33 2018-06-03 18:27:28	0|sipa|you try every possible private key
 34 2018-06-03 18:27:33	0|sipa|this has nothing to do with the encoding
 35 2018-06-03 18:27:43	0|gmaxwell|sipa: he wants a function on cpu usage vs distance.
 36 2018-06-03 18:27:49	0|sipa|ah, sorry!
 37 2018-06-03 18:27:58	0|jonasschnelli|I mean efficient
 38 2018-06-03 18:28:30	0|jonasschnelli|what gmaxwell said. yes
 39 2018-06-03 18:28:34	0|sipa|the checksum just gives you a fixed speedup
 40 2018-06-03 18:28:40	0|sipa|larger checksums give you a better speedup
 41 2018-06-03 18:29:06	0|jonasschnelli|P2WPKH: the P2WSH part should be removed there (paste error)
 42 2018-06-03 18:29:24	0|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)
 43 2018-06-03 18:30:33	0|sipa|jonasschnelli: if you want a way to represent the current bitcoin core behaviour, it also needs P2PK
 44 2018-06-03 18:30:57	0|jonasschnelli|I thought of that... but undefined is probably okay to set in this case
 45 2018-06-03 18:31:41	0|sipa|there shouldn't be undefined IMHO; you can use the existing xprv encoding for that
 46 2018-06-03 18:32:26	0|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.
 47 2018-06-03 18:33:17	0|jonasschnelli|do you think bech32 & derived element is acceptable for reconstructing extended keys?
 48 2018-06-03 18:33:28	0|sipa|bech32 of what?
 49 2018-06-03 18:33:43	0|jonasschnelli|chaincode&privatekey
 50 2018-06-03 18:33:54	0|sipa|ah, i see
 51 2018-06-03 18:34:03	0|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.
 52 2018-06-03 18:34:04	0|sipa|i really think for private keys you want stronger error detection
 53 2018-06-03 18:34:45	0|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.
 54 2018-06-03 18:35:45	0|gmaxwell|which is also important, since if users mess up generating their public keys for a secret they'll send funds off into space.
 55 2018-06-03 18:36:57	0|jonasschnelli|So your saying the bech32 error detection is not sufficient to check the entered extended key before deriving subkeys?
 56 2018-06-03 18:37:23	0|jonasschnelli|(since 512bit exceed the bech32 90 chars limit?)
 57 2018-06-03 18:37:37	0|sipa|jonasschnelli: if you either have a vast amount of computation power, or only 1 error... sure
 58 2018-06-03 18:37:47	0|sipa|but bech32 is really the wrong choice here
 59 2018-06-03 18:39:00	0|jonasschnelli|Yes. Maybe a new cycling could would make sense...
 60 2018-06-03 18:39:12	0|sipa|I'll comment on the list
 61 2018-06-03 18:39:19	0|jonasschnelli|thanks.
 62 2018-06-03 18:39:42	0|jonasschnelli|reusing bech32 for keys instead of using Base58check is such a low hanging fruit..
 63 2018-06-03 18:39:52	0|jonasschnelli|I hope we identify a code as soon as possible
 64 2018-06-03 18:40:48	0|jonasschnelli|Bech32 is currently available in most (all?) modern bitcoin software and a support of the bech32 keys proposal would be simple to implement
 65 2018-06-03 18:41:23	0|jonasschnelli|but I guess strong error detection is more important then simple implementation properties
 66 2018-06-03 18:42:16	0|sipa|i think you underestimate the difficulty of implementing a try-all-combinations-of-errors approach which compares with addresses/utxo set
 67 2018-06-03 18:43:12	0|jonasschnelli|sipa: yes..perhaps.
 68 2018-06-03 18:50:08	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #13385: build: Guard against accidental introduction of new Boost dependencies (06master...06lint-boost) 02https://github.com/bitcoin/bitcoin/pull/13385
 69 2018-06-03 19:23:54	0|sipa|jonasschnelli: sent
 70 2018-06-03 19:24:03	0|jonasschnelli|sipa: reading...
 71 2018-06-03 19:24:23	0|jonasschnelli|and writing code to exploit 4 invalid chats in a encoded key. :)
 72 2018-06-03 19:27:14	0|jonasschnelli|sipa: can the code have a variable checksum size (runtime)? Would it make sense to delegate the reconstruct-probability to the user?
 73 2018-06-03 19:27:33	0|sipa|jonasschnelli: that sounds hard
 74 2018-06-03 19:27:58	0|jonasschnelli|ok
 75 2018-06-03 19:49:27	0|jonasschnelli|sipa, gmaxwell: guess how long it takes to compute m/0 for possible 4 invalid chars (bech32 decode & bip32 pckd, hash160 base58check)?
 76 2018-06-03 19:49:33	0|jonasschnelli|923520 attempts
 77 2018-06-03 19:49:42	0|jonasschnelli|real	1m0.189s
 78 2018-06-03 19:49:50	0|jonasschnelli|And that is with -O0 :)
 79 2018-06-03 19:55:29	0|jonasschnelli|Oops.. I missed the char. So it is 1048575 attempts... resulting in 1.5m computation power on my Core i7
 80 2018-06-03 19:55:58	0|jonasschnelli|With -O0 and parallelized
 81 2018-06-03 19:56:01	0|jonasschnelli|not parallelized
 82 2018-06-03 19:56:46	0|sipa|what length?
 83 2018-06-03 19:58:43	0|jonasschnelli|xpriv... 555 bits
 84 2018-06-03 19:59:01	0|jonasschnelli|sipa: libbtc code: https://gist.github.com/jonasschnelli/a820d1c937c58292d388f83c1c5aef94
 85 2018-06-03 19:59:15	0|jonasschnelli|Hacked down very quickly... mistakes are possible
 86 2018-06-03 20:01:42	0|sipa|there should be 3743128125 combinations to try
 87 2018-06-03 20:01:57	0|sipa|for length 111
 88 2018-06-03 20:04:49	0|jonasschnelli|sipa: Yes. There is a misstake...
 89 2018-06-03 20:05:48	0|jonasschnelli|sipa: It may result then in ~60h...
 90 2018-06-03 20:06:06	0|jonasschnelli|(assume 1048575 takes ~1min)
 91 2018-06-03 20:15:30	0|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?
 92 2018-06-03 20:29:04	0|sipa|jonasschnelli: you don't know where the 4 errors are
 93 2018-06-03 20:29:17	0|sipa|you also don't know there are 4 errors
 94 2018-06-03 20:29:47	0|sipa|you only know whether (A) there are no errors OR more than 4 or (B) something else
 95 2018-06-03 20:30:20	0|jonasschnelli|sipa: I see. That is my mistake... I assumed Bech32 allows to point to the erroneous chars.
 96 2018-06-03 20:30:31	0|sipa|jonasschnelli: nope, that requires error correction
 97 2018-06-03 20:30:34	0|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
 98 2018-06-03 20:30:55	0|sipa|if you know where the errors are, you also know what the errors are
 99 2018-06-03 20:31:12	0|jonasschnelli|sipa: I see.
100 2018-06-03 20:32:01	0|jonasschnelli|I guess a BCH that can correct 4 errors (15 checksum characters) is probably a good tradeoff
101 2018-06-03 20:32:46	0|jonasschnelli|But for 111chars.. (512bit & metadata), that is only 3.6%).
102 2018-06-03 20:33:16	0|sipa|it's 126 characters
103 2018-06-03 20:33:25	0|sipa|the errors can be in the checksum too
104 2018-06-03 20:34:11	0|jcorgan|there are four lights
105 2018-06-03 20:35:01	0|jonasschnelli|Even with correct up to 28 errors = 102 checksum would then result in "only" 13.1%.
106 2018-06-03 20:59:36	0|luke-jr|sipa: more than 4 errors is only *sometimes* indistinguishable from no-errors, I would hope?
107 2018-06-03 21:01:50	0|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 )
108 2018-06-03 21:02:27	0|sipa|luke-jr: of course
109 2018-06-03 21:03:17	0|jonasschnelli|gmaxwell: what is (length choose 4), then length of the encoded payload & checksum?
110 2018-06-03 21:04:32	0|gmaxwell|length is the length with the checksum, "choose" means use the binomial formula  https://en.wikipedia.org/wiki/Binomial_coefficient
111 2018-06-03 21:05:28	0|gmaxwell|so length! / (4! * (length-4)!)  though you'll run out of precision if you compute it that way. :P
112 2018-06-03 21:06:02	0|gmaxwell|(because length! will be enormous)
113 2018-06-03 21:06:17	0|jonasschnelli|I see
114 2018-06-03 21:08:13	0|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.
115 2018-06-03 21:08:13	0|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
116 2018-06-03 21:09:00	0|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).
117 2018-06-03 21:10:07	0|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)
118 2018-06-03 21:10:31	0|jonasschnelli|Great explanation...
119 2018-06-03 21:10:48	0|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.
120 2018-06-03 21:11:30	0|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. :)
121 2018-06-03 21:12:14	0|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)
122 2018-06-03 21:12:40	0|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.
123 2018-06-03 21:13:06	0|jonasschnelli|My core i7 can do 31’775 operations per seconds where an operation is bech32-decode->bip32-ckd->hash160->base58check
124 2018-06-03 21:13:41	0|gmaxwell|jonasschnelli: yes, so that favors supporting a small amount of list decoding, but probably not more than a half million entries or so.
125 2018-06-03 21:14:15	0|gmaxwell|You'd only need CKD and a used-address-table lookup in the inner loop.
126 2018-06-03 21:14:45	0|jonasschnelli|Probably the child key index is also required
127 2018-06-03 21:16:24	0|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.
128 2018-06-03 21:16:40	0|jonasschnelli|Yes.
129 2018-06-03 21:19:20	0|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.
130 2018-06-03 21:26:28	0|drexl|it seems like microsoft just bought github
131 2018-06-03 21:29:46	0|midnightmagic|... whaa?
132 2018-06-03 21:30:19	0|midnightmagic|just in discussions, looks like.
133 2018-06-03 21:30:31	0|jonasschnelli|https://techcrunch.com/2018/06/03/microsoft-is-reportedly-acquiring-github/
134 2018-06-03 21:30:57	0|jonasschnelli|(rumors)
135 2018-06-03 21:31:12	0|midnightmagic|Bloomberg sources..
136 2018-06-03 21:31:29	0|drexl|https://www.bloomberg.com/news/articles/2018-06-03/microsoft-is-said-to-have-agreed-to-acquire-coding-site-github?
137 2018-06-03 21:31:36	0|midnightmagic|lol gee, I wonder what will become of the platform we all depend on.
138 2018-06-03 21:32:50	0|jonasschnelli|Integrate Skype for code-review...
139 2018-06-03 21:37:27	0|gmaxwell|like skype, first they'll get rid of the git supernodes and centeralize it on their own server farm..
140 2018-06-03 21:37:28	0|gmaxwell|wait.
141 2018-06-03 21:38:25	0|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.)
142 2018-06-03 21:40:28	0|drexl|they didn't really touch linkedin, you can't even login with a microsoft account
143 2018-06-03 21:41:30	0|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.
144 2018-06-03 22:24:05	0|intcat|drexl: i don't think you used to need a linkedin account to view profiles etc
145 2018-06-03 23:21:03	0|Varunram|intcat: those changes were relatively recent
146 2018-06-03 23:31:54	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #13386: SHA256 implementations based on Intel SHA Extensions (06master...06201806_shani) 02https://github.com/bitcoin/bitcoin/pull/13386