1 2018-05-22 01:28:07	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #13300: qa: Initialize lockstack to prevent null pointer deref (06master...06Mf1805-qaLockDebug) 02https://github.com/bitcoin/bitcoin/pull/13300
  2 2018-05-22 01:40:07	0|kallewoof|Is it just me, or didn't bitcoind use to write to debug.log even with -printtoconsole=0?
  3 2018-05-22 01:40:35	0|kallewoof|Running tests now doesn't create a debug.log file at all. Unless it was moved somewhere outside of -datadir...
  4 2018-05-22 01:41:02	0|kallewoof|Oh wait, nevermind, it was in regtest/.
  5 2018-05-22 03:22:11	0|bitcoin-git|[13bitcoin] 15Empact opened pull request #13301: lint: Add linter to error on #include <*.cpp> (06master...06lint-include-cpp) 02https://github.com/bitcoin/bitcoin/pull/13301
  6 2018-05-22 06:49:36	0|fanquake|Chris_Stewart_5 Looks like you need to swap to using posix threads
  7 2018-05-22 06:49:39	0|fanquake|sudo update-alternatives --config x86_64-w64-mingw32-g++
  8 2018-05-22 06:49:51	0|fanquake|From memory you need to pick option (1)
  9 2018-05-22 06:51:08	0|fanquake|Also, if your not using Ubuntu 18.04, which recently became available in the Windows Store, I'd suggest swapping to that. We have a WIP PR #13246, with simplified build instructions.
 10 2018-05-22 06:51:11	0|gribble|https://github.com/bitcoin/bitcoin/issues/13246 | doc: Bump to Ubuntu Bionic 18.04 in build-windows.md by ken2812221 · Pull Request #13246 · bitcoin/bitcoin · GitHub
 11 2018-05-22 07:07:03	0|jonasschnelli|sipa: we once talked about a similar error correction format (more tolerant) for private keys/seeds. Are you still exploring that field?
 12 2018-05-22 07:07:12	0|jonasschnelli|(similar to bech32)
 13 2018-05-22 07:07:20	0|sipa|i haven't followed up on that
 14 2018-05-22 07:07:50	0|sipa|but i can send a mail with the possible trade-offs or os
 15 2018-05-22 07:07:57	0|jonasschnelli|sipa: Do you think it makes sense to introduce a bip32 equivalent for xpriv in bech32 with seed birthday?
 16 2018-05-22 07:09:48	0|sipa|jonasschnelli: i don't think that the path of trying to encode all of the possible metadata around a key and derivation paths into one string is feasible
 17 2018-05-22 07:09:49	0|jonasschnelli|I guess there is a lot of blockchain scans (bandwidth and CPU consumption) due to the fact that seeds have no birthday
 18 2018-05-22 07:09:54	0|sipa|perhaps birthdate can be added
 19 2018-05-22 07:10:09	0|sipa|but what about subranges
 20 2018-05-22 07:10:17	0|jonasschnelli|subranges?
 21 2018-05-22 07:10:22	0|sipa|or whether hardened or nonhardened derivation is supposed to be used
 22 2018-05-22 07:10:36	0|sipa|or if it's a multisig key, the other chains to combine it with
 23 2018-05-22 07:10:57	0|luke-jr|there's too many possible variants to even try to include it IMO
 24 2018-05-22 07:11:07	0|gmaxwell|even just versioning so such things could be added later in a compatible way...
 25 2018-05-22 07:11:09	0|sipa|or if it's a nonstandard script, do you include some template into the string too?
 26 2018-05-22 07:11:28	0|gmaxwell|luke-jr: there is a subset which is much easier, known needed, etc.
 27 2018-05-22 07:12:02	0|jonasschnelli|Yes. Maybe a version bit and a birthday is a way to start. Other metadata is also interesting but birthday is most imortant and uses almost no bytes.
 28 2018-05-22 07:12:03	0|luke-jr|perhaps just an generic id field of some sort that can include a wallet format/name
 29 2018-05-22 07:12:18	0|gmaxwell|e.g. we _know_ a birth epoch is very useful, virtually always.
 30 2018-05-22 07:12:37	0|gmaxwell|it would be kinda sad to omit that just because we're not sure on all the other fields we might want to include. :)
 31 2018-05-22 07:12:39	0|luke-jr|I'm certainly not arguing against birth epoch
 32 2018-05-22 07:12:53	0|jonasschnelli|I'd say the birthday week from 2009-01-01 would be sufficient
 33 2018-05-22 07:13:13	0|sipa|to me, eventually these things will be some standard json like description of keys/addresses/templating/...
 34 2018-05-22 07:13:29	0|luke-jr|jonasschnelli: year+week might be easier to handle in code
 35 2018-05-22 07:13:43	0|sipa|and there may be "optimizations" to it which e.g. pack the private key into the same string as the derivation path (like xprv)
 36 2018-05-22 07:13:48	0|gmaxwell|jonasschnelli: I think there was some list post where I gave some figures on resoltion vs size tradeoff.
 37 2018-05-22 07:13:55	0|sipa|and perhaps pack the derivation type along with it (bip 158)
 38 2018-05-22 07:14:01	0|sipa|and perhaps the date/time too
 39 2018-05-22 07:14:13	0|jonasschnelli|gmaxwell: Okay. I'll search for it
 40 2018-05-22 07:14:36	0|gmaxwell|luke-jr: (datetime-spec_provided_offset)/number_of_seconds_in_a_week -- it's trivial
 41 2018-05-22 07:14:37	0|sipa|but i don't like the current thinking... which is essentially that the private key "string" is all you have
 42 2018-05-22 07:14:47	0|sipa|and that everything *must* be inside of it, or it doesn't exist
 43 2018-05-22 07:14:52	0|gmaxwell|sipa: that does reflect common backup practices.
 44 2018-05-22 07:15:33	0|luke-jr|sipa: agreed
 45 2018-05-22 07:15:53	0|sipa|well it could be a single string still - but not all of it needs to be encoded into an opaque blob
 46 2018-05-22 07:16:05	0|sipa|you could have something URI like that adds extra data
 47 2018-05-22 07:16:26	0|gmaxwell|I cerantly agree with your on that point though-- some things like metadata about your txn _cannot_ be encoded in any string set upfront regardless of how long it is... and that data can be pretty critical.
 48 2018-05-22 07:16:29	0|jonasschnelli|I guess one of the problems is, that users have the idea with 24 words they have a complete backup.
 49 2018-05-22 07:16:42	0|sipa|that's just silly
 50 2018-05-22 07:16:56	0|jonasschnelli|But it is sadly the reality...
 51 2018-05-22 07:17:00	0|sipa|there's not even a way to have an version number in it
 52 2018-05-22 07:17:05	0|gmaxwell|it's also what e.g. electrum and basically claims.
 53 2018-05-22 07:17:06	0|luke-jr|jonasschnelli: we don't have to encourage bad ideas
 54 2018-05-22 07:17:41	0|gmaxwell|(I mean claims as a feature)
 55 2018-05-22 07:17:51	0|sipa|jonasschnelli: well, i think what i'm thinking is a lower level than a whole wallet
 56 2018-05-22 07:17:56	0|jonasschnelli|The Bitbox approach to backup to an SDCard seems to be accepted but people still prefer to "write down words to a paper" for backup.
 57 2018-05-22 07:18:33	0|gmaxwell|Not just to a paper, it's relatively easy to make a fire durable backup of a short string.
 58 2018-05-22 07:18:39	0|luke-jr|ideally, one would have metadata fully encrypted with a key derived from the seed, and automatically make remote backups of the metadata
 59 2018-05-22 07:19:08	0|luke-jr|then one can use the seed to recover the full metadata, assuming it's widely backed up
 60 2018-05-22 07:20:21	0|gmaxwell|right I think a better model in general would be some nice integration where your seed also lets you derrive and ID and encryption key for an encrypted backup that could be stored insecurely... and it would have all that metadata other than the most limited needed for a recovery.
 61 2018-05-22 07:20:58	0|gmaxwell|and enough data so that if your metadata is lost it's still possible to recover things, though perhaps expensive.
 62 2018-05-22 07:21:35	0|sipa|see the "future design" section here: https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2
 63 2018-05-22 07:21:39	0|gmaxwell|such a process would let backups store things like transaction notes and whatnot that could never be captured otherwise.
 64 2018-05-22 07:21:55	0|sipa|that's effectively all the non-volatile metadata you need to describe a (part of) a wallet
 65 2018-05-22 07:22:00	0|gmaxwell|and would still let users have a short key to stick in a fire safe.
 66 2018-05-22 07:27:28	0|gmaxwell|in any case if "store the metadata elsewhere" were the path, basically the seed would only need versioning and maybe a hint about the kind of derrivation paths that were used.
 67 2018-05-22 07:28:05	0|gmaxwell|sipa: one thing that isn't included in your lists, is that user really often want to protect their seeds with passwords, and doing that potentially has some overheads.
 68 2018-05-22 07:28:11	0|luke-jr|well, so long as you can derive the backup key(s), you can put the rest of the derivation in the metadata
 69 2018-05-22 07:28:22	0|gmaxwell|(alternatively or inaddition to they want to do secret sharing.)
 70 2018-05-22 07:28:52	0|sipa|gmaxwell: well this is just describing the part that it's inside the wallet; not how it is to be encoded for exporting/importing
 71 2018-05-22 07:29:02	0|gmaxwell|luke-jr: I think the idea I was thinking about there would still admit recovery from only the seed but perhaps only in a very costly manner, e.g. lots of brute force path searching or forensics to figure out what software you used.
 72 2018-05-22 07:29:26	0|gmaxwell|sipa: I know, just pointing that serializing that stuff still probably isn't enough.
 73 2018-05-22 07:29:58	0|sipa|well this doesn't describe seeds at all
 74 2018-05-22 07:30:21	0|gmaxwell|yep not faulting your document.
 75 2018-05-22 07:30:21	0|sipa|if you want a seed, you'll have some short string and a determinstic way to derive all of this from it
 76 2018-05-22 07:30:40	0|sipa|but i don't expect an ability to encode a seed _from_ that data
 77 2018-05-22 07:31:42	0|gmaxwell|luke-jr: if you can (even at some expense) recover without the 'backup' it makes the backup solution much more usable.  e.g. don't have to worry much about your backup being randsomed for 50% of your funds.
 78 2018-05-22 07:33:06	0|luke-jr|gmaxwell: true
 79 2018-05-22 07:36:35	0|jonasschnelli|what alternatives for PBKDF2 with silly static 2048 rounds for seed passphrase derivation would make sense?
 80 2018-05-22 07:36:59	0|jonasschnelli|Or are passphrase protected seed just a footgun?
 81 2018-05-22 07:37:04	0|jonasschnelli|*seeds
 82 2018-05-22 07:37:47	0|gmaxwell|2048 rounds of PBKDF2 really reeks of snake oil. It's not a meaningful amount of hardening.
 83 2018-05-22 07:38:16	0|gmaxwell|I think passphrase protected seeds are a footgun, at least if there isn't a recovery mechenism... but people want them anyways.
 84 2018-05-22 07:38:38	0|gmaxwell|And a recovery mechenism could be provided totally seperately.
 85 2018-05-22 07:39:35	0|jonasschnelli|gmaxwell: with "recovery mechanism" you mean an expensive forensic like approach to recover a lost seed-passphrase?
 86 2018-05-22 07:39:42	0|gmaxwell|I'm still fond of offloadable KDFs, which we know how to do.  But when I talked to the trezor folks about that they wanted an additional property that they be (cheaply) verifyable,  which seems possible but moves it more towards being a research problem.
 87 2018-05-22 07:42:05	0|gmaxwell|esents him with a passport with your name on it, and not otherwise).
 88 2018-05-22 07:42:05	0|gmaxwell|jonasschnelli: I mean, like, for example, your backup could contain the an encrypted copy of the passphrase  in a section accessable with the seed alone,  which you could decrypt with the help of a recovery service. E.g. to recover your wallet you need seed+passphrase OR seed + bob's help.  (e.g. your backup has an encrypted message to bob, saying that he should give the content to anyone who pr
 89 2018-05-22 07:42:22	0|gmaxwell|exactly how password recovery works is a huge rathole, unfortunately.
 90 2018-05-22 07:43:12	0|gmaxwell|Which is why I was making the point that even though I think it's unsafe design to prompt users for a password without having one,  ... it's fine to design a scheme that allows for passwords, since recovery can be provided by something else.
 91 2018-05-22 07:44:22	0|jonasschnelli|Indeed
 92 2018-05-22 07:46:27	0|gmaxwell|the problem for passphrases is that they're really kinda dumb without a KDF, if the user provides the password (and if the user doesn't come up with the password they are even more likely to forget it).
 93 2018-05-22 07:46:58	0|gmaxwell|but people also want to use these schemes with hardware wallets, which don't have the CPU power to do a KDF that a GPU wouldn't laugh at.
 94 2018-05-22 09:33:59	0|si|hello world
 95 2018-05-22 09:36:29	0|Guest72611|hi
 96 2018-05-22 10:47:09	0|bitcoin-git|13bitcoin/06master 1460ebc7d 15Daniel Kraft: trivial: Mark overrides as such....
 97 2018-05-22 10:47:09	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d82c5d15c504...6916024768ec
 98 2018-05-22 10:47:10	0|bitcoin-git|13bitcoin/06master 146916024 15MarcoFalke: Merge #13282: trivial: Mark overrides as such....
 99 2018-05-22 10:47:58	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #13282: trivial: Mark overrides as such. (06master...06mark-override) 02https://github.com/bitcoin/bitcoin/pull/13282
