WIP: Add covenant-related information #806
Conversation
|
Awesome! Concept ACK. Very much looking forward to reviewing this in the next few days. |
|
I just noticed that the BIP119 site uses the term "uses" for what I've been calling "applications". I think "uses" has the advantage of being simpler and clearer, so I plan to switch to that in the next overhaul. |
|
See TAPLEAF_UPDATE_VERIFY entry available here : ariard@c8d46e5 For formatting issues or linking, I think that can be solved a posteriori. Note, the description is a first shot and any statement in the should be taken as lightweighted. I think TLUV is still one of the most "whiteboardy" covenant idea. If you think the entry is mature, feel free to take the commit or if you have more insights to add, let me know. Among the list of covenants in the referenced sketch, I think there is missing the old PUSHTXDATA idea. AFAICT, the more recent OP_TX / OP_TXHASH proposals are roughly equivalent and enable the same level of fine-grained transaction introspection, a really useful feature for a number of applications. Anyway, I think one of them deserves an entry. |
|
concept ACK Reminder that pretty much any of the most basic CTV use cases can be done(less efficiently!) via APO. Probably would want to analyze how much less efficient, especially in the case of something like congestion trees of course. For other cases like DLC it doesn't matter quite as much, since cooperative resolutions bypass the bloat entirely. |
|
@instagibbs claim about it not mattering for e.g. DLCs is false, one of the benefits of CTV for that purpose is that it can make it like 300x faster to construct, which you can backfill in with cooperative closes. So in that case it's the opposite sorta; less space efficient with CTV than with signatures, but much faster time wise, and then backfillable with cooperative resolution (or lazy pre-signing backfill AOT of cooperation). If you used APO -- unless there is some cool properties of signatures using G as a key or something -- it'd probably neutralize the time efficiency such that the technique might not be as worth it, altho still possibly an improvement. |
Whoops, you're right, and yes there is. My memory of the concept was wrong anyways. Thank you for fact-checking me:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019812.html edit: If this reasoning is specious somehow, let's continue on email thread for tracking purposes so we don't derail this PR too bad |
I think here we have a time-vs-space trade-offs, in the sense that if you embed a tree of CTV for any element of your stateful contracts (e.g DLCs) states set, you have a logarithmic witness size. This size would have to be paid by L2 node operators (whatever on-chain, payment-channel level or routed-over-LN) in case of non-cooperative closures. This risk of overhead cost downside might be far above node operators operational risk tolerance. I think it would be interesting to have quantitative measures of hash-chain-based vs script-in-the-sig based design for DLCs for different sizes of |
|
Closing this. I haven't had time to work on it (and I don't see that time becoming available again in the near future). |
|
Bummer, this is a great idea and worth doing. Hopefully it can be part of @ariard's upcoming efforts; I'll be happy to pitch in. |
|
For sure, I'll do my best to keep track of the covenant-related content. A lot of exciting stuff to go through! |
WIP PR to add a collection of information about covenant proposals and their uses to the site. Seeking concept-level feedback at this time, particularly opinions about the per-entry data and presentation, since changing the templates later will be much harder than changing them now.
Previews
TODO