Fix ahistorical CTV BIP summary #1811
Conversation
Fix ahistorical description of CTV/COSHV. https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-coshv.mediawiki
patched text from bitcoinops/bitcoinops.github.io#1811 correcting inaccurate historical record
There was a problem hiding this comment.
Suggestion to fix the build.
I dont have comments on the content changes, but perhaps @harding does
|
thanks for the fix! |
There was a problem hiding this comment.
The current summary seems correct from my perspective. I've added some line comments with citations to the events I witnessed during CTV's early history. That said, I don't think this is really worth arguing about. There's probably a more boring way we can phrase this that is less controversial.
| @@ -139,15 +139,16 @@ assures several receivers that they can each be paid. This two-step | |||
| process can probably be used anywhere payment batching is an option | |||
| but it can likely reduce fees even further than payment batching. | |||
|
|
|||
| Later versions of the proposal placed greater emphasis on other | |||
| The original proposal also emphasized other | |||
There was a problem hiding this comment.
Optech's original summary of COSHV was based on your email, which is titled: "[bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal" and says: "The BIP covers this use case [congestion control] in detail, and a few other use cases lightly."
Modern BIP119 hardly mentions congestion control at all, and all of the detailed content about it has been removed. In the References section of BIP119, which links to multiple use cases, congestion control is second-to-last.
There was a problem hiding this comment.
The original proposal (linked) also included these, applications. At the time I felt I really needed people to grok congestion control as a start, in order to start thinking about how the other applications could work (since channel factories and payment pools build on payment trees). I think the current "greater emphasis" text serves to build on a narrative that CTV was pitched as "only" for congestion control, and it was very limited, and other uses were an afterthought that only came much later to show it could do more than 1 thing, where the truth is that it was presented always with multiple applications.
i removed most of the motivation section because it felt like it was better handled -- and kept more up to date -- outside of the BIP process. https://github.com/bitcoin/bips/pull/1320/files. The current proposal is much lighter on application and motivation entirely.
There was a problem hiding this comment.
At the time I felt I really needed people to grok congestion control as a start, in order to start thinking about how the other applications could work
This is exactly what I observed and what I wrote. The original proposal (via your email) and discussion emphasized congestion control. Later publications by you emphasized other applications.
I think the current "greater emphasis" text serves to build on a narrative that CTV was pitched as "only" for congestion control, and it was very limited, and other uses were an afterthought that only came much later to show it could do more than 1 thing, where the truth is that it was presented always with multiple applications.
I'm sorry that there's a narrative that contains provably false statements and that you think our text, despite being accurate AFAICT, contributes to that.
There was a problem hiding this comment.
FWIW i don't think it's intentional at all and apoliogize thoroughly if you've read it as such.
I meant my top post quite literally -- to the extent people are trying to get an accurate history of the development of covenants, there are some persistant myths worth (to me, maybe others) cleaning up.
| contracts and [covenants][topic covenants] that could be created using | ||
| the new opcode, such as the ability to create [channel | ||
| factories][topic channel factories], [vaults][topic vaults], and | ||
| factories][topic channel factories], [vaults][topic vaults], |
There was a problem hiding this comment.
Why remove the conjunction?
There was a problem hiding this comment.
the and shows up later again
| trustlessly [pool their funds][joinpool] together into a single UTXO | ||
| in a way that would increase privacy. | ||
| in a way that would increase privacy. These other concepts have been | ||
| described in further detail in subsequent works by a variety of authors. |
There was a problem hiding this comment.
We originally had a draft summary of joinpools in the same newsletter that announced COSHV: https://gist.github.com/harding/a30864d0315a0cebd7de3732f5bd88f0 You left at least one comment on that joinpool draft without mentioning at the time that you felt it was improperly attributed to Greg Maxwell. What has changed in the intervening time?
There was a problem hiding this comment.
Gregory Maxwell discussed some of his first impressions of the COSHV proposal to the logged IRC channel #bitcoin-wizards. Among them was a description of how the above multi-transaction tree could be used as part of a coinjoin construction to manage balances offline.
this text still seems accurate to me, so i don't see the descrepency? He gave a description of how it could be used, it doesn't same "greg came up with a whole new way to use it not mentioned in the BIP at all".
There was a problem hiding this comment.
I've only quickly re-skimmed the original COSHV proposal, but I don't see it mentioning what we now call joinpools/payment pools/coinpools. It does describe channel factories, which are pretty much joinpools used for second-layer setup transactions, and it also describes the advantages to single-tx coinjoins, which is obviously related to joinpools---but I don't see anything that describes the novelty of using shared UTXO ownership with keypath spends for vastly enhanced onchain privacy and COSHV for non-interactive creation of the unilateral exit option.
There was a problem hiding this comment.
I think the below text is to that effect:
Each node of the tree can also attempt to 'opt in' to preferring a Taproot signature based spend, but if participants are offline or malicious the expansion can proceed to smaller groups.
If desired, the Tapscript path can be usurped by a signature based spend to improve fungibility.
Critically, because this is a Tapscript, it is intended that participants may collaborate to replace the Tapscript path with a signature. This lifts the requirement of the output being spent alone and the exact match of output hashes, if other dependencies (like channel state) can be updated.
|
Left some replies for @JeremyRubin, but I'm reasonably convinced at this point that our existing text is accurate. That said, I don't think there's any reason for our ~300 word summary to mention any historical details besides the fact that the proposal used to be called COSHV. I have work already scheduled for today and tomorrow, but I'll try to PR my own edit on Thursday. Let's keep this PR open in the meantime to remind me that there's an outstanding issue. |
See #1816 |
jonatack
force-pushed
the
master
branch
4 times, most recently
from
38028a8
to
9db038c
Compare
|
Closing in favor of #1816 which contains many more updates |
To the extent that optech wishes to accurately reflect history of BIP development, the page is innacurate with respect to the CTV proposal's development.
The original publication was https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-coshv.mediawiki which describes the entirety of the summary.
I've noticed that this text is being cited as a true history, and I think it's wrong.