sipa changed the topic of #bitcoin-wizards to: This channel is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
pmxb0t has quit []
shush has quit [Remote host closed the connection]
shush has joined #bitcoin-wizards
shush has quit [Remote host closed the connection]
shush has joined #bitcoin-wizards
shush has quit [Remote host closed the connection]
shush has joined #bitcoin-wizards
shush has quit [Ping timeout: 272 seconds]
fimp has joined #bitcoin-wizards
roconnor has quit [Quit: Konversation terminated!]
<sipa>
341 is taproot; 342 is the script changes under taproot
<rottensox>
ah.
<rottensox>
:D
<rottensox>
thanks.
shush has joined #bitcoin-wizards
shush has quit [Ping timeout: 248 seconds]
mauz555 has joined #bitcoin-wizards
<jeremyrubin>
So one question that I think is kinda tricky is how to work with fixed-width integers from Bitcoin script without violating minimal encodings?
<jeremyrubin>
Should we be adding some sort of OP_PAD{32,64} that fits an integer into 32/64 bits?
<jeremyrubin>
Or just relax encoding rules?
<sipa>
in what context is this a problem?
<jeremyrubin>
I don't beleive it to be a problem at present
<jeremyrubin>
But in OP_CTV at some point, if OP_CAT is added, you may want to perform numeric operations on an item that you then concatenate onto a stack element
<jeremyrubin>
You can handle this with an if/else tree which calls OP_SIZE and then adds the correct number of zeroes I guess?
<sipa>
i don't see the problem
<sipa>
ah
<jeremyrubin>
The issue is that the stack element then gets hashed
<sipa>
you mean for nsequence/nlocktime stuff?
<jeremyrubin>
And if the encoding isn't proper, you then have an issue
<jeremyrubin>
yeah
<sipa>
ok, that wasn't clear
<jeremyrubin>
A solution??? might be to minimal encode them for the hash. But I hate that for pretty good reason
<sipa>
OP_SUBSTR to the rescue? :p
<jeremyrubin>
Hmm
<sipa>
substr(num + 0000, 0, 4)
<sipa>
conceptually
<jeremyrubin>
Ah, I guess that works?
<jeremyrubin>
So you always over pad, and then remove?
shush has joined #bitcoin-wizards
<sipa>
it's a possibility (if SUBSTR existed...)
<jeremyrubin>
I guess you can do a cat only version
justanotheruser has quit [Ping timeout: 260 seconds]
afilini has joined #bitcoin-wizards
ddustin has joined #bitcoin-wizards
ddustin has quit [Remote host closed the connection]
ddustin has joined #bitcoin-wizards
<afilini>
hi everyone, not sure if this is the right channel to discuss this but i'll try anyways.. i was playing around with descriptors lately and i realized that sometimes, in case of non-standard derivation paths, two of them are needed to describe a complete wallet (one for the "external" addresses and one for the "internal" ones). i came up with an
<afilini>
idea of using some special symbol like $ to denote one item of the path that can be either 0 or 1 depending on what kind of address is being derived, but i figured i could ask here first in case something similar already exists or in case you had better ideas
<afilini>
if you like the idea i could make a PR to rust-bitcoin, maybe to Core too but i'm not very familiar with its codebase so it would probably take a while
<sipa>
afilini: this has been suggested before, and i see the appeal, but i'm worried about scope creep
<sipa>
so far, descriptors don't really encode any information about how they're supposed to be used
<sipa>
other things of that kind are e.g. the gap size
<sipa>
or information on what hardware device(s) shoukd be queried
<sipa>
ping achow101
<sipa>
that said, it's unfortunate that you'd need to duplicate an almost entire descriptor just because you need to describe both internal and external
<sipa>
i don't know what the solution is
<afilini>
right, i get your point
<sipa>
maybe a possibility is generalizing it further, and just allow $VARNAME in key derivation paths, which then must be set by the caller
<afilini>
i had never really thought about the gap size issue, because i just thought you could overshoot it, but now that i think about it's like... trying to brute-force a few common derivations and see if you find the internal addresses, which is not really a solution but more of an hack
<sipa>
as that avoids hardcoding the concept of address/change directly... but if that's the only the varname mechanism would be used for, there isn't mucn difference with a simpler specialized approach
<sipa>
afilini: my view is just that wallets will always be more than just a descriptor
<sipa>
descriptors encode the scripts used, but you need more than that in many casds
<afilini>
well i think we could argue that the change derivation index is somehow part of the "scripts"
<afilini>
more than the gap size, which is more in the "how do we use those scripts" category
<sipa>
well, the distinction between change and payment address does not matter in all contexts
<sipa>
e.g. if you just want to scan for utxos, it's not relevant
<sipa>
for that purpose you may want to convey "this part of the key derivation path may be either 0 or 1", but it's not conveying change or not
<afilini>
right, what do 0 and 1 mean is not relevant for the descriptor
<sipa>
right
<sipa>
if there was a variable kind of thing
<sipa>
you'd say "import descriptor=blabla(.../$INT/*); change goes to INT=1, paymemts to INT=0"
<sipa>
but what if you'd want distinct descriptors for change and payments
<sipa>
do we need a syntax to "merge" two descriptors, based on a variable?