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
Alex7 has quit []
justanotheruser has quit [Ping timeout: 246 seconds]
ogelbukh has joined #bitcoin-wizards
michaelfolkson has quit [Quit: Sleep mode]
AaronvanW has quit []
BlueMatt has quit [Ping timeout: 252 seconds]
BlueMatt has joined #bitcoin-wizards
davterra has quit [Quit: Leaving]
michaelsdunn1 has joined #bitcoin-wizards
davterra has joined #bitcoin-wizards
michaelsdunn1 has quit [Remote host closed the connection]
michaelsdunn1 has joined #bitcoin-wizards
michaelsdunn1 has quit [Remote host closed the connection]
michaelsdunn1 has joined #bitcoin-wizards
Belkaar has quit [Ping timeout: 245 seconds]
Belkaar has joined #bitcoin-wizards
Belkaar has quit [Changing host]
Belkaar has joined #bitcoin-wizards
ogelbukh has quit []
michaelsdunn1 has quit [Remote host closed the connection]
michaelsdunn1 has joined #bitcoin-wizards
Limnoria1 has joined #bitcoin-wizards
DeanWeen has joined #bitcoin-wizards
michaelsdunn1 has quit [Remote host closed the connection]
davterra has quit [Ping timeout: 248 seconds]
ccdle12 has quit [Remote host closed the connection]
instagibbs_ has quit [Ping timeout: 258 seconds]
davterra has joined #bitcoin-wizards
davterra has quit [Remote host closed the connection]
davterra has joined #bitcoin-wizards
ccdle12 has joined #bitcoin-wizards
rh0nj has quit [Remote host closed the connection]
rh0nj has joined #bitcoin-wizards
ccdle12 has quit [Ping timeout: 246 seconds]
ccdle12 has joined #bitcoin-wizards
ccdle12 has quit [Remote host closed the connection]
spinza has quit [Quit: Coyote finally caught up with me...]
justanotheruser has joined #bitcoin-wizards
satwo has joined #bitcoin-wizards
pinheadmz has quit [Quit: pinheadmz]
justanotheruser has quit [Ping timeout: 246 seconds]
spinza has joined #bitcoin-wizards
ccdle12 has joined #bitcoin-wizards
justanotheruser has joined #bitcoin-wizards
ccdle12 has quit [Ping timeout: 268 seconds]
tromp has joined #bitcoin-wizards
tromp has quit [Ping timeout: 258 seconds]
TheoStorm has joined #bitcoin-wizards
Limnoria1 has quit []
zigapeda1 has joined #bitcoin-wizards
ccdle12 has joined #bitcoin-wizards
ccdle12 has quit [Ping timeout: 268 seconds]
OhGodAGirl_ has joined #bitcoin-wizards
morcos has quit [Ping timeout: 256 seconds]
morcos has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
vtnerd has quit [Ping timeout: 258 seconds]
ccdle12 has joined #bitcoin-wizards
ccdle12 has quit [Ping timeout: 248 seconds]
ccdle12 has joined #bitcoin-wizards
DeanWeen has quit [Remote host closed the connection]
DeanWeen has joined #bitcoin-wizards
enemabandit has joined #bitcoin-wizards
Isthmus has quit [Read error: Connection reset by peer]
Isthmus has joined #bitcoin-wizards
dongcarl has quit [Ping timeout: 276 seconds]
misalias has quit [Ping timeout: 252 seconds]
rodolfo912__ has quit [Ping timeout: 276 seconds]
junderw has quit [Ping timeout: 276 seconds]
vfP56jSe has quit [Ping timeout: 252 seconds]
gleb has quit [Ping timeout: 276 seconds]
Isthmus has quit [Ping timeout: 244 seconds]
vfP56jSe has joined #bitcoin-wizards
gleb has joined #bitcoin-wizards
rodolfo912 has joined #bitcoin-wizards
junderw has joined #bitcoin-wizards
misalias has joined #bitcoin-wizards
Isthmus has joined #bitcoin-wizards
dongcarl has joined #bitcoin-wizards
DeanWeen has quit [Remote host closed the connection]
TheoStorm has quit [Quit: Leaving]
vfP56jSe has quit [Ping timeout: 252 seconds]
vfP56jSe has joined #bitcoin-wizards
sarang has quit [Ping timeout: 252 seconds]
sarang has joined #bitcoin-wizards
Jackielove4u has quit [Ping timeout: 252 seconds]
gleb has quit [Ping timeout: 252 seconds]
misalias has quit [Ping timeout: 252 seconds]
gleb has joined #bitcoin-wizards
misalias has joined #bitcoin-wizards
cannedprimates_ has quit [Ping timeout: 252 seconds]
Jackielove4u has joined #bitcoin-wizards
a5m0 has quit [Ping timeout: 252 seconds]
runeks has quit [Ping timeout: 252 seconds]
cannedprimates_ has joined #bitcoin-wizards
a5m0 has joined #bitcoin-wizards
runeks has joined #bitcoin-wizards
ddustin has joined #bitcoin-wizards
ddustin has quit [Read error: Connection reset by peer]
ddustin has joined #bitcoin-wizards
ddustin has quit [Read error: Connection reset by peer]
ddustin has joined #bitcoin-wizards
tromp has quit [Remote host closed the connection]
Zenton has joined #bitcoin-wizards
ddustin has quit [Remote host closed the connection]
ddustin has joined #bitcoin-wizards
ccdle12 has quit [Remote host closed the connection]
ccdle12 has joined #bitcoin-wizards
ddustin has quit [Ping timeout: 250 seconds]
tromp has joined #bitcoin-wizards
justanotheruser has quit [Ping timeout: 272 seconds]
zigapeda1 has quit []
michaelfolkson has joined #bitcoin-wizards
Perceptes has joined #bitcoin-wizards
ddustin has joined #bitcoin-wizards
justanotheruser has joined #bitcoin-wizards
ddustin has quit [Ping timeout: 258 seconds]
ddustin has joined #bitcoin-wizards
ddustin has quit [Ping timeout: 245 seconds]
DeanGuss has joined #bitcoin-wizards
setpill has joined #bitcoin-wizards
satwo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ddustin has joined #bitcoin-wizards
ddustin has quit [Ping timeout: 272 seconds]
spinza has quit [Quit: Coyote finally caught up with me...]
spinza has joined #bitcoin-wizards
ddustin has joined #bitcoin-wizards
ddustin has quit [Ping timeout: 268 seconds]
michaelfolkson has quit [Quit: Sleep mode]
michaelfolkson has joined #bitcoin-wizards
michaelfolkson has quit [Client Quit]
ccdle12 has quit [Remote host closed the connection]
michaelfolkson has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
Chris_Stewart_5 has joined #bitcoin-wizards
ccdle12 has joined #bitcoin-wizards
ddustin has joined #bitcoin-wizards
brianhoffman has joined #bitcoin-wizards
ddustin has quit [Ping timeout: 245 seconds]
ccdle12 has quit [Remote host closed the connection]
Madars has quit [Ping timeout: 245 seconds]
michaelfolkson has quit [Quit: Sleep mode]
Madars has joined #bitcoin-wizards
michaelfolkson has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 245 seconds]
Perceptes has quit []
ddustin has joined #bitcoin-wizards
DeanGuss has quit [Remote host closed the connection]
<jb55>
it's like saying "how to factor numbers using a black hole computer". it's like yeah sure if we had one of those. people are struggling to build what, 100 noisy qubit quantum computers?
<nsh>
a lot of less optimal qubits is probably more achievable than a few more optimal ones
<nsh>
just because the gap between current fabrication tech and what's required is more tractable
<nsh>
and it's not a design proposal but an academic exercise :)
ccdle12 has quit [Remote host closed the connection]
ccdle12 has joined #bitcoin-wizards
pinheadmz has joined #bitcoin-wizards
michaelfolkson has quit [Quit: Sleep mode]
<tromp>
is it safe to sign same message with same public key but with many different nonces in Schnorr (with nonce commitment part of hash challenge as usual) ?
<tromp>
safe in sense of not being able to make another signature with yet another nonce
<andytoshi>
yes, if all the nonces are independently uniformly random
<tromp>
what if nonces are 1,2,3... ?
<tromp>
oh, i see that doesn't work:(
<tromp>
you can just solve for x
<tromp>
thx, andytoshi
ccdle12 has quit [Remote host closed the connection]
setpill has quit [Quit: o/]
MononcQc1 has quit []
spinza has quit [Quit: Coyote finally caught up with me...]
Chris_Stewart_5 has quit [Ping timeout: 248 seconds]
rjected has quit [Quit: WeeChat 2.4]
Kabaka has quit []
Toflar has joined #bitcoin-wizards
schmidty__ has joined #bitcoin-wizards
schmidty has quit []
schmidty__ has quit [Client Quit]
schmidty has joined #bitcoin-wizards
Chris_Stewart_5 has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 246 seconds]
sfhi has quit [Read error: Connection reset by peer]
DeanGuss has quit [Remote host closed the connection]
DeanGuss has joined #bitcoin-wizards
sfhi has joined #bitcoin-wizards
satwo has joined #bitcoin-wizards
Chris_Stewart_5 has joined #bitcoin-wizards
DeanGuss has quit [Ping timeout: 256 seconds]
sfhi has quit [Remote host closed the connection]
StopAndDecrypt has joined #bitcoin-wizards
Zenton has joined #bitcoin-wizards
michaelfolkson has joined #bitcoin-wizards
michaelfolkson has quit [Ping timeout: 250 seconds]
rh0nj has quit [Remote host closed the connection]
rh0nj has joined #bitcoin-wizards
satwo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
pinheadmz has quit [Quit: pinheadmz]
satwo has joined #bitcoin-wizards
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
satwo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
CryptoDavid has joined #bitcoin-wizards
Toflar has quit []
drybjed1 has joined #bitcoin-wizards
pinheadmz has joined #bitcoin-wizards
mryandao_ has joined #bitcoin-wizards
mryandao has quit [Ping timeout: 256 seconds]
<jeremyrubin>
sipa: I figured out maybe how to do templating with the Annex (or just other witstack data) as a soft fork.
<jeremyrubin>
It's pretty clever (if I do say so myself), so first class support might be better but this is tolerable
<jeremyrubin>
essentially, you make your taproot script as follows: Taproot([keys], zip([Template Scripts], [Concrete Scripts])
<jeremyrubin>
For old taproot versions you just see OP_SUCCESS on the first instruction of the Template Script.
<jeremyrubin>
but for versions which make OP_SUCCESS -> OP_TEMPLATED you first run the template script, then you verify that the corresponding Concrete Script was in fact the right branch of the script.
<jeremyrubin>
Then, you run the concrete script
<jeremyrubin>
It's basically a P2SH-ish construct
<jeremyrubin>
The downside is that it doesn't help much for basic OP_COSHV because an extra righthand branch is about 32 bytes anyways. But if you had a script that had other template data in it it would be useful to do this
<jeremyrubin>
If you allow the right hand branch (the concrete) to be a Merkle Tree itself, then you can get some more efficiency maybe
<jeremyrubin>
but there's probably an equivalent compilation at the base-level tree
<jeremyrubin>
But if you wanted to do something like OP_CHECKSPECIFICOUTPUT, and then you had like 4 or 5 outputs listed, this would be a win
AaronvanW has quit [Ping timeout: 244 seconds]
AaronvanW has joined #bitcoin-wizards
<jeremyrubin>
e.g., you would have: Taproot([keys], [0, 1,4, 3 (n args), OP_CHECK_N_SPECIFIC_OUTPUTS_TEMPLATE], [<h(outputs[0,1,4])>, 0, 1, 4, 3, OP_CHECK_N_SPECIFIC_OUTPUTS_COCNRETE])
<jeremyrubin>
gmaxwell: ^^^
Aaronvan_ has joined #bitcoin-wizards
<gmaxwell>
one would want to be careful to make sure the other branch couldn't be interperted as a trivially true script!
<jeremyrubin>
actually that's fine
<jeremyrubin>
because it's a soft fork
<jeremyrubin>
you would also add the rule that RHS must be template?
<jeremyrubin>
But maybe safer to add an explicit IS_CONCRETE tage
<gmaxwell>
that would be okay if the template has a specific constant hash.
AaronvanW has quit [Ping timeout: 248 seconds]
<jeremyrubin>
Ah!
<gmaxwell>
yes, but that gets you 'partial witness program concealment', but not an 'implicit partial witness program'
<jeremyrubin>
Even better; just have a tag so such branches can't be expanded
<jeremyrubin>
e.g. TaggedHash(IsConcrete)
<jeremyrubin>
Then they can't be looked up at all via a normal tapscript path
<gmaxwell>
there you go.
<gmaxwell>
oh it does get you implicit, but only after one additional level.
<jeremyrubin>
I mean it kinda sucks that it's a savings of 32 + n rather than a pure savings of n bytes for OP_COSHV to be made one byte
<jeremyrubin>
But I guess that's OK as it gets you bigger wins if we add more templatable stuff
<gmaxwell>
So let me repeat the idea. You can add softforks that conceal part of the witness program, including switching the hashing function mid-tree, by making a OP_SUCCESS branch whos sibling is an unexpandable (differently tagged) commitment to your new stuff.
<jeremyrubin>
yep
<gmaxwell>
I agree.
<gmaxwell>
thats not even particularly inelegant.
<jeremyrubin>
and then you run a p2sh-like eval on the program after templating it
<jeremyrubin>
And there's lots of good data to template; e.g. inputs, outputs, fees, etc
<jeremyrubin>
so I could see great use cases which take advantage of this
<jeremyrubin>
just not the one that I wanted it to work for!
<jeremyrubin>
Also instead of op_success, can just do a different leaf version
<jeremyrubin>
recover a byte that way
<gmaxwell>
(your initial explination confused me a little because you talked both about the extension mechensim and your application of it at the same time. :P )
<jeremyrubin>
My bad, just wanted it to be concrete
<gmaxwell>
One of the challenges with covenanty thing is figuring out mechenisms which are generic enough to be useful, but specific enough to not be unattracively expensive to use. E.g. roconnor likes the signature equivilence covenant trick, where you construct the masked transaction on the stack. (I'm not entirely sure why he /likes/ it, I proposed it as kind of an intentionally awful example of how
<gmaxwell>
entirely unrelated operations can create covenants... like accidental turing completeness)-- but that approach tends to be pretty inefficient.
<gmaxwell>
My hope with taproot is that scripts being seriously inefficient are less of an impediment to their use, since in the common case you'd never even expose them.
<jeremyrubin>
Definitely. Best part of COSHV is that it's a hash we already have
<jeremyrubin>
And it's super straightforward to write the code to use them
<jeremyrubin>
very hard to mess up
<gmaxwell>
I do like how surprisingly general COSHV turns out to be for a relatively simple mechenism. (I don't actually think that hash reuse is particularly interesting)
<jeremyrubin>
Hah -- just that it has practically 0 expense
<gmaxwell>
(other than it makes it easier to be confident that it can't be turned into a qudratic hashing attack)
<gmaxwell>
runtime expense of hashing is essentially irrelevant except when there is some trick to cause a LOT of it.
<jeremyrubin>
In any case, I agree that you'd likely prefer the signature path than the lookup in the tree path, especially if you have more than one branch in your congestion control tapscript (e.g., expand one level v.s. expandall)
<jeremyrubin>
But if you do have just the one or have it huffman encoded you *might* prefer it
<jeremyrubin>
Even though that preference is there for N of N I actually take the opposite view
<jeremyrubin>
I think it will be exceedingly common to use the script paths
<jeremyrubin>
under the idea that people will be more likely to engage in business with risky partners
<jeremyrubin>
so this will 'grow the pie' of trustless commerce as people can do things with partners more likely to require arbitration
<gmaxwell>
Risky partners doesn't mean using the script path.
<gmaxwell>
Transacting with a hopless attempted fraud does.
<gmaxwell>
hopeless*
<gmaxwell>
Why bother trying to defraud someone when the script guarentees that you lose?
<jeremyrubin>
Not sure I agree that fraud is a prime case
<gmaxwell>
esp because with sufficient covenants, you can probably guarentee that the cheater pays for the extra txn cost too. :)
<jeremyrubin>
C'est possible
<gmaxwell>
also taproot does NOT mean NofN.
<gmaxwell>
you can also do a 2 of 3 or whatnot at the top level.
<gmaxwell>
The N of N observation is just the point that in the vast majority of situations N of N agreement is sufficient to move the coins.
<jeremyrubin>
hmm but 2 of 3 requires interactive setup right?
<jeremyrubin>
In any case, I think it's something we can armchair all day but ultimately it's something we'll just have to measure in a year or two :)
<jeremyrubin>
Possible that actually a reasonable model is they are uncommon at a uniformly picked time
<jeremyrubin>
But that when they are common, they are very common
<gmaxwell>
Yes, but deciding you want to transact with someone requires interaction too... I also expect the most common non-single-party taproot usage to be a 2 of 3 implemented like this : 2-of-2 OR ((2 of 2) OR (2 of 2)) .... not due to interaction, but due to accountablity, and because the usual usage of 2 of 3 has two hot keys that almost always sign and one cold key.
<jeremyrubin>
(e.g. company went out of business with a lot of contracts)
<sipa>
jeremyrubin: no; you can create a merkle tree with B-and-C and A-and-C, and use MuSig(A-and-B) as internal key
copumpkin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<gmaxwell>
(and scanning the chain supports that, for reused 2 of 3s, there is a single pair which does virtually all of the signing)
<jeremyrubin>
In which case, making them smaller is actually a pretty good goal given there would be increased congestion at that time
<jeremyrubin>
gmaxwell: that's actually not quite true, I can open a channel to you which by default gives me all the money non interactively
<jeremyrubin>
(enabled by OP_COSHV actually -- I don't think so otherwise)
<jeremyrubin>
so while you probably *should* get interaction to start a channel, I can imagine there are cases where it's convenient to not
<jeremyrubin>
E.g., if you want to open a channel to a read only IOT device
<gmaxwell>
in any case, you've managed to miss or derail my point, and I think actually to the detriment of your own position. I was saying that one of the challenges in moving forward with covenant things is the need for them to be efficient... which is hard while also not just hardcoding single use cases. And it's my hope that taproot makes efficiency less important, which would make it easier to
<gmaxwell>
specify stuff.
<jeremyrubin>
Well my position is making Bitcoin serve users well, so if it's doing that or not is the prime motivator
<jeremyrubin>
so not sure if anything is detrimental to that if it gives you rise to feel differently
<gmaxwell>
IOW, if I was focusing on efficiency I'd say that we should hold off on any kind of OP_COSHV until we could get the implicit form used, because the gross inefficiency of having to have an extra 32 bytes for every input, for no real purpose. But the existance of the top spend means that users can (hopefully frequently) completely avoid that inefficiency, so its less important.
<jeremyrubin>
I think it's just conjecture about taproot and focus on efficiency. Certainly in terms of Omega bounds. Not in terms of O()
<jeremyrubin>
gmaxwell: that's an intersting point. I think that the pre-signed versions of OP_COSHV are really difficult to get to work because people can trivially DoS it. But yeah; did you see my paper I was working on where you can do that form just with ECDSA>
<jeremyrubin>
No one would review it because it had ECDSA in it
<jeremyrubin>
But you can do an optimized ECDSA distributed signing because you can use ephemeral keys all along the spend paths, and abort if you don't make the whole tree
<jeremyrubin>
I'm not positive it's secure, it hasn't been reviewed, but it can probably be made secure using some of the more recent schemes at a slight efficiency hit
<jeremyrubin>
But if you want to take the 'see if it works w/o the COSHV' we could implement this :p
<gmaxwell>
man, I know you want to make things concrete, but if I'd seen this paper previously I wouldn't have read it because from the title and top it sounds like it's just a protocol for N of N ecdsa.
<gmaxwell>
I'd only bother reading that if I really felt I had to go implement N of N ECDSA. :)
<jeremyrubin>
Well i presented at BPASE 17 on it as well
<jeremyrubin>
And then it was just covenants... to which the response was no covenants ;)
<gmaxwell>
I don't know where you got that from? the whole no covenants to me just sounds foreign.
satwo has joined #bitcoin-wizards
<gmaxwell>
(perhaps because so many covenants ideas are stupid/pointless) :)
satwo has quit [Client Quit]
<gmaxwell>
In any case, you have my vote to lead more with the end result than the mechenism! :)
<jeremyrubin>
Hahah I'm just going to leave you with a quote from you on bitcointalk about covenants: "Any attempt to think of why someone might want to do this leaves me screaming in horror"
<jeremyrubin>
I also recall their being a lot of pushback on Gun's covenants design (rightfully perhaps, it's too much IMO)
<gmaxwell>
jeremyrubin: "this" I'm talking about there is perpetual rules.
arubi has quit [Remote host closed the connection]
arubi has joined #bitcoin-wizards
<gmaxwell>
things like COSHV can't be used to create meningfully perpetual rules AFAICT, but even if they could it would just be awful to do it.
<gmaxwell>
not a particular reason to not have COSHV.
<gmaxwell>
take a more full quote there: "A particular sort of rule could take the form of requiring any output scriptpubkey to be of the form THIS_VALIDATION_KEY && {whatever rules you want} and by doing so you have effectively created a coin which is forever subject to a covenant which will run with the coin and forever constrain the use of it and its descendants degrading and its fungibility. Any
<gmaxwell>
attempt to think of why someone might want to do this leaves me screaming in horror— Which you should expect as this is the robotic equivalent of a home owners association."
<sipa>
gmaxwell: right, but i think jeremyrubin is saying he feels the need to point out that coshv can't be used for perpetual rules, because in general covenants introduce that risk
<sipa>
or at least pointing out that the type of covenent introduced by coshv isn't the perpetual rule one
<jeremyrubin>
sipa: right. This is why I'm particularly against CHECKSIGFROMSTACK
<gmaxwell>
It has also never been my position that the consensus rules shouldn't make perpetual rules impossible-- I actually think thats essentially impossible, and I still suspect there is a way to construct them. The whole reason I came up with that 'signature to hash the transaction' approach was an effort to figure out how to get a perpetual rule in the existing script.
<gmaxwell>
Only that you'd be a total moron or evil to actually make use of a perpetual rule.
<jeremyrubin>
anyways I think we're very side tracked now
<gmaxwell>
I mean, I do know how to construct them, in the existing system, if you believe that indistinguishability obfuscation can be made secure... just have an IO signing program.. :)
Aaronvan_ is now known as AaronvanW
<gmaxwell>
jeremyrubin: sure, but if people are going around saying that consensus rules shouldn't be added because of some generalized fear of covenants, I'd like to know so I can attempt to stop it-- since obviously I might be part of the source of it.
<jeremyrubin>
So personally I don't worry about recursive covenants as much as I worry about argument templated ones.
mryandao has joined #bitcoin-wizards
<sipa>
i'm personally more concerned about adding features to script that may interfere with the ability to coinjoin transaction pieces from heterogenous sources
<jeremyrubin>
perpetuality on a 2-of-2 big brother multisig can be emulated by just having a million deep covenant that templates the receiver address
<jeremyrubin>
but not the govt address
<gmaxwell>
I wouldn't worry about any of it. The risk with any script feature isn't that it'll be used in a bad way, the risk is that it won't be used at all. like 99% of script today.
<jeremyrubin>
haha
<jeremyrubin>
OP_1's all my bitcoin
mryandao_ has quit [Ping timeout: 256 seconds]
<gmaxwell>
okay, sure breaking things like coinjoin is also a concern but I think it's generally hard to do that?
<sipa>
to be fair, if we'd design script today, it would also drop 98% :p
<sipa>
gmaxwell: hard to break coinjoin, or hard to not break it?
<gmaxwell>
hard to break it
<jeremyrubin>
anyways
<sipa>
coshv as is breaks it
<gmaxwell>
Agreed. I didn't say impossible. :P
<jeremyrubin>
sipa: if you read the scrollback, how do you feel about template softfork
<sipa>
jeremyrubin: sorry, haven't followed the discussion
spinza has quit [Quit: Coyote finally caught up with me...]
<jeremyrubin>
sipa: 14:16, maybe just read greg's summarization later down
<jeremyrubin>
at 14:40
<sipa>
i saw that part, but i think i miss some context
<sipa>
what it's trying to address, how it fits in, what templates are useful for, ...
<jeremyrubin>
well, earlier we claimed to you that you can't add templating to taproot via softfork
<gmaxwell>
sipa: JR was trying to solve the problem of how to efficiently get the output hash into the transaction without stating it explicitly.
<jeremyrubin>
without changing hashing
morcos has quit [Remote host closed the connection]
<jeremyrubin>
I realized that you can do this
<jeremyrubin>
in such a manner that is not useful for my application
morcos has joined #bitcoin-wizards
<jeremyrubin>
But is maybe generally useful if we do templating for other params
<jeremyrubin>
Or more powerful variants of OP_COSHV
<gmaxwell>
sipa: that requires changing the hashing function, he found a way to do it as a softfork to the existing taproot proposal, mid tree. The overhead of doing it makes it not useful for his initial application, but maybe its useful for something else.
<gmaxwell>
sipa: in any case, we can fix the coinjoin breakage of OP_COSHV easily enough, I believe. I didn't say it was impossible to break coinjoin. Just hard.
<jeremyrubin>
gmaxwell: also one thing I just realized, the right hand branch elisison compression for new versions at p2p/storage still works :)
<gmaxwell>
Yes.
<sipa>
gmaxwell: eh, i have the opposite impression; it's really hard to design features that can put constraints on output scripts that are generically compatible with coinjoin (in particular, don't require all participants to support extensions for the type of covenant you're using)
<sipa>
unless you make those features very restrictive
<jeremyrubin>
sipa: can you restate the original concern for me? That you can't take a COSHV output into a coinjoin?
<gmaxwell>
sipa: Well how compatible do you want? -- sighash single still exists.
<sipa>
jeremyrubin: only 1 input allowed.
<jeremyrubin>
Ah, yeah.
<sipa>
as gmaxwell says, i believe this is fixable... though it adds complication to coinjoin implementations to do so
<jeremyrubin>
Covenants generally are realllllly hard to make work without the 1 input restrict
<gmaxwell>
sipa: my "we can fix" was regarding 1 input. It would still remain functionally similar to a sighash single where the anonymity set of a joint transaction is compromised.
<sipa>
and i suspect that the more generic a covenant structure is, the harder it is to make it functionally compatible with coinjoins
<jeremyrubin>
sipa: remember you can still N-of-N into a coinjoin?
<gmaxwell>
To be clear "don't break coinjoin" also means "don't break many different kinds of atomic spending"
<sipa>
right
<gmaxwell>
I have a proposed use of a JR-style output covenant that depends pretty critically on being able to support multiple inputs, though mostly in the N of N case.
<jeremyrubin>
Also just noting the only-one-input restriction is very important for using it as a channel tree
<jeremyrubin>
because you need stable txids
<jeremyrubin>
unless you also have anyprevout.
<jeremyrubin>
So I think that in any case the 'can use multiple inputs' is an option
<gmaxwell>
jeremyrubin: I am doubtful it's sufficient for channel trees even with the one input restriction, though I'm sure you've thought about it a lot more than you. .. there are a lot of sources of txid malleability you don't appear to have considered.
<gmaxwell>
(e.g. set the txn version...)
<gmaxwell>
er you've thought it a lot more than I. :P
<jeremyrubin>
Yeah I've been thinking about that a bit
<sipa>
gmaxwell: we've thought about this in the context of programmable signatures, but i don't know if it's written up anywhere, it may be relevant here. essentially every signature is a constraint on the spending transaction, of the form "f(tx, sighash)=v", where v is included in the signature hash; we could generalize this and have a language that extracts features from a transaction, which then gets
<jeremyrubin>
We might want a soft fork that is something like if malleable set default values
<sipa>
evaluated on the tx and its output...
<sipa>
included in the sighash (this could even include a constraint like "locktime>x", where the boolean outcome is signed, and you can rebind to anything that evaluates the same)
<jeremyrubin>
I'm worried about locktimes and version etc
<jeremyrubin>
I think it might make sense to just commit to everything except the inputs
<jeremyrubin>
(and witness)
<jeremyrubin>
basically anything that can affect the txid, except the input
michaelsdunn1 has quit [Remote host closed the connection]
spinza has joined #bitcoin-wizards
ddustin has joined #bitcoin-wizards
<jeremyrubin>
Can also be done piecmeal by always including a CheckSequence/locktime opcode
<jeremyrubin>
And then making a fix in a higher transaction version 3
<gmaxwell>
jeremyrubin: not so for version, (and god knows whatever else were aren't thinking of... this is why malleability sucks. :P )
<jeremyrubin>
hmm. Maybe it's best to just make a copy of the exact TXID code and set all inputs to 0
ddustin has quit [Remote host closed the connection]
ddustin has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 258 seconds]
ccdle12 has joined #bitcoin-wizards
DeanGuss has joined #bitcoin-wizards
ddustin has quit [Remote host closed the connection]
justan0theruser has joined #bitcoin-wizards
justanotheruser has quit [Ping timeout: 268 seconds]
DeanGuss has quit [Remote host closed the connection]