arythmetic has quit [Remote host closed the connection]
ZeroMaster has quit [Ping timeout: 240 seconds]
ZeroMaster_ has joined #bitcoin-core-dev
Guest has quit [Quit: Client closed]
brunoerg has quit [Ping timeout: 250 seconds]
arythmetic has joined #bitcoin-core-dev
arythmetic has quit [Remote host closed the connection]
arythmetic has joined #bitcoin-core-dev
arythmetic has quit [Remote host closed the connection]
arythmetic has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
arythmetic has quit [Ping timeout: 240 seconds]
rex4539 has joined #bitcoin-core-dev
rex4539 has quit [Ping timeout: 276 seconds]
AaronvanW has quit [Ping timeout: 240 seconds]
bomb-on has quit [Quit: aллилѹіа!]
sipsorcery has quit [Read error: Connection reset by peer]
brunoerg has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] pg156 opened pull request #24183: test: use MiniWallet for mempool_updatefromblock.py (master...mempool-updatefromblock-miniwallet) https://github.com/bitcoin/bitcoin/pull/24183
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
pergaminho has quit []
arythmetic has joined #bitcoin-core-dev
arythmetic has quit [Ping timeout: 240 seconds]
sdfgsdfg has joined #bitcoin-core-dev
rex4539 has joined #bitcoin-core-dev
arythmetic has joined #bitcoin-core-dev
rex4539 has quit [Ping timeout: 276 seconds]
arythmetic has quit [Ping timeout: 256 seconds]
brunoerg has quit [Ping timeout: 250 seconds]
brunoerg has joined #bitcoin-core-dev
jeremyrubin has quit [Quit: Ping timeout (120 seconds)]
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
AaronvanW has quit [Ping timeout: 256 seconds]
michagogo has quit [Quit: Connection closed for inactivity]
brunoerg has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
rex4539 has joined #bitcoin-core-dev
rex4539 has quit [Ping timeout: 276 seconds]
brunoerg has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
bairen has quit [Ping timeout: 276 seconds]
vysn has joined #bitcoin-core-dev
bairen has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] PastaPastaPasta opened pull request #24185: refactor: only use explicit reinterpret/const casts, not implicit (master...explicit-reinterpret-cast) https://github.com/bitcoin/bitcoin/pull/24185
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
sdfgsdfg has joined #bitcoin-core-dev
<stickies-v>
Is this the right place to ask for a CI retrigger? If so, could someone please restart #24098 - the fuzzer timed out but it seems unrelated to the PR.
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
vysn has quit [Ping timeout: 250 seconds]
arythmetic has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
arythmetic has quit [Ping timeout: 240 seconds]
jarthur has joined #bitcoin-core-dev
arythmetic has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 250 seconds]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] mzumsande opened pull request #24195: test: Fix failfast option for functional test runner (master...202201_testrunner_fix) https://github.com/bitcoin/bitcoin/pull/24195
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 256 seconds]
sipsorcery has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
<sdaftuar>
I'm seeing repeated ci timeouts in #20726, for the ci job "[fuzzer,address,undefined,integer, no depends]". i've tried re-running the job several times, but no luck -- each time it still times out. anyone have ideas about how to get this to complete?
cryptapus has quit [Remote host closed the connection]
<darosior>
hi
cryptapus has joined #bitcoin-core-dev
<achow101>
There's one pre-proposed meeting topic, any others people want to add?
<sipa>
hi
<darosior>
Hmm maybe i failed to add mine?
<michaelfolkson>
[18:12:49] <darosior> #proposedwalletmeetingtopic labels for ranged descriptors
<achow101>
oops, 2 pre-proposed topics
<achow101>
#topic labels for ranged descriptors (darosior)
<core-meetingbot`>
topic: labels for ranged descriptors (darosior)
brunoerg has joined #bitcoin-core-dev
<laanwj>
hi
<darosior>
So as part of the Miniscript work, i tested the branch against my application (which uses Miniscript internally and the descriptor wallet as watchonly to track 2 main descriptors) and discovered that labels are deactivated for range descriptors.
<darosior>
However labels are pretty useful to differentiate the coins when you have multiple descriptors on the same watchonly wallet (which i think is the intent?). Typically for triage in the `listsinceblock` or `listunspent` results: i think i'm just an instance and they are useful as well.
<darosior>
So i wondered what people here thought about enabling the same features to the descriptor level, to not have to add all addresses to the address book in advance (which i guessed is the reason to disable them for range descriptors in the first place?). Or if something else than labels was envisioned to enable the same features.
<darosior>
s/and they are useful as well/ and they are useful as well to others/
sipsorcery has joined #bitcoin-core-dev
<achow101>
the reason that labels were not implemented originally was because it seemed odd to me that someone would want to assign the same label to all addresses generated by a descriptor
<sipa>
What are you thinking of, something like a label template on the descriptor, with say a %i in it that gets replaced by the index?
<sipa>
Or just the same label for everything?
<achow101>
and also I think there was some complexity with applying labels to addresses that did not exist yet
<darosior>
The same label for any address derived for this descriptor. Something to say "this received coin is for this descriptor"
bomb-on has joined #bitcoin-core-dev
<achow101>
if you think it's something people will use, go for it
<michaelfolkson>
Sorry for the ELI5 but by label do you mean the subscripts of Miniscript?
<darosior>
No i mean a metadata to identify a descriptor
<darosior>
Could just add the descriptor itself to the result, i guess, although i'd to think how a client of the API would manage that
brunoerg has quit [Ping timeout: 252 seconds]
<sipa>
No, label, as in the setlabel RPC.
<sipa>
and getaddressesbylabel
<michaelfolkson>
Oh ok
<darosior>
Ok, thanks. It was mainly to know if there were prior discussions on this topic. Guess i'm done :)
<achow101>
I'm not sure I understand the use case, but I am ambivalent on this
<achow101>
#topic Taproot support in the wallet (open PRs, latest thinking) (michaelfolkson)
<core-meetingbot`>
topic: Taproot support in the wallet (open PRs, latest thinking) (michaelfolkson)
<sipa>
Likewise.
<darosior>
I can describe the motivation better in an issue, if that's helpful
<achow101>
darosior: please do
<michaelfolkson>
Ok.. so was just looking over the Taproot related PRs. #22558 is marked as high prio
bomb-on has quit [Client Quit]
<michaelfolkson>
This should be tested in tandem with #24043?
<achow101>
they are orthogonal
<michaelfolkson>
To do a Taproot multisig you need the Taproot multisig descriptor right?
<michaelfolkson>
And that is only introduced in #24043
vysn has quit [Ping timeout: 268 seconds]
<achow101>
#22558 is just for the basic taproot fields to actually be able to do any kind of watchonly taproot spend
<michaelfolkson>
But to be passing around Taproot multisig PSBTs you need to have setup a Taproot multisig.... right?
<sipa>
the multisig part is in 24043
<achow101>
psbt is for more than just multisigs
<sipa>
the taproot psbt part is in 22558
<sipa>
if you want taproot multisig psbt, then you indeed need both
<achow101>
#22558 is needed to work with HWI for example
<achow101>
just to do a single key taproot spend
bomb-on has joined #bitcoin-core-dev
<michaelfolkson>
Ah ok. So to test #24043 you should be doing a single key taproot spend
<michaelfolkson>
And then to test Taproot multisig wait for #24043 or test in tandem with #24043
<achow101>
too many 24043's in that sentence
<jonatack>
hi
<michaelfolkson>
I guess what I'm saying is to get #22558 merged test with a single key Taproot spend
<michaelfolkson>
The alternative would be to make both #22558 and #24043 high prio
<michaelfolkson>
Ok that makes sense (I think)
<achow101>
yes, 22558 can be tested with single key spends
<michaelfolkson>
So then moving to #24043
<michaelfolkson>
This seems a stopgap to me (which is fine, just testing my understanding)
<michaelfolkson>
But presumably longer term a Taproot enabled Miniscript would tell you which 2-of-3 arrangement is most efficient
<sipa>
No, that information is implied by miniscript.
<sipa>
If you have a miniscript/descriptor, the script is already decided.
<sipa>
Which one is most efficient is trivial; the question is which one is applicable.
<sipa>
Because using e.g. FROST threshold key as internal taproot key will always be the most efficient possible for any kind of multisig.
<michaelfolkson>
So when you say "later replaced with Miniscript based implementation" what are you referring to?
<sipa>
That's just an implementation aspect, not something observable.
<michaelfolkson>
I see as a descriptor as a one to one mapping with script. But Miniscript is a one to many mapping to script depending on the subscripts
<sipa>
What are subscripts?
<michaelfolkson>
Like the _a etc
<sipa>
No, miniscript is a 1-to-1 mapping with (a subset of) script.
<michaelfolkson>
Sorry shouldn't say sub*script*, makes things complicated
<sipa>
The functions in miniscript (e.g. "multi_a", "and_v", ...) we call "fragments". if you're looking for terminology.
<sipa>
Let me try to explain what that sentence was about, unless someone has something else to discuss?
<sipa>
achow101?
<michaelfolkson>
There aren't any other topics
<achow101>
I don't have any topics
<sipa>
Ok, so, currently the bitcoin core codebase doesn't have miniscript implemented.
<sipa>
Miniscript covers a bunch of different things, but it at least is sort of an extension of descriptors, as well as generic signing support for miniscript-compatible scripts, and a few other things.
<sipa>
In the long term, with the miniscript codebase integrated into bitcoin core, a significant part of the logic around descriptors and signing can be handled by miniscript, which does lots of things generically.
<michaelfolkson>
I'm thinking eventually you could almost ditch the term "descriptors" entirely. Everything would be Miniscript
<sipa>
I very strongly hope it's the other way around.
<sipa>
Miniscript is the name of research project, it's not something "visible".
<sipa>
The part that is visible are what it enables in descriptors.
<michaelfolkson>
Ok whatever, but it would all be one thing under one name
<sipa>
Definitely.
<michaelfolkson>
So this new multi_a descriptor would eventually be ditched right?
<sipa>
No?
<sipa>
In favor of what?
<michaelfolkson>
A Miniscript equivalent that would give you the script for n-of-n which is optimal
<michaelfolkson>
You say in the PR n-of-n isn't optimal, but k-of-n (k<n) is optimal
<sipa>
Once we add support for a particular descriptor we cannot remove it, as it'd break wallets that have such a descriptor.
<sipa>
michaelfolkson: Yes, and that miniscript equivalent would be called multi_a, which behaves exactly the same as the one we have now.
<sipa>
Only it'd be done via the miniscript codebase, instead of a special-case inside the descriptor codebase.
<sipa>
But as a user you wouldn't be able to tell the difference.
<michaelfolkson>
There would be multi_a for k-of-n and say a multi_b for n-of-n?
<sipa>
For example, yes.
<michaelfolkson>
Ok gotcha
<michaelfolkson>
The wallet estimating witness size incorrectly will be addressed in follow up PR?
<sipa>
Or perhaps and_v(v:pk(A),v:pk(B),...,pk(Z)).
<sipa>
Which is more in line with how miniscript treats the optimal n-of-n script.
<sipa>
Size estimation is a hard question, I don't really have a good solution.
<sipa>
You can't in general predict which branch signers will be using.
<sipa>
Perhaps something where you can pass to the fundraw* RPC which keys/signers are available.
<sipa>
I think people have discussed something like that in the past.
<michaelfolkson>
Doesn't Miniscript give you the most efficient option (and hence can estimate the witness sizes of the various spending paths)?
<michaelfolkson>
Solved by Miniscript (if we can get that merged)
<sipa>
No.
<sipa>
Miniscript is just a way of writing scripts in a different way that allows more generic reasoning over them.
<sipa>
You're talking about the miniscript policy compiler, which is one application of the things you can do with miniscript.
<Murch>
hi
<sipa>
But that's not something I'm expecting would be integrated into Bitcoin Core.
<sipa>
It's not estimating witness sizes that's hard - miniscript can do that, as can our current codebase.
<michaelfolkson>
Ok gotcha. You will be able to do that external to Core but Core won't have access to the compiler (necessarily)
<sipa>
The difficulty is making the code know which keys are available, so it knows which branch to pick.
<sipa>
That's just a logistic issue.
<michaelfolkson>
Ok final question (thanks btw). I'm assuming all the build stuff that was done for Minisketch will need to be done for Miniscript?
<sipa>
nope, nothing
<sipa>
because miniscript isn't a separate library
<sipa>
it'll just be merged into bitcoin core
brunoerg has joined #bitcoin-core-dev
<michaelfolkson>
By separate library you just mean separate repo...?
<sipa>
No.
<sipa>
Minisketch is a library you build separately, with an API, you can build applications against, ...
<sipa>
Miniscript is just a bunch of source files which are mostly intended to be integrated into Bitcoin Core.
<sipa>
The future of the repository after that point is unclear; perhaps we keep it just for the compiler/website.
<michaelfolkson>
There will be no Miniscript "API" or applications built using the Miniscript "library"?
<sipa>
Perhaps people want to spend time on actually turning the miniscript codebase into a library that's independently usable, ...
<michaelfolkson>
Oh ok you've answered that
<sipa>
That's right. It needs Bitcoin Core right now.
<sipa>
michaelfolkson: Not sure how clear that is, but what is shown/entered on my miniscript site (https://bitcoin.sipa.be/miniscript/) is two very different languages. They look similar which may make it confusing, but their purpose is completely different. One is the policy language, which is for writing "under what conditions should my output be spendable". The other is miniscript (which is a 1-to-1 mapping with Bitcoin Script, but a bit more readable). The
<sipa>
policy compiler complies policy to miniscript, by finding out the most efficient miniscript way of doing what you want, specified by the policy.
<sipa>
The thing that would be integrated into Bitcoin Core is the miniscript side of things, i.e., the output of the policy compiler if that's what you use to construct it.
ZeroMaster_ has quit [Ping timeout: 250 seconds]
sipsorcery has joined #bitcoin-core-dev
<michaelfolkson>
sipa: Right, I knew this, I was forgetting all the clever, analysis stuff happens with the compiler between Policy and Miniscript
<michaelfolkson>
And Core doesn't have access to it
<sipa>
I mean, it could... but there is no need for it. E.g. we could have a bitcoin-miniscript-compiler tool, or a "compileminiscript" RPC. But I doubt we'll want to put all that functionality inside bitcoin core, as it can be done externally just as well.
<michaelfolkson>
The new multi_a descriptor would be Taproot'd Miniscript and multi (Taproot'd Policy) would compile down to multi_a (Taproot'd Miniscript)
<sipa>
Right.
<michaelfolkson>
Or compile down to multi_b (Taproot'd Miniscript) if you were doing n-of-n
<sipa>
Once we have a taproot-enabled miniscript definition and compiler for it.
<michaelfolkson>
I think Luke said on the PR he didn't like the tag (_a) and could we avoid it. But Miniscript has a number of tags, it is normal from a Miniscript perspective
<sipa>
Yeah, and it's understandable, because right now the _a is completely redundant.
<sipa>
You can only use multi_a inside tr(), and you can only use multi outside tr().
<michaelfolkson>
Tag or fragment? I'm not sure on terminology. The literal (_a) is a tag? And the segment of Miniscript would be a fragment?
<sipa>
suffix
<sipa>
the fragment is the whole name (multi_a)
<michaelfolkson>
Ok
<sipa>
The idea is that the suffces like _a and wrappers (like the "v:" prefix) don't modify the policy implemented by the script.
<sipa>
So if you just want to get an idea of "what does this script allow", you just ignore them.
<sipa>
But they are relevant for specifying the actual script opcodes, and possibly its efficiency.
<michaelfolkson>
[19:52:04] <sipa> I mean, it could... but there is no need for it. E.g. we could have a bitcoin-miniscript-compiler tool, or a "compileminiscript" RPC. But I doubt we'll want to put all that functionality inside bitcoin core, as it can be done externally just as well.
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] jonatack opened pull request #24197: Replace lock with thread safety annotation in CBlockTreeDB::LoadBlockIndexGuts() (master...replace-lock-with-annotation-in-LoadBlockIndexGuts) https://github.com/bitcoin/bitcoin/pull/24197
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<michaelfolkson>
We can't assess the witness size for script path spends that would be a reason
<sipa>
What? No, that's unrelated.
<sipa>
Miniscript allows reasoning over witness sizes.
<sipa>
The compiler uses that functionality to figure out the optimal script for a given policy.
<sipa>
But you don't need the compiler to know the witness size for a miniscript.
ZeroMaster has joined #bitcoin-core-dev
<sipa>
The only thing you need to compiler for is constructing miniscripts in a somewhat more user-friendly way.
<sipa>
doing things with the resulting miniscript doesn't need to compiler
<michaelfolkson>
The compiler will tell you what Miniscript is most efficient based on the size of witnesses that need to be provided? Hence it has to be able to assess the witness size that will be needed to spend from that Miniscript?
<sipa>
Yes.
<sipa>
It uses the miniscript codebase to figure out which script is most efficient.
<michaelfolkson>
So as a result the compiler could assess the witness size for a script path spend
<michaelfolkson>
And solve the problem that I quoted you?
<sipa>
But the logic for determining witness sizes is in miniscript itself - so it's available to whatever uses it.
<sipa>
There is no problem to be solved.
<sipa>
Our current codebase in bitcoin core can already compute witness sizes.
<sipa>
Once we integrate miniscript, it can do that too for the new scripts supported by miniscript.
<sipa>
The "problem" is just logistical... at signing time you may not know which signers are available, and that affects which satisfaction of a script is available.
<michaelfolkson>
"Wallet code will for now estimate witness size incorrectly for script path spends" <- This is solved by merging Miniscript being merged into Core. It doesn't need access to the Policy -> Miniscript compiler to solve this problem
<sipa>
No, that problem is completely unrelated.
<sipa>
It's just because there is no way to tell the wallet which signers are available, for the third time.
<sipa>
It's not that it can't compute it.
<sipa>
It's that it doesn't know, because there is no way to tell it.
<michaelfolkson>
Ok sorry, I'll read this over again
<sipa>
Imagine you have an output that can be spent by either A and B signing, or by C signing.
brunoerg has joined #bitcoin-core-dev
<sipa>
If C is available, then a witness with 1 signature suffices.
<sipa>
If A and B are available, then a witness with 2 signatures is needed.
<sipa>
There is no way to tell fundrawtransaction etc which of these two options is going to be used, and no way to give it the information to infer it.
<sipa>
So it always assumes that whatever is cheapest/smallest will be used.
<sipa>
This problem is exacerbated by miniscript, but not unique to it.
<michaelfolkson>
fundrawtransaction doesn't know which option isn't going to be used and neither does Policy, Miniscript or the compiler. But the compiler knows the witness size needed to spend from each option
<sipa>
Yes, and so does Miniscript, and our codebase. If it knew what option was going to be used, it could compute the expected witness size.
<michaelfolkson>
Hence fundrawtransaction would want to say to the compiler "Hey this option is being used. What's the witness size needed to spend from this option?"
<sipa>
But it currently has no way of knowing.
<sipa>
This has nothing to do with the compiler!
brunoerg has quit [Ping timeout: 250 seconds]
<sipa>
All this information can be inferred from the script itself.
<sipa>
The compiler is for constructing scripts.
<sipa>
If you already have a script, the compiler isn't relevant.
<michaelfolkson>
Ok I think I get it, fundrawtransaction can easily know what the witness size to spend from an option is but it doesn't know which option will be used ahead of time