< bitcoin-git>
[bitcoin] fanquake opened pull request #16448: doc: add note on precedence of options in bitcoin.conf (master...options_bitocin_conf) https://github.com/bitcoin/bitcoin/pull/16448
< wumpus>
dongcarl: we've always regarded IPv4 as a subset of IPv6, I think to change that would need a very good reason, as it might break some things
< dongcarl>
wumpus: Sounds good
< bitcoin-git>
[bitcoin] ariard opened pull request #16452: refactor : use RelayTransaction in BroadcastTransaction utility (master...2019-07-reuse-relay-tx) https://github.com/bitcoin/bitcoin/pull/16452
< elichai2>
sipa: Hey, I'm trying to figure out what kind of descriptors makes sense *inside* a `tap(internal_key, [...tree..])` desc, I came up with a new pk(let's call it ts_pk for the conversation) and a new multi for CHECKSIGADD scripts(n-of-n), and that's it? maybe `raw()`? (I don't think sh,wsh, pkh, wpkh, combo,addr or regular pk makes sense inside of taproot/tapscripts)
< sipa>
elichai2: join ##miniscript
< sipa>
there are many things possible
< sipa>
wsh/wpkh clearly don't make sense inside taproot, as they're only valid as toplevel things or p2sh by definition
< sipa>
but i think pk/pkh should be, though perhaps by then we can just only have a miniscript variant for taproot and only support that inside taproot descriptors
< elichai2>
But tapscript modifies `OP_CHECKSIG` to be with schnorr
< sipa>
sure
< elichai2>
so then `pk()` will mean different thing inside and outside of taproot
< sipa>
but pk could have different semantics inside taproot than inside other things
< sipa>
that's already the case
< elichai2>
should it still be the same name?
< sipa>
inside p2sh the sighash is computed differently than outside
< sipa>
inside segwit it's computed even more differently
< elichai2>
he
< elichai2>
ok, makes sense. pkh doesn't make a lot of sense to me because when do you reveal the pubkey? on the same script you give the hash?
< sipa>
elichai2: in miniscript we have a pk_h that's actually preferable sometimes to pk
< sipa>
because you only put a shorter hash inside the script
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #16453: validation: Run CheckBlockIndex only on success (Fixup) (master...1907-validationCheckBlockIndexSuccess) https://github.com/bitcoin/bitcoin/pull/16453
< elichai2>
but on the spending script you'll need to supply that key anyway. (in the same tx that you reveal the script with the hash)
< sipa>
elichai2: only if the branch is actually executed
< sipa>
if the probability for that is low enough, this may be a good tradeoff
< sipa>
the miniscript compiler can figure that out :)
< elichai2>
to alliveate 32 byte of hashing computation? ok haha, i'm trying to figure out if the current non-miniscript desc makes sense. because it seems that there's some time until miniscript is really public
< sipa>
elichai2: no, to reduce the size of a satisfaction
< sipa>
20 byte hash instead of 33 byte pubkey
< elichai2>
but if that's not the spending path you reveal only the hash of the branch anyway, right?
< sipa>
right
< elichai2>
what about a SIGHASHADD multi descriptor?(n-of-n) do you think it should be a thing or people should try to stick to musig even when interactivity is a problem?
< sipa>
elichai2: the signing interactivity won't always be possible, so there definitely should be a way to use CHECKSIGADD-based multisig scripts
< sipa>
elichai2: we could have a variant of multi for that in taproot descriptors (and i'd suggest that for that it does get a different name, because the actual opcodes that correspond to it are different)
< elichai2>
Right. and I think there's no point of talking about a muSig descriptor before musig has at least a standardization proposal
< sipa>
agree
< sipa>
i think the same is true about taproot
< sipa>
but at least in terms of experimental work, we can do both
< sipa>
but regardless, we can't do without non-musig based thresholds/multisig
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #16455: doc: Remove downgrading warning in release notes, per 0.18 branch (master...1907-docReleaseNotes) https://github.com/bitcoin/bitcoin/pull/16455
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #16453: WIP: validation: Run CheckBlockIndex only on success (Fixup) (master...1907-validationCheckBlockIndexSuccess) https://github.com/bitcoin/bitcoin/pull/16453
< elichai2>
Is the right way to access the scripts in descriptors is using `ExpandHelper`? (because `MakeScripts` is private) (I have a function that parses a taproot desc and generates a tree with `DescriptorImpl` leafs, and I want to compute the right tweak)
< sipa>
elichai2: eh depends what you want to do
< sipa>
MakeScripts is the node-type-specific function to be overridden
< sipa>
ExpandHelper is what invokes things recursively etc
< elichai2>
let's say I have a `PKDescriptor` descriptor there I would want to get the `KEY OP_CHECKSIG` script so I can hash it. it seems that naivley MakeScripts does it but it's designed as you said to be used internally by ExpandHelper
< sipa>
everything is expanded into the FlatSigningProvider
< sipa>
you'll need to add some interface to SigningProvider to access taproot pubkey->key or pubkey->(merklebranch,script) things
< elichai2>
does it expand in `ParseScript` already? or do I need to call something to make it expand there?
< sipa>
ParseScript just builds the Descriptor objects
< sipa>
filling the FlatSigningProvider happens through the Expand* functions
< elichai2>
Ok. So I'll make my TapDescriptor contain DescriptorImpls and not scripts and i'll expand them later when needed. Thanks!