1 2018-06-19 00:11:34	0|sipa|gmaxwell: z85 also excludes _
  2 2018-06-19 00:11:37	0|sipa|that's the 9th one
  3 2018-06-19 00:11:57	0|sipa|seems indeed a bit of a strange choice: "',;\_`|~
  4 2018-06-19 00:39:52	0|gmaxwell|sipa: I wonder why _ ?
  5 2018-06-19 00:45:53	0|sipa|no clue
  6 2018-06-19 07:24:27	0|bitcoin-git|[13bitcoin] 15jonasschnelli pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/088240685456...3f398d7a17f1
  7 2018-06-19 07:24:28	0|bitcoin-git|13bitcoin/06master 14fa6e497 15MarcoFalke: rpc: Avoid "duplicate" return value for invalid submitblock
  8 2018-06-19 07:24:29	0|bitcoin-git|13bitcoin/06master 143f398d7 15Jonas Schnelli: Merge #13439: rpc: Avoid "duplicate" return value for invalid submitblock...
  9 2018-06-19 07:24:29	0|bitcoin-git|13bitcoin/06master 14f748944 15Matt Corallo: Only set fNewBlock to true in AcceptBlock when we write to disk...
 10 2018-06-19 07:25:28	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #13439: rpc: Avoid "duplicate" return value for invalid submitblock (06master...062018-06-marcos-submitblock-fix) 02https://github.com/bitcoin/bitcoin/pull/13439
 11 2018-06-19 08:05:36	0|jonasschnelli|Regarding BIP174 (PSBT), the BIP32 derivation path is global, does that mean that each Co-Signer must use the same master key? Or is that global value per PSBT file which is per co-signer different?
 12 2018-06-19 08:05:50	0|jonasschnelli|^ achow101
 13 2018-06-19 08:06:45	0|achow101|jonasschnelli: not all signers need to be able to produce the private key for a public key in the derivation paths
 14 2018-06-19 08:07:04	0|achow101|that's just there as a "here is some information that may be useful, use it as you wish"
 15 2018-06-19 08:07:24	0|achow101|co signers can use different master keys
 16 2018-06-19 08:07:46	0|jonasschnelli|achow101: so in multisig accoding to Bip45 or similar, this information (BIP32 derivation path) would be of no value to the signers, right?
 17 2018-06-19 08:08:59	0|achow101|I think the derivation paths would still be useful
 18 2018-06-19 08:09:23	0|jonasschnelli|How would a cosigner figure out what key he needs to derive for signing a multisig UTXO?
 19 2018-06-19 08:10:09	0|jonasschnelli|By taking the global BIP32 keypath but not looking at the fingerprint/masterkey?
 20 2018-06-19 08:10:38	0|achow101|jonasschnelli: the idea is that suppose you have a signer who just has a master private key. Using the derivation paths, he can find which pubkeys that he can sign for because they have his master key fingerprint so then he can derive their private keys and sign
 21 2018-06-19 08:12:25	0|jonasschnelli|a) why would the signer need the fingerprint? Wouldn't the path be sufficient?
 22 2018-06-19 08:13:14	0|jonasschnelli|b) What if creator and signer are in a non trusted relationship... the only thing i'd like to tell the creator – if I would be a signer – is my pubkey for creating the MS address.
 23 2018-06-19 08:13:26	0|achow101|a) in the bip45 case, the path would be sufficient. but bip45 is not guaranteed
 24 2018-06-19 08:13:57	0|achow101|b) then there is no need for a derivation path entry for that pubkey
 25 2018-06-19 08:14:32	0|achow101|derivation paths is only there to tell a wallet how to get the private key if it doesn't already know it
 26 2018-06-19 08:14:46	0|jonasschnelli|Okay. I see. I think it was not obvious to me by reading the BIP that one could fill in the path but present 0 bytes for the fingerprint
 27 2018-06-19 08:15:07	0|achow101|... that is not allowed
 28 2018-06-19 08:15:16	0|jonasschnelli|hmm...
 29 2018-06-19 08:15:44	0|jonasschnelli|achow101: Can we go through the BIP 2-of-3 usecase: https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#2-of-3-multisig-workflow?
 30 2018-06-19 08:15:48	0|gribble|https://github.com/bitcoin/bitcoin/issues/2 | Long-term, safe, store-of-value · Issue #2 · bitcoin/bitcoin · GitHub
 31 2018-06-19 08:16:02	0|achow101|ok..
 32 2018-06-19 08:16:16	0|jonasschnelli|Alice (creator) would she need to know the fingerpritn of Bob's /Caroles master?
 33 2018-06-19 08:16:46	0|achow101|no
 34 2018-06-19 08:16:57	0|achow101|however Bob and Carol can provide it if they want to
 35 2018-06-19 08:17:11	0|jonasschnelli|achow101: would she just not provide the BIP32 derivation key/value?
 36 2018-06-19 08:17:35	0|achow101|yes, there would simply be no BIP 32 derivations if neither Bob or Carol provided their master fingerprint
 37 2018-06-19 08:17:59	0|achow101|If one provided, then there would only be one BIP 32 derivation entry
 38 2018-06-19 08:18:05	0|jonasschnelli|But that means, Carol (HWW) would need a map of utxo-addresses-to-keypath in order to derive the key required for signing, right?
 39 2018-06-19 08:18:29	0|achow101|yes
 40 2018-06-19 08:18:41	0|achow101|so in this case, Carol would probably want to provide the master fingerprint
 41 2018-06-19 08:18:58	0|jonasschnelli|Though, we assume now, they are using BIP45 or another deterministic MS address generation scheme...
 42 2018-06-19 08:19:20	0|jonasschnelli|Is there a K/V where Alice could tell Carol which keypath they should use without telling or knowing its fingerprint?
 43 2018-06-19 08:19:50	0|achow101|no
 44 2018-06-19 08:20:13	0|jonasschnelli|Would that make sense to have a such field? or allow BIP32 keypath without fingerprint/master key reference?
 45 2018-06-19 08:20:52	0|achow101|presumably with BIP 45 the master key fingerprint would already be known, no?
 46 2018-06-19 08:21:22	0|jonasschnelli|Yes. I think so...
 47 2018-06-19 08:21:46	0|jonasschnelli|But not if we would go with sipa change request (see ML)
 48 2018-06-19 08:22:08	0|jonasschnelli|though... eventually..
 49 2018-06-19 08:22:56	0|jonasschnelli|achow101: I was just playing an example in my head where cosigner would not share xpubs (not BIP45) since sharing the xpub is a security and privacy risk...
 50 2018-06-19 08:23:14	0|jonasschnelli|I think MS creation should be possible by just sharing a range of pubkeys
 51 2018-06-19 08:23:18	0|achow101|jonasschnelli: which change? the "generic key offset" one?
 52 2018-06-19 08:23:32	0|jonasschnelli|derived from. This does mean that the Creator needs to know the full
 53 2018-06-19 08:23:32	0|jonasschnelli|"For that reason I would suggest that the derivation paths include the
 54 2018-06-19 08:23:32	0|jonasschnelli|full public key and chaincode of the parent or master things are
 55 2018-06-19 08:23:32	0|jonasschnelli|xpub which things are derived from, rather than just its fingerprin"
 56 2018-06-19 08:23:40	0|achow101|oh that.
 57 2018-06-19 08:25:22	0|achow101|jonasschnelli: not having a bip32 derivation path entry is completely fine. The signers just need to parse the redeemscript for that input to figure out what keys are required and check whether they have them
 58 2018-06-19 08:25:47	0|jonasschnelli|I see... thanks
 59 2018-06-19 08:27:18	0|jonasschnelli|achow101: from the BIP "The master key fingerprint concatenated with the derivation path of the public key"
 60 2018-06-19 08:27:27	0|jonasschnelli|Is "public" in "public key" relevant here?
 61 2018-06-19 08:27:39	0|jonasschnelli|Since a derivation path refers to pub & priv, right?
 62 2018-06-19 08:27:53	0|achow101|the "public" isn't relevant
 63 2018-06-19 08:28:17	0|jonasschnelli|Same here: "Public keys can be those that will be needed to sign any type of key hash input or is spent to by an output"
 64 2018-06-19 08:28:46	0|achow101|the pubkey is the key of the KV pair for bip32 derivation paths. so I just worded it to refer to that pubkey
 65 2018-06-19 08:29:13	0|jonasschnelli|Okay. I see
 66 2018-06-19 08:31:41	0|jonasschnelli|achow101: again for my clarification (sorry if I'm bothering you): using the 0x03 type (BIP32 derivation path) would mean, that each Co-Signer (in case of a multisig) would require to use the same masterkey (if we assume they have no capabilities to derive keys based on just the pubkey)?
 67 2018-06-19 08:32:28	0|achow101|no. there can be multiple bip32 derivation paths, each corresponding to a different key
 68 2018-06-19 08:33:08	0|achow101|so pubkey 1 can have master key 1 and derivation path 1, and pubkey 2 can have a different master key 2 and derivation path 2. both get their own 0x03 type records
 69 2018-06-19 08:34:48	0|jonasschnelli|Ah.. I see. The uniqueness is not on the k/v number (0x03) its for the whole key (ex. 0x03&pubkey)
 70 2018-06-19 08:35:14	0|achow101|yes
 71 2018-06-19 08:36:45	0|jonasschnelli|Thanks achow101
 72 2018-06-19 08:38:54	0|jonasschnelli|achow101: the current K/V value type (k/v size depending on type) seems to disallow backward compatibility, is that sipa point on the mailing list?
 73 2018-06-19 08:39:07	0|achow101|how so?
 74 2018-06-19 08:39:14	0|jonasschnelli|(old clients may fail to skip k/v's they don't know)
 75 2018-06-19 08:39:30	0|achow101|the size includes the type
 76 2018-06-19 08:39:41	0|jonasschnelli|Oh.. right. I see
 77 2018-06-19 08:39:48	0|achow101|it's <size><type><key><size><value>
 78 2018-06-19 08:39:56	0|achow101|so sizes will always be known
 79 2018-06-19 08:40:13	0|jonasschnelli|Indeed. So clients can skip unknown k/v types
 80 2018-06-19 08:40:24	0|achow101|yep
 81 2018-06-19 08:41:22	0|jonasschnelli|Okay. I see the point on the ML was more that, instead of K/V, we could use a set of record... since somce K/V have acctually no K
 82 2018-06-19 08:41:25	0|jonasschnelli|*some
 83 2018-06-19 08:41:37	0|achow101|yeah..
 84 2018-06-19 09:03:04	0|promag|jonasschnelli: does unloadwallet lgty?
 85 2018-06-19 09:03:32	0|jonasschnelli|yes.. I just had a crash on regtest while executing generate 1 ... but not sure if it is related to that change
 86 2018-06-19 09:04:02	0|jonasschnelli|promag: can you try to load / unload and play a bit with generate 1
 87 2018-06-19 09:04:14	0|jonasschnelli|Could also be related to my disableprivatekey work
 88 2018-06-19 09:04:30	0|jonasschnelli|But in general it looks good... I think it needs other acks before merge
 89 2018-06-19 09:04:35	0|promag|you are rebased on unloadwallet?
 90 2018-06-19 09:04:58	0|promag|I hope jnewbery can look at it again
 91 2018-06-19 09:37:59	0|jonasschnelli|promag: I did some local changes on top of unloadwallet (just because I forgot to reset back to master)
 92 2018-06-19 09:39:07	0|promag|jonasschnelli: I'm on #13501 but then I'll try the above
 93 2018-06-19 09:39:09	0|gribble|https://github.com/bitcoin/bitcoin/issues/13501 | Remove race on shutdown between event loop exit and http reply by promag · Pull Request #13501 · bitcoin/bitcoin · GitHub
 94 2018-06-19 10:30:35	0|hri|hi
 95 2018-06-19 13:47:47	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #13503: Document FreeBSD quirk. Fix FreeBSD build: Cast to int to allow std::min to work under FreeBSD. (06master...06document-freebsd-quirk) 02https://github.com/bitcoin/bitcoin/pull/13503
 96 2018-06-19 14:27:00	0|bitcoin-git|[13bitcoin] 15practicalswift closed pull request #13503: Document FreeBSD quirk. Fix FreeBSD build: Cast to int to allow std::min to work under FreeBSD. (06master...06document-freebsd-quirk) 02https://github.com/bitcoin/bitcoin/pull/13503
 97 2018-06-19 17:04:27	0|bitcoin-git|[13bitcoin] 15promag closed pull request #13492: Fix reply not sent when event loop terminates prematurely (06master...062018-06-http-shutdown) 02https://github.com/bitcoin/bitcoin/pull/13492
 98 2018-06-19 17:32:59	0|promag_|wumpus: MarcoFalke: cfields: fyi #13501
 99 2018-06-19 17:33:00	0|gribble|https://github.com/bitcoin/bitcoin/issues/13501 | Remove race on shutdown between event loop exit and http reply by promag · Pull Request #13501 · bitcoin/bitcoin · GitHub
100 2018-06-19 17:59:57	0|michagogo|Hm, the Debian bug that keeps us in unstable just got closed
101 2018-06-19 18:12:46	0|michagogo|Do you think that’s okay, or should we argue against that?
102 2018-06-19 18:44:49	0|bitcoin-git|[13bitcoin] 15skeees closed pull request #12801: Add option to only notify after wallet transactions are confirmed (06master...06notifycount) 02https://github.com/bitcoin/bitcoin/pull/12801
103 2018-06-19 18:51:27	0|jonasschnelli|promag why is uiInterface.LoadWallet(walletInstance); called before the CreateWalletFromFile() method can't return an error?
104 2018-06-19 18:51:42	0|jonasschnelli|s/can't/can
105 2018-06-19 18:52:30	0|jonasschnelli|I think uiInterface.LoadWallet(walletInstance); displays the wallet in the GUI but there are various cases where CreateWalletFromFile will refuse loading the wallet after that uiInterface call
106 2018-06-19 19:39:46	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #13506: Qt: load wallet in UI after possible init aborts (06master...062018/06/wallet_ui) 02https://github.com/bitcoin/bitcoin/pull/13506
107 2018-06-19 19:46:16	0|promag|jonasschnelli: yes, that needs a fix
108 2018-06-19 19:46:31	0|jonasschnelli|promag: See #13506
109 2018-06-19 19:46:32	0|gribble|https://github.com/bitcoin/bitcoin/issues/13506 | Qt: load wallet in UI after possible init aborts by jonasschnelli · Pull Request #13506 · bitcoin/bitcoin · GitHub
110 2018-06-19 19:46:58	0|promag|i think its the same problem in https://github.com/bitcoin/bitcoin/pull/13097#issuecomment-398445833
111 2018-06-19 19:48:08	0|promag|oh that's a new issue
112 2018-06-19 19:55:53	0|promag|jonasschnelli: your fix is obviously correct
113 2018-06-19 19:56:14	0|jonasschnelli|promag: I wasn't sure but could not find a reason why it can't be called later
114 2018-06-19 19:56:51	0|promag|like I said in your PR, the bug was already there before #13063
115 2018-06-19 19:56:54	0|gribble|https://github.com/bitcoin/bitcoin/issues/13063 | Use shared pointer to retain wallet instance by promag · Pull Request #13063 · bitcoin/bitcoin · GitHub
116 2018-06-19 19:57:56	0|promag|there are a couple of places with "CWallet::CreateWalletFromFile(...); if (!wallet) error; AddWallet(...)"
117 2018-06-19 19:59:09	0|promag|I have a branch with CWallet::LoadWalletFromFile that does that (also WalletManager::LoadWalletFromFile)
118 2018-06-19 20:03:39	0|jonasschnelli|Indeed
119 2018-06-19 21:35:50	0|bitcoin-git|[13bitcoin] 15kristapsk opened pull request #13507: RPC: Fix parameter count check for importpubkey. (06master...06importpubkey) 02https://github.com/bitcoin/bitcoin/pull/13507
120 2018-06-19 23:07:23	0|lqz|whoami
121 2018-06-19 23:07:26	0|lqz|ls
122 2018-06-19 23:08:00	0|lqz|whois