Re: [bitcoin-dev] CTV BIP review

From: Alex Schoof <alex.schoof@gmail•com>
To: Jeremy <jlrubin@mit•edu>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] CTV BIP review
Date: Tue, 18 Jan 2022 19:37:02 -0500	[thread overview]
Message-ID: <CA+2b5C31jcDZaeov5_2kmcfRbMCr2nmdJd0UphGR_2PaGB3y5Q@mail.gmail.com> (raw)
In-Reply-To: <CAD5xwhh3d1=KXEJOPVuYm3UqNKovrojqJS-c6r6ficsKf6S_7g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 9988 bytes --]

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 <https://twitter.com/JeremyRubin>
> <https://twitter.com/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

[-- Attachment #2: Type: text/html, Size: 13226 bytes --]