Hey Jeremy, > On the topic of drafting BIPs for specific use cases, I agree that would be valuable and can consider it. > However, I'm a bit skeptical of that approach overall as I don't necessarily think that the applications *must be* standard, and I view BIPs as primarily for standardization whereas part of the flexibility of CTV/Sapio allows users to figure out how they want to use it. Electronic components (think an integrated circuit or a capacitor) usually have both a "data sheet" and a set of "application notes". The data sheet is like a spec or the formal documentation: how the thing works (or is intended to work), precise dimensions and tolerances, etc. On the other hand, the Application Notes are either a separate document or an appendix to the data sheet with specific details about using that component in a specific application: things like schematics for an example implementation, things to watch out for (edge cases or unexpected application-specific behavior, etc.). I appreciate the balance you're trying to strike between having the BIP for CTV have enough details about how you think it might be used and having it exclusively be a spec to help drive standardization. Maybe the solution here is to have some explicit application notes that have enough details to give people a sense of how these uses could be built out, but still have it be clear that they are a use of, not a part of CTV itself by having it either in a linked document or an appendix or something. Just a suggestion. Cheers, Alex On Tue, Jan 18, 2022 at 6:54 PM Jeremy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Thanks for the detailed review. > > I'll withhold comment around activation logic and leave that for others to > discuss. > > w.r.t. the language cleanups I'll make a PR that (I hope) clears up the > small nits later today or tomorrow. Some of it's kind of annoying because > the legal definition of covenant is "A formal agreement or promise, > usually included in a contract or deed, to do or not do a particular act; a > compact or stipulation made in writing or by parol." so I do think things > like CLTV/CSV are covenants since it's a binding promise to not spend > before a certain time... it might be out of scope for the BIP to fully > define these terms because it doesn't really matter what a covenant could > be as much as it matters what CTV is specifically. > > On the topic of drafting BIPs for specific use cases, I agree that would > be valuable and can consider it. > > However, I'm a bit skeptical of that approach overall as I don't > necessarily think that the applications *must be* standard, and I view BIPs > as primarily for standardization whereas part of the flexibility of > CTV/Sapio allows users to figure out how they want to use it. > > E.g., we do not yet have a BIP for MuSig or even Multisig in Taproot, > although there are some papers and example implementations but nothing > formal yet > https://bitcoin.stackexchange.com/questions/111666/support-for-taproot-multisig-descriptors). > Perhaps this is an opportunity for CTV to lead on the amount of formal > application designs available before 'release'. > > As a starting point, maybe you could review some of the application > focused posts in rubin.io/advent21 and let me know where they seem > deficient? > > Also a BIP describing how to build something like Sapio (and less so Sapio > itself, since it's still early days for that) might help for folks to be > able to think through how to compile to CTV contracts? But again, I'm > skeptical of the value of a BIP v.s. the documentation and examples > available in the code and https://learn.sapio-lang.org. > > I think it's an interesting discussion too because as we've just seen the > LN ecosystem start the BLIP standards, would an example of non-interactive > channels be best written up as a BIP, a BLIP, or a descriptive blog/mailing > list post? > > -- > @JeremyRubin > > > > On Tue, Jan 18, 2022 at 1:19 PM Luke Dashjr via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> tl;dr: I don't think CTV is ready yet (but probably close), and in any >> case >> definitely not worth reviving BIP 9 with its known flaws and >> vulnerability. >> >> My review here is based solely on the BIP, with no outside context (aside >> from >> current consensus rules, of course). In particular, I have _not_ looked >> at >> the CTV code proposed for Bitcoin Core yet. >> >> >Covenants are restrictions on how a coin may be spent beyond key >> ownership. >> >> nit: Poorly phrased. Even simple scripts can do that already. >> >> >A few examples are described below, which should be the subject of >> future >> non-consensus standardization efforts. >> >> I would ideally like to see fully implemented BIPs for at least one of >> these >> (preferably the claimed CoinJoin improvements) before we move toward >> activation. >> >> >Congestion Controlled Transactions >> >> I think this use case hasn't been fully thought through yet. It seems >> like it >> would be desirable for this purpose, to allow any of the recipients to >> claim >> their portion of the payment without footing the fee for every other >> payment >> included in the batch. This is still a covenant-type solution, but one >> that >> BIP 119 cannot support as-is. >> >> (I realise this may be a known and accepted limitation, but I think it >> should >> be addressed in the BIP) >> >> >Payment Channels >> >> Why batch mere channel creation? Seems like the spending transaction >> should >> really be the channel closing. >> >> >CHECKTEMPLATEVERIFY makes it much easier to set up trustless CoinJoins >> than >> previously because participants agree on a single output which pays all >> participants, which will be lower fee than before. >> >> I don't see how. They still have to agree in advance on the outputs, and >> the >> total fees will logically be higher than not using CTV...? >> >> >Further Each participant doesn't need to know the totality of the >> outputs >> committed to by that output, they only have to verify their own sub-tree >> will >> pay them. >> >> I don't see any way to do this with the provided implementation. >> >> >Deployment could be done via BIP 9 VersionBits deployed through Speedy >> Trial. >> >> Hard NACK on this. BIP 9 at this point represents developers attempting >> to >> disregard and impose their will over community consensus, as well as an >> attempt to force a miner veto backdoor/vulnerability on deployment. It >> should >> never be used again. >> >> Speedy Trial implemented with BIP 8 made sense* as a possible neutral >> compromise between LOT=True and LOT=False (which could be deployed prior >> to >> or in parallel), but using BIP 9 would destroy this. >> >> As with Taproot, any future deployments should use BIP 8 again, until a >> better >> solution is developed. Reverting back to a known flawed and vulnerable >> activation method should not be done, and it would be better not to >> deploy >> CTV at all at such an expense. >> >> The fact that certain developers attempted to deploy a BIP 9 alternative >> activation for Taproot against community consensus, and that even managed >> to >> get released as "Bitcoin Core", makes it all the more important that the >> community firmly rejects any further action to force this regression. >> >> * it is my opinion a BIP 8 ST would be an okay compromise under those >> circumstances; others do disagree that ST is acceptable at all >> >> > This ensures that for a given known input, the TXIDs can also be known >> ahead >> of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched >> Channel Creation constructions as the redemption TXID could be malleated >> and >> pre-signed transactions invalidated, unless the channels are built using >> an >> Eltoo-like protocol. >> >> Why is it a problem for them to use an Eltoo-like protocol? >> >> Why not just commit to the txid itself if that's the goal? >> >> >P2SH is incompatible with CHECKTEMPLATEVERIFY >> >> Maybe the CTV opcode should only be defined/enforced within witness >> scripts? >> >> >nLockTime should generally be fixed to 0 (in the case of a payment tree, >> only >> the *first* lock time is needed to prevent fee-sniping the root) >> >> Your "Congestion Controlled Transactions" example would only make sense >> with >> the spending transaction much later than the "root", and so could benefit >> from fee sniping malleability. (In fact, in that example, it would be >> better >> not to commit to locktime at all.) >> >> >In the CHECKTEMPLATEVERIFY approach, the covenants are severely >> restricted to >> simple templates. The structure of CHECKTEMPLATEVERIFY template is such >> that >> the outputs must be known exactly at the time of construction. Based on a >> destructuring argument, it is only possible to create templates which >> expand >> in a finite number of steps. >> >> It's not clear to me that this holds if OP_CAT or OP_SHA256STREAM get >> added. >> >> >For example, a exchange's hot wallet might use an address which can >> automatically be moved to a cold storage address after a relative timeout. >> >> Wouldn't it make more sense to just have a UTXO both cold+hot can spend, >> then >> throw away the hot key? >> >> >In contrast to previous forks, OP_CHECKTEMPLATEVERIFY will not make >> scripts >> valid for policy until the new rule is active. >> >> Policy isn't validity, and cannot be dictated by BIPs (or >> anyone/anything, for >> that matter). >> >> Luke >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- Alex Schoof