100 2018-05-22 15:20:57	0|jnewbery|wumpus: #13011 definitely seems ready for merge
101 2018-05-22 15:21:00	0|gribble|https://github.com/bitcoin/bitcoin/issues/13011 | Cache witness hash in CTransaction by MarcoFalke · Pull Request #13011 · bitcoin/bitcoin · GitHub
102 2018-05-22 15:55:55	0|promag|jnewbery: +1 ^
103 2018-05-22 20:16:51	0|sdaftuar|kallewoof: if you're around i was wondering if you could explain how the refactoring in #12634 relates to #12257?
104 2018-05-22 20:16:55	0|gribble|https://github.com/bitcoin/bitcoin/issues/12634 | [refactor] Make TransactionWithinChainLimit more flexible by kallewoof · Pull Request #12634 · bitcoin/bitcoin · GitHub
105 2018-05-22 20:16:58	0|gribble|https://github.com/bitcoin/bitcoin/issues/12257 | [wallet] Use destination groups instead of coins in coin select by kallewoof · Pull Request #12257 · bitcoin/bitcoin · GitHub
106 2018-05-22 20:56:17	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #13304: qa: Fix wallet_listreceivedby race (06master...06Mf1805-qaWalletRace) 02https://github.com/bitcoin/bitcoin/pull/13304
107 2018-05-22 21:01:27	0|bitcoin-git|[13bitcoin] 15jimpo opened pull request #13305: Refactor: encapsulate mapBlockIndex within validation.cpp (06master...06validation-globals) 02https://github.com/bitcoin/bitcoin/pull/13305
108 2018-05-22 21:09:59	0|bitcoin-git|[13bitcoin] 15jimpo closed pull request #13305: Refactor: encapsulate mapBlockIndex within validation.cpp (06master...06validation-globals) 02https://github.com/bitcoin/bitcoin/pull/13305
109 2018-05-22 22:18:01	0|bitcoin-git|[13bitcoin] 15theuni opened pull request #13306: build: split warnings out of CXXFLAGS (06master...06debug_flags) 02https://github.com/bitcoin/bitcoin/pull/13306
110 2018-05-22 22:56:18	0|roasbeef|jonasschnelli: re-seed stuff, have y'all seen what we made for lnd? it has all the features one would desire in a seed format: reversible mapping between seed+phrase (uses an arbitrary length tweakable block cipher), a versioning scheme (for the encryption and also the internal wallet payload), if you use a passphrase we can detect invalid attempts, and also we have a "birthdate" which is offset from the genesis block in days -- good till 2189 (iir
111 2018-05-22 22:57:02	0|roasbeef|uses proper key derivation (no like 2k rounds of sha2 or w/e lol)
112 2018-05-22 22:57:38	0|sipa|roasbeef: does proper imply variable number of rounds? :)
113 2018-05-22 22:58:27	0|roasbeef|well woudl be able to have diff versions with higher/lower number of rounds to make it easier for say hardware wallets if that's what you mean
114 2018-05-22 23:15:39	0|kallewoof|sdaftuar: When doing coin selection on groups rather than individual outputs, the ancestor/descendant stuff becomes rather messy if you don't unify them to their corresponding maximums. In order to do that, you need the values, since they are tested against multiple limits.