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
RiscTaker has quit []
queip has quit [Ping timeout: 276 seconds]
queip has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
marcoagner has quit [Ping timeout: 246 seconds]
romtam has joined #bitcoin-wizards
michaelfolkson has quit [Ping timeout: 246 seconds]
shush has quit [Remote host closed the connection]
shush has joined #bitcoin-wizards
queip has quit [Ping timeout: 240 seconds]
queip has joined #bitcoin-wizards
shush has quit [Remote host closed the connection]
shush has joined #bitcoin-wizards
TheoStorm has quit [Quit: Leaving]
AaronvanW has quit [Remote host closed the connection]
shush has quit [Ping timeout: 252 seconds]
shush has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 246 seconds]
queip has quit [Ping timeout: 276 seconds]
slivera has joined #bitcoin-wizards
queip has joined #bitcoin-wizards
riclas has quit [Ping timeout: 265 seconds]
riclas has joined #bitcoin-wizards
nuncanada has quit [Quit: Leaving]
Belkaar_ has joined #bitcoin-wizards
Belkaar has quit [Ping timeout: 268 seconds]
romtam has quit []
queip_ has joined #bitcoin-wizards
queip has quit [Ping timeout: 268 seconds]
queip_ is now known as queip
perrier_ has joined #bitcoin-wizards
reallll has joined #bitcoin-wizards
belcher has quit [Ping timeout: 246 seconds]
queip has quit [Ping timeout: 250 seconds]
queip has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
shush has quit []
queip has quit [Ping timeout: 276 seconds]
lowentropy has quit [Remote host closed the connection]
queip has joined #bitcoin-wizards
lowentropy has joined #bitcoin-wizards
wk057 has quit [Read error: Connection reset by peer]
wk057 has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 265 seconds]
rusty has quit [Quit: Leaving.]
queip has quit [Ping timeout: 265 seconds]
queip has joined #bitcoin-wizards
justanotheruser has quit [Ping timeout: 276 seconds]
queip has quit [Ping timeout: 250 seconds]
queip has joined #bitcoin-wizards
wk057 has quit [Read error: Connection reset by peer]
queip has quit [Ping timeout: 250 seconds]
wk057 has joined #bitcoin-wizards
queip has joined #bitcoin-wizards
kenshi84_ has joined #bitcoin-wizards
justanotheruser has joined #bitcoin-wizards
kenshi84 has quit [Ping timeout: 250 seconds]
exho has quit [*.net *.split]
wraithm has quit [*.net *.split]
forrestv has quit [*.net *.split]
GAit has quit [*.net *.split]
bxbxb has quit [*.net *.split]
dEBRUYNE has quit [*.net *.split]
gambpang has quit [*.net *.split]
chjj has quit [*.net *.split]
x-warrior has quit [*.net *.split]
kaalia has quit [*.net *.split]
Nebraskka has quit [*.net *.split]
queip has quit [Ping timeout: 250 seconds]
queip has joined #bitcoin-wizards
GAit has joined #bitcoin-wizards
bxbxb has joined #bitcoin-wizards
forrestv has joined #bitcoin-wizards
wraithm has joined #bitcoin-wizards
gambpang has joined #bitcoin-wizards
exho has joined #bitcoin-wizards
dEBRUYNE has joined #bitcoin-wizards
x-warrior has joined #bitcoin-wizards
chjj has joined #bitcoin-wizards
kaalia has joined #bitcoin-wizards
Nebraskka has joined #bitcoin-wizards
perrier_ has quit []
AaronvanW has joined #bitcoin-wizards
achow101 has quit [Quit: ZNC 1.7.4+deb0+bionic0 - https://znc.in]
rusty has joined #bitcoin-wizards
mryandao_ has quit [Remote host closed the connection]
achow101 has joined #bitcoin-wizards
mryandao has joined #bitcoin-wizards
alorente has joined #bitcoin-wizards
rusty has quit [Quit: Leaving.]
wk057 has quit [Read error: Connection reset by peer]
wk057 has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 276 seconds]
slivera has quit [Remote host closed the connection]
tromp has quit [Remote host closed the connection]
wk057 has quit [Read error: Connection reset by peer]
wk057 has joined #bitcoin-wizards
queip has quit [Ping timeout: 252 seconds]
queip has joined #bitcoin-wizards
berndj has quit [Ping timeout: 240 seconds]
berndj has joined #bitcoin-wizards
reallll is now known as belcher
Guyver2 has joined #bitcoin-wizards
wk057 has quit [Read error: Connection reset by peer]
wk057 has joined #bitcoin-wizards
queip has quit [Ping timeout: 265 seconds]
queip has joined #bitcoin-wizards
wk057 has quit [Read error: Connection reset by peer]
wk057 has joined #bitcoin-wizards
justanotheruser has quit [Ping timeout: 245 seconds]
tromp has joined #bitcoin-wizards
wk057 has quit [Read error: Connection reset by peer]
justanotheruser has joined #bitcoin-wizards
wk057 has joined #bitcoin-wizards
wk057 has quit [Read error: Connection reset by peer]
AaronvanW has joined #bitcoin-wizards
wk057 has joined #bitcoin-wizards
wk057 has quit [Read error: Connection reset by peer]
tromp has quit [Remote host closed the connection]
antanst- has quit [Ping timeout: 245 seconds]
antanst has joined #bitcoin-wizards
wk057 has joined #bitcoin-wizards
wk057 has quit [Read error: Connection reset by peer]
Socoro has joined #bitcoin-wizards
wk057 has joined #bitcoin-wizards
wk057 has quit [Read error: Connection reset by peer]
wk057 has joined #bitcoin-wizards
alorente has quit []
marcoagner has joined #bitcoin-wizards
CryptoDavid_ has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
CryptoDavid_ has quit []
CryptoDavid_ has joined #bitcoin-wizards
CryptoDavid_ has quit [Client Quit]
wk057 has quit [Read error: Connection reset by peer]
CryptoDavid_ has joined #bitcoin-wizards
CryptoDavid_ has quit []
AaronvanW has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-wizards
CryptoDavid_ has joined #bitcoin-wizards
wk057 has joined #bitcoin-wizards
nijynot has joined #bitcoin-wizards
doitux|mob has joined #bitcoin-wizards
justanotheruser has quit [Ping timeout: 252 seconds]
queip has quit [Ping timeout: 268 seconds]
queip has joined #bitcoin-wizards
jonatack_ has joined #bitcoin-wizards
jonatack has quit [Ping timeout: 268 seconds]
justanotheruser has joined #bitcoin-wizards
antanst- has joined #bitcoin-wizards
antanst has quit [Ping timeout: 252 seconds]
slivera has joined #bitcoin-wizards
justanotheruser has quit [Ping timeout: 265 seconds]
justanotheruser has joined #bitcoin-wizards
stiell has quit [Ping timeout: 276 seconds]
gtklocker has joined #bitcoin-wizards
TheoStorm has joined #bitcoin-wizards
simian_za has joined #bitcoin-wizards
riclas has quit [Ping timeout: 268 seconds]
doitux|mob has quit []
CryptoDavid_ has quit [Quit: Connection closed for inactivity]
shesek has joined #bitcoin-wizards
shesek has quit [Changing host]
shesek has joined #bitcoin-wizards
queip has quit [Ping timeout: 268 seconds]
queip has joined #bitcoin-wizards
queip has quit [Ping timeout: 245 seconds]
queip has joined #bitcoin-wizards
khorben1 has joined #bitcoin-wizards
jtimon has joined #bitcoin-wizards
slivera has quit [Remote host closed the connection]
wk057 has quit [Ping timeout: 268 seconds]
Jeremy_Rand_Talo has quit [Read error: Connection reset by peer]
dl3br[m] has quit [Write error: Connection reset by peer]
kewde[m] has quit [Write error: Connection reset by peer]
azdrianz[m] has quit [Remote host closed the connection]
M7918070_[m] has quit [Read error: Connection reset by peer]
hasu[m] has quit [Remote host closed the connection]
hsngrmpf[m] has quit [Remote host closed the connection]
tomtau[m] has quit [Write error: Connection reset by peer]
charuto has quit [Read error: Connection reset by peer]
TheFuzzStone[m] has quit [Read error: Connection reset by peer]
catcow has quit [Remote host closed the connection]
queip has quit [Ping timeout: 276 seconds]
queip has joined #bitcoin-wizards
TheoStorm has quit [Remote host closed the connection]
justanotheruser has quit [Ping timeout: 252 seconds]
queip has quit [Ping timeout: 268 seconds]
queip has joined #bitcoin-wizards
justanotheruser has joined #bitcoin-wizards
queip has quit [Ping timeout: 246 seconds]
queip has joined #bitcoin-wizards
queip has quit [Ping timeout: 245 seconds]
queip has joined #bitcoin-wizards
queip has quit [Ping timeout: 245 seconds]
queip has joined #bitcoin-wizards
wk057 has joined #bitcoin-wizards
queip has quit [Ping timeout: 250 seconds]
queip_ has joined #bitcoin-wizards
queip_ is now known as queip
wk057 has quit [Ping timeout: 268 seconds]
queip has quit [Ping timeout: 245 seconds]
queip has joined #bitcoin-wizards
khorben1 has quit []
Jeremy_Rand_Talo has joined #bitcoin-wizards
M7918070_[m] has joined #bitcoin-wizards
dl3br[m] has joined #bitcoin-wizards
azdrianz[m] has joined #bitcoin-wizards
tomtau[m] has joined #bitcoin-wizards
kewde[m] has joined #bitcoin-wizards
TheFuzzStone[m] has joined #bitcoin-wizards
catcow has joined #bitcoin-wizards
charuto has joined #bitcoin-wizards
hsngrmpf[m] has joined #bitcoin-wizards
hasu[m] has joined #bitcoin-wizards
lcb has joined #bitcoin-wizards
TheoStorm has joined #bitcoin-wizards
stiell has joined #bitcoin-wizards
hasu[m] has quit [Quit: User has been idle for 30+ days.]
queip has quit [Ping timeout: 252 seconds]
queip_ has joined #bitcoin-wizards
queip_ is now known as queip
queip has quit [Ping timeout: 276 seconds]
davterra has quit [Ping timeout: 265 seconds]
queip has joined #bitcoin-wizards
davterra has joined #bitcoin-wizards
Socoro has quit [Ping timeout: 265 seconds]
davterra has quit [Ping timeout: 246 seconds]
queip has quit [Ping timeout: 268 seconds]
queip has joined #bitcoin-wizards
wk057 has joined #bitcoin-wizards
wk057 has quit [Read error: Connection reset by peer]
wk057 has joined #bitcoin-wizards
TheoStorm has quit [Quit: Leaving]
wk057 has quit [Read error: Connection reset by peer]
wk057 has joined #bitcoin-wizards
queip has quit [Ping timeout: 240 seconds]
queip has joined #bitcoin-wizards
TheoStorm has joined #bitcoin-wizards
queip has quit [Ping timeout: 265 seconds]
queip has joined #bitcoin-wizards
dr-orlovsky has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
devrando1 has joined #bitcoin-wizards
wk057 has quit [Read error: Connection reset by peer]
wk057 has joined #bitcoin-wizards
queip has quit [Ping timeout: 245 seconds]
queip has joined #bitcoin-wizards
nijynot has quit [Quit: WeeChat 2.6]
nijynot has joined #bitcoin-wizards
TheoStorm has quit [Remote host closed the connection]
devrando1 has quit [Ping timeout: 250 seconds]
queip_ has joined #bitcoin-wizards
queip has quit [Ping timeout: 276 seconds]
queip_ is now known as queip
lowentropy has quit [Ping timeout: 260 seconds]
lowentropy has joined #bitcoin-wizards
lcb has quit []
queip has quit [Ping timeout: 246 seconds]
queip has joined #bitcoin-wizards
nijynot has quit [Ping timeout: 276 seconds]
Socoro has joined #bitcoin-wizards
queip has quit [Ping timeout: 265 seconds]
riclas has joined #bitcoin-wizards
queip has joined #bitcoin-wizards
elsimio has joined #bitcoin-wizards
queip has quit [Ping timeout: 250 seconds]
queip_ has joined #bitcoin-wizards
queip_ is now known as queip
queip has quit [Ping timeout: 250 seconds]
AaronvanW has quit [Remote host closed the connection]
queip has joined #bitcoin-wizards
queip_ has joined #bitcoin-wizards
queip has quit [Ping timeout: 240 seconds]
queip_ has quit [Ping timeout: 240 seconds]
queip has joined #bitcoin-wizards
queip has quit [Ping timeout: 240 seconds]
queip has joined #bitcoin-wizards
queip has quit [Ping timeout: 245 seconds]
queip has joined #bitcoin-wizards
DeanWeen has quit [Remote host closed the connection]
ghost43_ has joined #bitcoin-wizards
ghost43 has quit [Ping timeout: 260 seconds]
queip has quit [Ping timeout: 246 seconds]
ghost43_ is now known as ghost43
queip has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
tromp has quit [Remote host closed the connection]
queip has quit [Ping timeout: 268 seconds]
AaronvanW has quit [Ping timeout: 268 seconds]
gmaxwell has joined #bitcoin-wizards
<gmaxwell>
Is it just me or does the CHECKTEMPLATEVERIFY proposal totally miss the insight of graftroot? -- that a signature is a lot more flexible than a hash, and except for storage considerations, basically strictly superior?
<gmaxwell>
ISTM that proposal would be much better constructed if it pushed the output hash (with optional masking) onto the stack... where it could then be constrained for equality or validated w/ a signature operator that checksigs stuff on the stack.
queip has joined #bitcoin-wizards
<gmaxwell>
then it could be used either in a stateless taproot sort of way, or in a more flexible graftroot sort of way.
DougieBot5000_ has joined #bitcoin-wizards
jeremyrubin has joined #bitcoin-wizards
DougieBot5000 has quit [Ping timeout: 240 seconds]
queip has quit [Ping timeout: 252 seconds]
<jeremyrubin>
Can you expand on what you mean by the insight of graftroot?
<jeremyrubin>
The key benefit of the hash being used is being able to statically verify all possible spends
<jeremyrubin>
Whereas graftroot seems more relevant for delegating control to a post-hoc selected script
<jeremyrubin>
gmaxwell: ^^
queip has joined #bitcoin-wizards
<jeremyrubin>
An OP which pushes the StandardTemplateHash onto the stack would also not have the constexpr restriction that CHECKTEMPLATEVERIFY is designed to support.
<jeremyrubin>
It would be possible to enable more expansive covenants with such an opcode
<jeremyrubin>
Therefore, in the pursuit of the minimal feature to enable the functionality required and not more, especially not to introduce potentially unsafe scripts, CHECKTEMPLATEVERIFY only verifies a constexpr literal matches the computed value.
<jeremyrubin>
I'd be open to making the check of the hash happen via a sighash flag, that had occured to me, but I figured the SIGHASH flags were best left for things which are signatures
<gmaxwell>
jeremyrubin: with a graftroot style construction you can still statically verify admissable spends, and no additional ones could be added without the interaction of the participants. (depending on what signature is used to verify it, the signature could also be a "disguised hash" -- e.g. if it doesn't commit to P).
<gmaxwell>
What specifically do you mean by "unsafe scripts"?
<gmaxwell>
jeremyrubin: as far as masking flags go, one concern I have had with your opcode is that it's extremely specific for its usecase, e.g. binding all outputs and the input count makes it basically impossible to add additional fees. I know there are anti-doubledipping reasons why particular applications may want to cover all fields, but it's a pretty extreme restriction.
tromp has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
<jeremyrubin>
gmaxwell: on 11:52, We want to be able to do this without requiring interaction of participants at all. We also want to be able to forbid interaction from novating a contract in certain cases (or at least opt-in/opt-out able)
ppartyix has joined #bitcoin-wizards
<jeremyrubin>
11:53 recursive covenants for example
<gmaxwell>
(and, I think actually if you ever allow 2 inputs, I think it immediately opens up a "spend two outputs at once that allow two inputs, converting half the funds into fees" attack. E.g. I create two idencial coins, A and A' which allow two inputs, so they can get a variable fee input, and each one requires an output of B with all its value. But then an attacker makes a txn that spends both at
<gmaxwell>
once, creating only one B output, and sends the rest of the funds to fees)
<jeremyrubin>
11:59 It does allow two inputs, if you specify, which can be used for adding fees
<jeremyrubin>
But the superior way is to use CPFP to add fees
<jeremyrubin>
Which package relaying and my mempool work will ameliorate greatly
<jeremyrubin>
gmaxwell: that is specified in the BIP that that is a concern
<jeremyrubin>
Which is why the default case is single-output
<gmaxwell>
jeremyrubin: who is we? that idea that there is something wrong with a recursive covenant is a bad meme which I don't think is seriously held by anyone, -- it's a misunderstanding of my post introducing the term. The whole point of my post was that it's stupid to _create_ immortal covenants, just as it's stupid to throw your private keys away.
Socoro has quit [Ping timeout: 265 seconds]
<gmaxwell>
jeremyrubin: I think the pattern I described essentially makes the multi-input usage impossible to use safely. If instead it worked by having each usage of CHECKTEMPLATE 'consume' an output so that no other usage of CHECKTEMPLATE could make use of it, then that vulnerablity goes away, and then I think there is no need to constrain input count at all.
queip has quit [Ping timeout: 276 seconds]
queip has joined #bitcoin-wizards
<gmaxwell>
(aside, thanks for renaming the proposal)
tromp has quit [Ping timeout: 276 seconds]
<gmaxwell>
s/consume an/consume its/
<jeremyrubin>
We == people wanting to use this to make non-interactive payments to users?
<jeremyrubin>
So the follow on opcode to introduce to make the reusability concerns go away would be some sort of OP_CHECKINPUT
<jeremyrubin>
so that you're bound to be spent with some other specific output
<jeremyrubin>
Or to add something to check how much total value is being added and reject if out of range
<jeremyrubin>
The checking the fee range one is a bit better as it's more flexible
<gmaxwell>
jeremyrubin: as far as non-interactive goes, graftrooting doesn't necessarily imply interaction. If the signature used doesn't commit to the pubkey, then it can be used as a disguised hash. E.g. I can pick a nums signature and compute the pubkey that makes it valid for a particular message. A third party that doesn't know the nums seed can't distinguish that from a signature. I would have
<gmaxwell>
lobbied heavily to never do taproot and only do graftroot, except an additional signature is space inefficient.
<jeremyrubin>
Hmmm
<jeremyrubin>
Well then isn't there an issue if you do that of not being able to bind multiple values?
<jeremyrubin>
Or are you imaging a graftroot opcode?
<jeremyrubin>
Because OP_IF <h(t1)> OP_CTV OP_ELSE <h(t2)> OP_CTV OP_ENDIF is a pretty desirable script
<gmaxwell>
If you use a nums signature to treat a signature has a hashcheck then you're stuck with a single value. But it has the nice property that a third party observer can't tell that you did that. Only the first and second party can. It has the downside that it's bigger than a hash.
<jeremyrubin>
If you're using a "local" nums, not a global one, you also lose compressability
<gmaxwell>
Of course, in applications where you might revise the outputs (e.g. using a decrementing CSV sequence like a payment channel), the ability to make revised outputs is probably super useful... it just comes at a cost of interaction.
<jeremyrubin>
permits revising, but the defaults have to be spelled out not embedded in the key
<jeremyrubin>
Also permits multiple default branches which is super useful
<jeremyrubin>
Interaction is not realistic for the types of use cases that I designed OP_CTV to support
<jeremyrubin>
E.g., exchanges being able to deposit to thousands of customers during high fee periods
<jeremyrubin>
One bad user can DoS the whole process
<jeremyrubin>
So you can use a NUMS signature, but then you can't add something later right
<gmaxwell>
Right, Nums signature is functionaly the same as a hash however a nums signature is indistinguishable to third parties from people using a real signature.
<jeremyrubin>
that's only true if the parties interact?
<gmaxwell>
No, nums signature doesn't require interaction.
<jeremyrubin>
To communicate the NUMS-ness it does require you to communicate information out-of-band of the chain
<gmaxwell>
And for things like payment pools, interaction is assumed, so real signatures are fine. (I didn't look at your applications yet, so I don't know if you've got payment pools there, perhaps under another name)
<jeremyrubin>
Which I'm counting as an interaction
<jeremyrubin>
I didn't include payment pools as I think they're a bit hard to explain so i focused on more straightforward wins
<gmaxwell>
jeremyrubin: you have to like.. know the exchanges pubkey for any of this to be useful. (in fact you actually have to learn the whole content of the tree of payments ... which can't even be sent in advance)
<jeremyrubin>
Huh?
<jeremyrubin>
What do you mean?
<gmaxwell>
I'm totally fine with leaving that application out of the bip, but I still want it work well. :)
<jeremyrubin>
For CTV or for NUMS-GRAFTROOT
<gmaxwell>
jeremyrubin: I mean if the exchange is going to pay users A, B, C, D .... user D needs to know about that hashtree with A,B,C in it too to know they got paid with CTV. The exchange could tell them the nums 'secret' at the same time.
<jeremyrubin>
Ah correct. The difference is those transactions can be directly broadcast to the mempool/network
<jeremyrubin>
so your assumptions are the same as normal txn relay
<jeremyrubin>
Whereas in order to get this NUMS privacy benefit you have to broadcast it to the user through some new path
<jeremyrubin>
or make it public
<gmaxwell>
Plus they have to interact for the user to provide their own address in the first place. The nums secret is something they only need to learn once for a given counterparty (exchange)
<gmaxwell>
(since the nums value can just be derrived as H(inputs||secret) or the like, no per-payment interaction is needed)
<jeremyrubin>
Wouldn't re-use make it unsafe? or do you imagine tweaking it somehow per-tx
<jeremyrubin>
ok
<jeremyrubin>
I agree there is a benefit to be had in terms of indistinguishability, but I would need to see specific graftroot code and implementation to ensure that the committing to the NUMS signature isn't otherwise leaking information.
<jeremyrubin>
I think also this ends up having to be similar in features to what anyprevout is providing
<jeremyrubin>
because fundamentally it means you aren't signing which TXID
<jeremyrubin>
I think also RE: the NUMS point I like that it is opt-in/out. I just think most people will opt for lower-fees for a well-known NUMS point.
<jeremyrubin>
And if you want to opt-in to better privacy for OP_CTV you can use the musig-alternative script (or a taproot)
<gmaxwell>
It's just strictly more flexible. For the application where there can't be interaction and it has to be set in advance, it doesn't add anything except being indistinguishable from an application where being able to revise is useful. Perhaps the revision isn't all that useful in any case because you could just chain transactions.
<jeremyrubin>
Well it's not strictly more flexible
<gmaxwell>
the downside of chaining to revise is that it's distinguishable and also less efficient.
<jeremyrubin>
OP_CTV is more flexible in allowing multiple alts
<gmaxwell>
jeremyrubin: how so? You can op_if the pubkey to get multiple alternatives in exactly the same way.
<gmaxwell>
nums signature is just a somewhat space inefficienct and potentially denyable hash function.
<jeremyrubin>
I'm assuming graftroot would be implemented like taproot
<jeremyrubin>
I think also the upgrade paths for OP_CTV are desirable.
<jeremyrubin>
As we come up with other things we want to mask in/out we have a straightforward place to put them, whereas I beleive graftroot would be restricted to sighash flags
queip has quit [Ping timeout: 268 seconds]
AaronvanW has quit [Ping timeout: 246 seconds]
queip has joined #bitcoin-wizards
<jeremyrubin>
(also, not to be overly practical in the wizards side of discussion, but CTV is designed to be something that could be relatively easy to get through to the community today, even if made redundant in the future. There's a pretty big benefit IMO for helping solve the problems CTV solves ahead of another wave of adoption)
<gmaxwell>
I don't think opcodes that essentially hard code a specific use case are ones that would be easy to get through... they just turn into technical debt if the usecase is eclipsed or turns out to not be popular.
<jeremyrubin>
I don't think it's fair to say CTV is a hard coded specific use case
<gmaxwell>
and a couple lightning specifc things have essentially been shot down for that reason in the past.
<gmaxwell>
jeremyrubin: no, but I don't think it's clear that it doesn't either. Stuff like making it essentialy impossible to add inputs is a really extreme restriction. (yes you can allow multiple inputs, but as I pointed out-- I think it's really hard if not impossible to do that safely due to double dipping)
<gmaxwell>
There is a natural tension between wanting to provide a generic mechenism that has the most usecases, providing something that is simple to implement and review, and proving something that isn't a heinous footgun that is hard/impossible to use safely.
<jeremyrubin>
The multi-input use cases listed are basically limited to wallet vault infrastructure, where you are implementing stuff in a walled garden. Easy enough to prevent key reuse which obviates that concern.
<gmaxwell>
Stuff like CSV and CLTV managed to thread that needle pretty well.
<jeremyrubin>
Also bear in mind I did originally limit it to the single input use case but there was outcry that people wanted a bit more flexibility and that it should be safe enough with this design to permit multiple
<jeremyrubin>
I don't recall specifically but that may have even been yourself at the time ;)
queip has quit [Ping timeout: 265 seconds]
<gmaxwell>
it's pretty hard to prevent key reuse in general. You essentially need to either avoid any runtime redundancy (creating a single point of failure) or have a consensus system to avoid replay. And still also hope that no one goes and snarfs and address off the blockchain and 'refunds' to it or similar.
<jeremyrubin>
In any case, the multi-input case can be made safer with a chaperone signature for a key known to all participants
queip has joined #bitcoin-wizards
<gmaxwell>
I think it's still effecively limited to single input. Or at least, multi-input is only safe to use under a big pile of assumptions. I don't think there is any fundimental reason why this needs to be the case.
<jeremyrubin>
I'm not clear why graftroot is safer here
<jeremyrubin>
Or why anyprevout is safer eitherr
<jeremyrubin>
Also as mentioned the OP_AMOUNTSPENTRANGE type opcode makes this sort of thing safe too
<gmaxwell>
It isn't. Seperate point. The graftroot comment is strictly about flexiblity (/indistinguisability with the more flexible usage)
<jeremyrubin>
Would you like a simultaneous BIP which checks the amount spent is not more than a bound? I think it changes some caching assumptions.
<gmaxwell>
Making multiple inputs safe would need a bit of 'anti-duplication' logic, so that each CTV 'consumes' some outputs so that a seperate CTV couldn't also be satisfied by the same outputs.
<gmaxwell>
I dont like ranging fees as a fix, I think thats kludgy.
<jeremyrubin>
Ok, so you prefer an OP_CHECKINPUT
<gmaxwell>
(and doesn't address the root problem)
<jeremyrubin>
No it doesn't
<jeremyrubin>
because that could be spent under you
<jeremyrubin>
Actually maybe it does?
<jeremyrubin>
Spend to <H> OP_CTV with 0 sats to create input A
<jeremyrubin>
Ah nvm
<gmaxwell>
Yes because thats actually what the application is doing, the fact that it just matches all the outputs is an effort to simplify it... but the real application is along the lines of "this input coin get converted into these outputs".
<jeremyrubin>
Also btw there are underfunded OP_CTV multisig cases that *are safe* to use I think, e.g. kickstarters
<gmaxwell>
which inherently means that two different CTV's ought not be able to double dip by using the same outputs for their satisfaction. In the case where there is only one input, there is no chance of double dipping.
<jeremyrubin>
It would be possible to add the rule that OP_CTV is only defined if it's in the first output, otherwise invalid
<gmaxwell>
jeremyrubin: if the miner can add them up to an overfunded amount, e.g. because non-synchronized users collectively overpay, then they can steal the excess as fees.
<jeremyrubin>
*input
<jeremyrubin>
Would you like that? Then you can't combine OP_CTVs but you can use one with some other coins?
<gmaxwell>
lemme go to lunch and think a bit.
* gmaxwell
bbl lunch
<jeremyrubin>
happy thanksgiving lunch
<gmaxwell>
(I think mostly what I want is something likean OP_CTV that takes a bitmask from the witness about which outputs it's NOT applying to, and the outputs outputs it is applying to are 'spent' and can't be used by any other CTV's bitmask, but I should give that more thought... (I say 'not applying to' so the case of 'all' is a OP_0))
elsimio has quit []
queip has quit [Ping timeout: 250 seconds]
queip has joined #bitcoin-wizards
jeremyrubin has quit [Ping timeout: 265 seconds]
queip has quit [Ping timeout: 250 seconds]
queip has joined #bitcoin-wizards
jeremyrubin has joined #bitcoin-wizards
ppartyix has quit [Ping timeout: 265 seconds]
jonatack__ has joined #bitcoin-wizards
jonatack_ has quit [Ping timeout: 245 seconds]
queip has quit [Ping timeout: 240 seconds]
queip has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
jonatack__ has quit [Quit: jonatack__]
jonatack has joined #bitcoin-wizards
devrando1 has joined #bitcoin-wizards
jonatack has quit [Client Quit]
jonatack has joined #bitcoin-wizards
queip_ has joined #bitcoin-wizards
queip has quit [Ping timeout: 276 seconds]
queip_ is now known as queip
jeremyrubin has quit [Ping timeout: 240 seconds]
mcorpgc has joined #bitcoin-wizards
queip has quit [Ping timeout: 276 seconds]
queip has joined #bitcoin-wizards
jeremyrubin has joined #bitcoin-wizards
<jeremyrubin>
The witness so as to prevent malleation?
<jeremyrubin>
(I have kinda spotty reception/lots of thanksgiving stuff so forgive if I'm in and out a bit)
jonatack_ has joined #bitcoin-wizards
<gmaxwell>
the witness, so that which outputs will be the matched ones need not be set in advance, but can be set correctly by the txn author.
jonatack has quit [Ping timeout: 252 seconds]
<gmaxwell>
In effect, it's just a hint to help the verifier find the matching input(s) rather than having to do an exponential time search.
tromp has joined #bitcoin-wizards
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
jeremyrubin has quit [Ping timeout: 252 seconds]
dr-orlovsky has joined #bitcoin-wizards
slivera has joined #bitcoin-wizards
jeremyrubin has joined #bitcoin-wizards
<jeremyrubin>
So one issue there is output malleation. An adversarial miner can re-arrange the outputs, malleating their indexes
<jeremyrubin>
Ah here's a fun rule
<jeremyrubin>
Make OP_CTV commit to the input index!
<jeremyrubin>
By committing to the input index you make some OP_CTVs unspendable together. But you make the reuse safe because the hash commits to the index
<gmaxwell>
hm? two of the same CTV both commiting to 0 would reuse the outputs...
<gmaxwell>
Is miners malleating it particularly a problem? Where it is, you could include required checksig with a key known to all participants.
<jeremyrubin>
gmaxwell: no they wouldn't
<jeremyrubin>
If they both commit to 0 they can't be in the same transaction as they must occupy prevout 0 to be valid
<gmaxwell>
oh INPUT INDEX.
<jeremyrubin>
Yes (one day, we really ought to give unspent outputs, inputs, and outputs some more semantic names)
<gmaxwell>
that is ... kinda weird. athough future softforks that have reason to bind to particular indexes is one of the reasons I argued against BIP69! :)
<jeremyrubin>
I think is addresses your issue with reuse-safety
<jeremyrubin>
Like obviously you could rebind it to another index
<jeremyrubin>
but you can also burn your coins
<gmaxwell>
it would though I think it's almost functionally equivilent to saying there can only be one input using CTV in the trasnsaction.
<jeremyrubin>
No, not at all
<gmaxwell>
(I mean, what would the case ever be for specifying another index, particular if that is the only anti-reuse mechenism?)
<jeremyrubin>
Kickstarter commitments maybe?
<jeremyrubin>
E.g., I CTV to create coins C before time T at index 0
<jeremyrubin>
you can then CTV to create coins C before time T and index 1
<jeremyrubin>
etc.
<jeremyrubin>
Each CTV is under-funded
queip has quit [Ping timeout: 240 seconds]
<gmaxwell>
and indeed, that also shows a case where 'reuse of an output' is desirable.
<gmaxwell>
But it requires we coordinate, and if we mess up I think we burn coins?
<gmaxwell>
(like if we both pick 0.
<gmaxwell>
)
<jeremyrubin>
Nope
<jeremyrubin>
hence the "before time T"
<jeremyrubin>
else return to sender
queip has joined #bitcoin-wizards
<gmaxwell>
still the coordination is ugly, and I think not essential.
<jeremyrubin>
It does require coordination to not mess up
<jeremyrubin>
It's true that in the under-funded case it works without input index commitments
<jeremyrubin>
Because the CTVs are under-funded
<jeremyrubin>
you actually *want* them to be double spent
<gmaxwell>
I mean that the coordination is purely a side effect of this anti-reuse mechenism, not something fundimental to the application.
<jeremyrubin>
Until you hit saturation
<jeremyrubin>
Correct.
<jeremyrubin>
I guess you can also bind a range of values using taproot
<jeremyrubin>
but that is clunky
<gmaxwell>
You actually want that output to be a SUM of input values, not actually double spent. like if someone adds in a #3 with enough value to fully fund it, you don't want a #4 that adds a bit more to all go to fee.
<gmaxwell>
I think if you're assuming the participants can interact to not clash numbers, thats really close to just saying they can coinjoin to create it and dispense with the CTV.
<jeremyrubin>
The difference being that the commits are on-chain and you know the bounded time before the 'bid' can be withdrawn
<jeremyrubin>
Anyways... that's an aside from the point which is that strictly speaking the commitment to input index does slightly solve the reuse issue
<jeremyrubin>
And it is strictly speaking, possible for multiple indexes to have multiple covenants
<jeremyrubin>
we could also support an ANYINDEX value
<jeremyrubin>
if you don't care
<jeremyrubin>
Also RE coordination, we are already committing to the # of inputs
<gmaxwell>
'commits are on-chain' -- still leaves a race condition. And as far as withdrawn, maybe not so optimal esp considering that overpayment turns to fees... pretty good incentive to just ignore the withdrawl transaction. :)
<gmaxwell>
jeremyrubin: YES and that is what I've been complaining about from the start: binding additional inputs prevents adding fees directly.
<jeremyrubin>
I think that CPFP is a more robust mechanism
<jeremyrubin>
So I don't think that should be a huge concern
<gmaxwell>
jeremyrubin: as your proposal is right now, the only sensible input count is 1 (because otherwise a copycat input can be double spent), which is also the same as commiting to the index and then everyone commiting a 0.
<jeremyrubin>
Well it's actually not the same
<jeremyrubin>
There are some programmatic use cases where you'd generate templates at different indexes
<jeremyrubin>
Especially around the vault stuff where it's under your control and you want to select from some set of templates
<gmaxwell>
jeremyrubin: CPFP has relay complications, among other limitations.
<gmaxwell>
jeremyrubin: what addresses other people send to is never under your control.
<jeremyrubin>
Not sure what that has to do with it
<jeremyrubin>
CPFP is being improved a lot afaik? Suhas has been working on packagerelay
<jeremyrubin>
And we have the new 1-hop cutout for the mempool
<jeremyrubin>
which fixes some issues related to pinning
<jeremyrubin>
With adding an input to add fee you have to do two transactions; one to set up the correct amount of fee, and then one to include it in the txn.
<gmaxwell>
The CPFP improvements are just taking it from a hack that only works in some cases to a hack that works in more cases.
<gmaxwell>
jeremyrubin: you don't, if you didn't have all these limitations.
<jeremyrubin>
And also it wouldn't work for half the use cases
<gmaxwell>
If the CTV took a witness value that specifies the covered inputs, then additional fee and change could just be provided.
<jeremyrubin>
Because we want to avoid malleating txids
<jeremyrubin>
Malleating the txid is a non option
<gmaxwell>
Why does malleating the txid matter?
<jeremyrubin>
Because you want to use CTV to batch generate channels
<jeremyrubin>
and allow users to blindly request payouts into channels
<jeremyrubin>
You also want to be able to open non-interactive channels, where the counterparty doesn't have a key online
<jeremyrubin>
CTV lets you do all these things, which if you couldn't predict the txid would be not doable
<gmaxwell>
Then effectively the CTV isn't a "template" constrant at all, if you do that, then essneitally it allows the output to only be spent by a _specific_ transaction.
<jeremyrubin>
It is a template, the only template varaible being the specific inputs.
<gmaxwell>
If the txid can't change the "template" is the entire functional part of the transaction.
<gmaxwell>
changing intputs changes the txid.
<gmaxwell>
inputs*
<jeremyrubin>
If you care to suggest a better name please do.
<jeremyrubin>
Also, the idea is that future versions can permit more expansive templates
<jeremyrubin>
By permitting to read non-constexpr templates
<jeremyrubin>
or permitting other variants
<jeremyrubin>
The current BIP just proposes one (which is called StandardTemplate)
<gmaxwell>
as the bip is written it doesn't achieve the goal you've stated here: the txid is malleable (substitute one input for a different one).
<jeremyrubin>
That's incorrect. As noted, if you only use one input that's the only way to acheive non malleability
<jeremyrubin>
It's in the BIP
<gmaxwell>
If it's restricted enough so that this isn't possible, then it only commits to a specific chain of transactions. Which, I can imagine would be useful for some applications, but it is very limited.
<jeremyrubin>
It is insanely useful
<jeremyrubin>
And really not that limited
<gmaxwell>
jeremyrubin: But that isn't so-- e.g. even if there is one input, I could substitue that one input for another equivilent input, and change the txid.
<jeremyrubin>
Yes
<jeremyrubin>
Anyone can pay to any output they like
<jeremyrubin>
Someone can set up a coinbase mirror and pay everyone from coinbase who gets paid just for kindness
<jeremyrubin>
CTV just ensures that you can prove that you will get some specific fund sent your way
<jeremyrubin>
It doesn't prevent people from paying you in the future
<gmaxwell>
I think that the flexibility is just a sham here: as is, this proposal is only useful with a single input, and a fixed set of outputs... and hopefully your fixed set of outputs includes at least one that anyone who'd like to adjust fees can CPFP.
<gmaxwell>
I agree that its useful, but it could be radically simplified to just mandating a single input, and commiting to essentially the whole tx would be equally useful.
<jeremyrubin>
That's what I originally proposed :shrug:
<jeremyrubin>
I think allowing other use cases, with a modicum of flexibility isn't bad
<jeremyrubin>
In fact I have other use cases already which depend on this, around wallet vaults.
<jeremyrubin>
Further, it helps "future proof" the design so that when templates can be stack-computed you can regain tons of flexibility
<jeremyrubin>
Including things like "any number of inputs"
<gmaxwell>
I'd like it to support other use cases, but I think as it doesn't really, the added flexibility without any other safegards is mostly just a footgun. Like you think you can allow two inputs, but really they just lets your coins get burned by a reuse.
rusty has joined #bitcoin-wizards
<gmaxwell>
The requirement that the txid be non-malleable essentially kills almost any flexibility.
<jeremyrubin>
The txid being non-malleable allows some of the most desirable use cases.
<gmaxwell>
I am not disputing the desirability of that... just pointing out that it kills flexibility.
<jeremyrubin>
I also don't really think it's worth bending over backwards for re-use safety when designing things like... internal custody services
<jeremyrubin>
If you're engineering a custom cold/hot wallet interface, you can avoid reuse in these scenarios easily
<gmaxwell>
Aren't those applications also killed by the ability to cut-through the CTV spend? like if the txn can be spent by CTV _or_ N of N, then that isn't non-malleable.
<jeremyrubin>
Nope
<jeremyrubin>
Because you can do that in the witness
<jeremyrubin>
Ah let me revise
<jeremyrubin>
Yes. if you decide to do a different transaction
<gmaxwell>
Avoiding reuse in a production system is extremely hard. You essentially need a consensus system to do it. You need to either not have backups or secondary backup masters, or have very strong guarentees that they can't come up with old state.
<jeremyrubin>
But then it's incumbent on you to track your channel states and multisig out to something correct
<gmaxwell>
I'm aware of at least one instance where a big bitcoin exchange managed to create a mess by giving out addresses they already gave to other users again...
<gmaxwell>
so I don't buy that it's easy to avoid reuse.
<jeremyrubin>
RE: production reuse, it's actually not difficult in this case because what you can do is tweak your keys basedon the inputs your planning to use
<jeremyrubin>
This gives you provable anti-reuse.
<gmaxwell>
jeremyrubin: I see so in the NofN case you just won't sign that other way unless you are guarenteed to get to recreate your chain of txn there. OK that makes sense to me.
<jeremyrubin>
Well you *could*
<jeremyrubin>
as long as they are equivalent to you
<gmaxwell>
right but if you want to avoid the malleation problems.
<jeremyrubin>
Yes
<gmaxwell>
Gotcha.
<jeremyrubin>
It doesn't force you to have to malleate
<jeremyrubin>
Which is good in taproot
<jeremyrubin>
Because you can hide if it is CTV or Taproot
<jeremyrubin>
Also RE key reuse, we're not talking about keys to users
<jeremyrubin>
We're just talking about writing an API that makes CTV trees and either tweaks leaf nodes with the hash of the inputs or an OP_RETURN random value or something
<gmaxwell>
sorry if you feel like I'm dicking you around on this. I am excited about the prospects. I would really prefer a _general mechenism_ but I guess what I'm learning by talking to you is that we don't actually know what a general mechenism would look like. I thought it could be fully flexible if only it had explicit anti-reuse (or controlled reuse) but since you've pointed out that malleability
<gmaxwell>
is a concern, -- well basically if you care about malleability than I think nothing but a "this coin can be spend only by THIS single input transaction" can work.
<jeremyrubin>
Yeah it basically needs to be very locked down for that reason
<jeremyrubin>
I misled you when I presented COSHV originally
<jeremyrubin>
Was my error
<jeremyrubin>
it was just "hash these outputs"
<jeremyrubin>
Then I realized I had forgotten malleability
<jeremyrubin>
and had to add... a lot of other stuff
<jeremyrubin>
I think with the current CTV mechanism, loosening the restriction on constexpr ness + OP_CAT would add a *lot* of this flexibility back in
<jeremyrubin>
(OP_CAT or OP_SUBSTR & friends)
<gmaxwell>
For the application I care about (payment pools), the totally locked down case is fine. (though I think being able to graftroot substitute would be somewhat better) -- because in that application the CTV (check transaction verify!) is really only just guarentting a backup backout state.
<jeremyrubin>
So it can be made fully graftroot compatible in the future if it's in a taproot leafd
<gmaxwell>
it's unclear to me how viable programmatically constructing templates really is... I guess I'd need to see concrete examples to be confident that this worked, and wouldn't constantly get messed up by the absense of opcodes or where performing some check is really absurdly expensive.
<jeremyrubin>
You also can emulate graftroot by permitting a signed hash?
queip has quit [Ping timeout: 250 seconds]
<jeremyrubin>
You can look at my demo-quality code for sendmanycompacted
<jeremyrubin>
You essentially build up the tree bottom up
<gmaxwell>
Well I still think I like an operation that PUSHs the CTV hash... which then you'd have the freedom of comparing for equality OR checking with a checksigfromstack.
<jeremyrubin>
I also recommend watching my scaling bitcoin talk
queip has joined #bitcoin-wizards
<gmaxwell>
Other than some 'constness' goal, I don't see any advantage to the VERIFY construction. (and I don't think the constness is actually something anyone needs: yes, it means some footgun uses aren't possible, but you can always burn your coins)
<jeremyrubin>
It's there to prevent any sort of "non enumerable"covenants
<gmaxwell>
Who cares?
<gmaxwell>
I can post my private keys online, or throw my coins away.
<jeremyrubin>
Well, everyone I've talked to about this beleives, you?
<jeremyrubin>
So maybe you should make your views on some of these issues a bit more well known
<jeremyrubin>
:)
<jeremyrubin>
I'd be happy to discard the constness rule if people check it over and determine that permitting these sorts of things are fully safe
<gmaxwell>
This is some weird cult thing and I'm confused by it. I think I said earlier: I think it would be idiotic to subject your own coins to a perpetual encumberance -- effectively you're burning them if you do that. And I think it's funny to imagine what kind of silly ways people could come up with to do that... but anyone can burn coins at any time for any reason they want.
<gmaxwell>
I'm not sure how to be any more clear on that.
<jeremyrubin>
Maybe write one the mailing list that you think the constexpr rule can be safely dropped
<jeremyrubin>
I would love that as it also solves Russel's concern about parsing
<gmaxwell>
I'm not even completely sure that there isn't a way to get a perpetual encumberance today (or that one isn't created by tapscript)... we just don't know how currently. I've shown a couple ways in the past that the original bitcoin rules allowed for it... and how a couple rules (like a checksigfromstack) create one. :)
<gmaxwell>
OK. well I'm not on the list but I could do that.
<jeremyrubin>
Why not? Too much noise these days?
<gmaxwell>
yeah, it's very high SNR, and interacting with some hostile people that show up there (like voskuil) just makes my life suck and I'd rather not have anything to do with bitcoin tech than deal with more of that crap.
<gmaxwell>
er very LOW SNR
<gmaxwell>
HIGH NSR. :P
<gmaxwell>
same reason I'm mostly not in this channel anymore. (just came in here because I knew I could get your attention here, or at least someone else who might care)
<jeremyrubin>
Ah yeah. Because of the holidays I only found out you commented here because of amiti pinging me :)
<jeremyrubin>
But it's good that others can look through this discussion
<jeremyrubin>
I think the main motivating factor for the constexpr rule is that it lessens the review burden (opcode introduces *provably*) fewer features, so we don't worry about what it may enable or not. But if we're on-board for "if you want to waste your coins, do it" I agree it can be removed.
<gmaxwell>
anyways. I think the constexpr can go, and that it could basically be an opcode that sticks the hash of the whole txn except input-txids, and only one input.. onto the stack. And then you're free to check that hash however you want (equality, or a future checksigfromstack strike me as the most useful). ... and future versions that are more relaxed-- if we can manage to come up with an actually
<gmaxwell>
general mechenism which adds more applications and isn't an automatic footgun-- could just be different opcodes.
<gmaxwell>
yes but the constexpr thing also implies a very "unscriptlike" evaluation constraint, that makes pretty strong assumptions about how the verifier is programmed. So it's not free, I think.
<jeremyrubin>
Only one input breaks some vault use cases so I'd prefer to keep it.
<gmaxwell>
and it comes at the cost of breaking the ability to use the opcode with signatures for a grafty construction. Maybe that isn't that big a loss, because you could key-path spend to cut past to a different set of outputs. I guess I should contemplate that some more before being convinced that the loss of being able to sign for it matters.
<gmaxwell>
I'm really dubious that those are safe. Are they described in the BIP?
<jeremyrubin>
I don't care too much about the VERIFY vs PUSH semantics.. can you come up with a concrete example of why it would be worth the extra opcode to check equals? The checksigfromstack works with either verify or push
<gmaxwell>
The verify requires you put an extra 32-bytes in the witness. Otherwise I believe the only other difference is that you can't construct a "IF NOT CTV", which ... it's not an obviously useful construct to me but also there is no reason why it shouldn't be possible to create. For things like time (e.g. CLTV) constraints it's important for consensus reason that the match not be invertable, which
<gmaxwell>
is why they're forced through the one-way latching nlocktime.
<gmaxwell>
Because the CTV constraints the whole transaction a NOT-CTV isn't too useful (e.g. bypass by just using a different nlocktime), if CTV constrained less it might be useful.
<jeremyrubin>
huh? Why does verify require extra data in witness
<jeremyrubin>
scriptPubKey: <32 bytes> OP_CTV
<jeremyrubin>
scriptSig:
<jeremyrubin>
witness stack:
<gmaxwell>
like if I want to checksig from stack, my witness would push the CTV hash and the signature, and the witnessprogram would verify the signature and run CTV on the hash. But a PushTV the witness would just be the signature.
<gmaxwell>
and the witness program would push the hash then validate the signature on it.
<gmaxwell>
(also we prefer 'validate' like checksigs, or at least ones with "designated failure inputs", due to batch validation-- but that doesn't apply for CTV)
<jeremyrubin>
hm. let me think on that one. If you have CheckSigFromStack you might do some other things differently too
<jeremyrubin>
I also generally think we could make the precomputedtxdata always accessible by special opcodes in a new tapscript version
<gmaxwell>
I really hope it gets CheckSigFromStack... it's surprisingly useful and also absurdly simple.
<jeremyrubin>
I don't think anyone is proposing it presently?
<gmaxwell>
it was at one point just part of an early tapscript proposal but got stripped because it can be easily added later with a OP_SUCCESS
<gmaxwell>
the whole taproot thing seems to have been a circus of removing functionality to get it done fast, then dropping it on the floor because half the interesting stuff got taken out. :P
<gmaxwell>
(as was reenabling size limited versions of many of the disabled opcodes, like elements)
Zenton has quit [Ping timeout: 265 seconds]
<jeremyrubin>
:shrug:
<jeremyrubin>
bitcoin is hard
<jeremyrubin>
maybe someone will pick it up
<gmaxwell>
Yep. Oh I'm sure it'll be picked up, I think people are just waiting for taproot to make more progress.
<gmaxwell>
in particular it should copy the taproot signature type ... and stuff like pubkey styles have been changing soooo.