--- Day changed Wed Oct 30 2019
00:19 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 252 seconds]     
01:22 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Ping timeout: 250 seconds]     
02:00 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined ##hwi     
02:08 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined ##hwi     
02:23 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 265 seconds]     
02:24 -!- jonatack [~jon@213.152.161.219] has joined ##hwi     
02:29 -!- jonatack_ [~jon@54.76.13.109.rev.sfr.net] has joined ##hwi     
02:30 -!- jonatack [~jon@213.152.161.219] has quit [Ping timeout: 276 seconds]     
02:33 -!- jonatack_ [~jon@54.76.13.109.rev.sfr.net] has quit [Client Quit]     
02:34 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined ##hwi     
02:38 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 252 seconds]     
02:40 -!- jonatack [~jon@213.152.161.138] has joined ##hwi     
03:54 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined ##hwi     
04:40 -!- jonatack [~jon@213.152.161.138] has quit [Ping timeout: 245 seconds]     
07:35 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined ##hwi     
07:55 < ghost43> what's the thinking re prime "'" vs "h" in key origin strings? it seems HWI defaults to "h", right? I guess "h" might be more user-friendly than "'"
08:13 < achow101> h doesn't require escaping and other terminal fuckery
08:14 < achow101> technically, bip32 specifies that hardened steps are denoted with a subscript H. h is close enough to that. I don't know where the ' notation came from or why it's so widely used now
08:31 < gwillen> the prime notation is very easy to read by eye / write on paper
08:31 < gwillen> but like, the h notation is _so_ much easier to work with because of the quoting thing
08:31 < gwillen> that the prime notation seems like kind of a mistake to ever use in a concrete syntax
10:05 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 276 seconds]     
10:26 < ghost43> good point re terminal escaping... thanks
10:34 < ghost43> achow101: re bip174, PSBT_IN_BIP32_DERIVATION, I was talking with ThomasV and we realised we had different interpretations of the spec. what is meant by "master key fingerprint"? I was thinking it should be the root fingerprint. He was thinking it could be either the root fp, or the intermediate xpub's fp, (with "derivation path" meaning full path vs only derivation suffix (path after that node) correspondingly). The point is that if we don't know key
10:34 < ghost43> origin info for a cosigner, we could put the fp of the intermediate node and the derivation suffix there; and then the "updater" of that cosigner could recognise that this is happening and potentially change it to the full path and root fp, and then he could maybe also add the global xpub field into the psbt. The question is can an updater be expected to do this however? Is it expected to handle both the root fp + full path and the intermediate fp +
10:34 < ghost43> der suffix cases. It does not seem clear from the BIP.
10:35 < ghost43> Clearly in "our" updater we could implement whatever; but regarding interop...
10:41 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has quit [Read error: Connection reset by peer]     
10:43 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined ##hwi     
10:45 < achow101> ghost43: The master fingerprint can be the root or an intermediate's. I think you can expect an updater to add "more correct" information to a psbt
10:47 < achow101> Core will overwrite information for pubkeys it knows about
10:50 < achow101> but really, I think each party is supposed to have their own updater that processes the psbt first, so you shouldn't have an updater add the key deriv info for a signer that isn't its
10:53 < ghost43> that sounds nice in theory, but in practice it mandates an extra round of comms
10:54 < ghost43> because it means the first user will not be able to sign until everyone's updater processed the tx
10:55 < ghost43> specifically thinking about multisig inputs and change outputs for example
10:56 < ghost43> to be clear about what Core does; this presupposes that the public keys are within Core's gap limit, right?
10:57 < achow101> yes     
12:04 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Quit: jonatack]     
12:04 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined ##hwi     
12:11 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Quit: jonatack]     
12:11 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined ##hwi     
12:30 < ghost43> achow101: but if the root fp and full path is there, in PSBT_IN_BIP32_DERIVATION, and it's beyond the gap limit, can Core then sign?
12:31 < achow101> Core won't sign if it is beyond the gap limit
12:32 < achow101> it doesn't actually look at the derivation path info
12:34 < ghost43> that's... weird
12:34 < ghost43> I imagine it's due to legacy codebase reasons :P
12:37 < ghost43> so, if I have an offline bitcoin core and an online bitcoin core, and I try to use PSBTs to offline sign, then it will suddenly stop working when it reaches the gap limit? e.g. 1000 addresses?
12:37 < ghost43> but it would work initially?
13:43 < achow101> yeah, that's due to legacy reasons. so right now, if you are using keys that haven't been generated yet, it won't work
13:44 < achow101> but you can use keypoolrefill to just add more keys to the keypool
13:44 < ghost43> how many is "more"? or how does that work? ideally it should look at the psbt and either generate all keys up to that point or just take the derivation for there
13:45 < ghost43> from*
13:51 < achow101> there's an argument to specify how many you want to add to the keypool
13:51 < achow101> without the argument, it just fills to 1000 (or whatever you configured the keypool size to be)
22:09 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has quit [Remote host closed the connection]     
22:17 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined ##hwi