< bitcoin-git>
bitcoin/master fa6e497 MarcoFalke: rpc: Avoid "duplicate" return value for invalid submitblock
< bitcoin-git>
bitcoin/master f748944 Matt Corallo: Only set fNewBlock to true in AcceptBlock when we write to disk...
< bitcoin-git>
bitcoin/master 3f398d7 Jonas Schnelli: Merge #13439: rpc: Avoid "duplicate" return value for invalid submitblock...
< bitcoin-git>
[bitcoin] jonasschnelli closed pull request #13439: rpc: Avoid "duplicate" return value for invalid submitblock (master...2018-06-marcos-submitblock-fix) https://github.com/bitcoin/bitcoin/pull/13439
< 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?
< jonasschnelli>
^ achow101
< achow101>
jonasschnelli: not all signers need to be able to produce the private key for a public key in the derivation paths
< achow101>
that's just there as a "here is some information that may be useful, use it as you wish"
< achow101>
co signers can use different master keys
< jonasschnelli>
achow101: so in multisig accoding to Bip45 or similar, this information (BIP32 derivation path) would be of no value to the signers, right?
< achow101>
I think the derivation paths would still be useful
< jonasschnelli>
How would a cosigner figure out what key he needs to derive for signing a multisig UTXO?
< jonasschnelli>
By taking the global BIP32 keypath but not looking at the fingerprint/masterkey?
< 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
< jonasschnelli>
a) why would the signer need the fingerprint? Wouldn't the path be sufficient?
< 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.
< achow101>
a) in the bip45 case, the path would be sufficient. but bip45 is not guaranteed
< achow101>
b) then there is no need for a derivation path entry for that pubkey
< achow101>
derivation paths is only there to tell a wallet how to get the private key if it doesn't already know it
< 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
< jonasschnelli>
Alice (creator) would she need to know the fingerpritn of Bob's /Caroles master?
< achow101>
no
< achow101>
however Bob and Carol can provide it if they want to
< jonasschnelli>
achow101: would she just not provide the BIP32 derivation key/value?
< achow101>
yes, there would simply be no BIP 32 derivations if neither Bob or Carol provided their master fingerprint
< achow101>
If one provided, then there would only be one BIP 32 derivation entry
< 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?
< achow101>
yes
< achow101>
so in this case, Carol would probably want to provide the master fingerprint
< jonasschnelli>
Though, we assume now, they are using BIP45 or another deterministic MS address generation scheme...
< jonasschnelli>
Is there a K/V where Alice could tell Carol which keypath they should use without telling or knowing its fingerprint?
< achow101>
no
< jonasschnelli>
Would that make sense to have a such field? or allow BIP32 keypath without fingerprint/master key reference?
< achow101>
presumably with BIP 45 the master key fingerprint would already be known, no?
< jonasschnelli>
Yes. I think so...
< jonasschnelli>
But not if we would go with sipa change request (see ML)
< jonasschnelli>
though... eventually..
< 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...
< jonasschnelli>
I think MS creation should be possible by just sharing a range of pubkeys
< achow101>
jonasschnelli: which change? the "generic key offset" one?
< jonasschnelli>
"For that reason I would suggest that the derivation paths include the
< jonasschnelli>
full public key and chaincode of the parent or master things are
< jonasschnelli>
derived from. This does mean that the Creator needs to know the full
< jonasschnelli>
xpub which things are derived from, rather than just its fingerprin"
< achow101>
oh that.
< 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
< jonasschnelli>
I see... thanks
< jonasschnelli>
achow101: from the BIP "The master key fingerprint concatenated with the derivation path of the public key"
< jonasschnelli>
Is "public" in "public key" relevant here?
< jonasschnelli>
Since a derivation path refers to pub & priv, right?
< achow101>
the "public" isn't relevant
< 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"
< achow101>
the pubkey is the key of the KV pair for bip32 derivation paths. so I just worded it to refer to that pubkey
< jonasschnelli>
Okay. I see
< 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)?
< achow101>
no. there can be multiple bip32 derivation paths, each corresponding to a different key
< 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
< jonasschnelli>
Ah.. I see. The uniqueness is not on the k/v number (0x03) its for the whole key (ex. 0x03&pubkey)
< achow101>
yes
< jonasschnelli>
Thanks achow101
< 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?
< achow101>
how so?
< jonasschnelli>
(old clients may fail to skip k/v's they don't know)
< achow101>
the size includes the type
< jonasschnelli>
Oh.. right. I see
< achow101>
it's <size><type><key><size><value>
< achow101>
so sizes will always be known
< jonasschnelli>
Indeed. So clients can skip unknown k/v types
< achow101>
yep
< 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
< jonasschnelli>
*some
< achow101>
yeah..
< promag>
jonasschnelli: does unloadwallet lgty?
< jonasschnelli>
yes.. I just had a crash on regtest while executing generate 1 ... but not sure if it is related to that change
< jonasschnelli>
promag: can you try to load / unload and play a bit with generate 1
< jonasschnelli>
Could also be related to my disableprivatekey work
< jonasschnelli>
But in general it looks good... I think it needs other acks before merge
< promag>
you are rebased on unloadwallet?
< promag>
I hope jnewbery can look at it again
< jonasschnelli>
promag: I did some local changes on top of unloadwallet (just because I forgot to reset back to master)
< promag>
jonasschnelli: I'm on #13501 but then I'll try the above
< bitcoin-git>
[bitcoin] practicalswift opened pull request #13503: Document FreeBSD quirk. Fix FreeBSD build: Cast to int to allow std::min to work under FreeBSD. (master...document-freebsd-quirk) https://github.com/bitcoin/bitcoin/pull/13503
< bitcoin-git>
[bitcoin] practicalswift closed pull request #13503: Document FreeBSD quirk. Fix FreeBSD build: Cast to int to allow std::min to work under FreeBSD. (master...document-freebsd-quirk) https://github.com/bitcoin/bitcoin/pull/13503
< bitcoin-git>
[bitcoin] promag closed pull request #13492: Fix reply not sent when event loop terminates prematurely (master...2018-06-http-shutdown) https://github.com/bitcoin/bitcoin/pull/13492
< michagogo>
Hm, the Debian bug that keeps us in unstable just got closed
< michagogo>
Do you think that’s okay, or should we argue against that?
< bitcoin-git>
[bitcoin] skeees closed pull request #12801: Add option to only notify after wallet transactions are confirmed (master...notifycount) https://github.com/bitcoin/bitcoin/pull/12801
< jonasschnelli>
promag why is uiInterface.LoadWallet(walletInstance); called before the CreateWalletFromFile() method can't return an error?
< jonasschnelli>
s/can't/can
< 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
< bitcoin-git>
[bitcoin] jonasschnelli opened pull request #13506: Qt: load wallet in UI after possible init aborts (master...2018/06/wallet_ui) https://github.com/bitcoin/bitcoin/pull/13506