[BIP-119] Slim down motivation, add more references #1320

JeremyRubin commented at 4:10 PM on May 10, 2022: contributor

The level of detail in the motivations for BIP-119 was excessive, this PR removes the lengthy motivation section and adds more links out to various resources.

[BIP-119] Slim down motivation, add more references de0ff362fc

in bip-0119.mediawiki:52 in de0ff362fc outdated

 166 | +risk of introducing fungibility discriminants they have not been seriously
 167 | +considered for inclusion in Bitcoin.
 168 | +
 169 | +This BIP introduces a simple covenant called a *template* which enables a
 170 | +limited set of highly valuable use cases without significant risk. BIP-119
 171 | +templates allow for non-recursive fully-enumerated covenants with no dynamic

unknown commented at 4:47 PM on May 10, 2022:

templates allow for '''non-recursive''' fully-enumerated covenants with no dynamic

in bip-0119.mediawiki:55 in de0ff362fc outdated

 169 | +This BIP introduces a simple covenant called a *template* which enables a
 170 | +limited set of highly valuable use cases without significant risk. BIP-119
 171 | +templates allow for non-recursive fully-enumerated covenants with no dynamic
 172 | +state. CTV serves as a replacement for a pre-signed transaction oracle, which
 173 | +eliminates the trust and interactivity requirements.  Examples of uses include
 174 | +wallet vaults, non-interactive payment channel creation, congestion controlled

unknown commented at 4:50 PM on May 10, 2022:

vaults, non-interactive payment channel creation, congestion controlled

unknown approved

unknown commented at 4:54 PM on May 10, 2022: none

ACK https://github.com/bitcoin/bips/pull/1320/commits/de0ff362fc70a814978b6b11ee8887109a6bdc40

This would make it easier for developers to review the BIP and not get confused with the use cases. 2 suggestions that can be ignored.

in bip-0119.mediawiki:46 in 24d4accf11 outdated

 160 | -forming a "Payment Pool".
 161 | +Covenants are restrictions on how a coin may be spent beyond key ownership.
 162 | +This is a general definition based on the legal definition which even simple
 163 | +scripts using CSV would satisfy.  Covenants in Bitcoin transactions usually
 164 | +refer to restrictions on where coins can be transferred.  Covenants can be
 165 | +useful to construct smart contracts. As covenants are complex to implement and

bucko13 commented at 6:33 PM on May 10, 2022:

Using two spaces after period elsewhere

in bip-0119.mediawiki:47 in 24d4accf11 outdated

 161 | +Covenants are restrictions on how a coin may be spent beyond key ownership.
 162 | +This is a general definition based on the legal definition which even simple
 163 | +scripts using CSV would satisfy.  Covenants in Bitcoin transactions usually
 164 | +refer to restrictions on where coins can be transferred.  Covenants can be
 165 | +useful to construct smart contracts. As covenants are complex to implement and
 166 | +risk of introducing fungibility discriminants they have not been seriously

bucko13 commented at 6:34 PM on May 10, 2022:

should this be "risk introducing fungibility discriminants"?

comma after "discriminants" to split up the clauses.

bucko13 commented at 6:35 PM on May 10, 2022: none

ACK. Just a couple of small copy edit nits.

AdamISZ commented at 9:57 PM on May 22, 2022: contributor

ACK for this simplification, the very large detailing of application constructs seemed not appropriate for this type of doc.

Having said that, it may be overkill to give only names and leave everything else to citations; short summaries in-text of a few major applications are common (off the top of my head I remember BIP65, BIP340, I'm sure there are many, many others!). But I mean, this works, as is.

(Another thing to consider is ordering: I never liked having to scroll so far down to find the Rationale section).

[BIP-119] No double space after period, no trailing whitespaces b29a3d27bf

[BIP-119] Reword section on fungibility in motivation c05f4042f4

[BIP-119] Minor wording fixups

Co-authored-by: /dev/fd0 <94559964+1440000bytes@users.noreply.github.com>

cde2bd31a2

JeremyRubin force-pushed on May 23, 2022

JeremyRubin commented at 6:36 PM on June 2, 2022: contributor

@AdamISZ I think the BIP-65 example makes me think that it may be best to err on the lighter side w.r.t. applications...

None of the given examples are particularly in common use, if at all? Where they have been used is in HTLCs, which are (IMO -- I could be misreading) very different from what is stated in the BIP.

Similarly, BIP-340 links to MuSig, which has a flaw rendering it "less usable"/unprovable.

This leads me to believe that it's better to be abstract in the applications section, as previous examples in BIPs don't fully stand the test of time, but the concepts do.

AdamISZ commented at 8:14 PM on June 2, 2022: contributor

I think that's a pretty decent overall take fwiw.

(Re: BIP340's link to the 2018/068 paper, it's no longer the flawed version there, but the patched up one, so it's not technically a mistake, but yeah for sure once the MuSig2 BIP is actually assigned they will presumably want to update it since that's significantly preferable).

luke-jr merged this on Jul 25, 2022

luke-jr closed this on Jul 25, 2022

luke-jr commented at 9:11 PM on July 25, 2022: member

IMO better to keep it all in the BIP (links die), but you're the author...