You are working on a use case of OP_CTV now? Cool, you only recently announced
you were working on Bitcoin Knots (and I think Wasabi before that) so I'm
losing track of all the announcements. Regardless stick with it and build out
more than a rudimentary proof of concept. That is one of the things that is
severely lacking at this point for OP_CTV.
> TBH I am not against Miniscript and still waiting for its support in Core
> which might take another few years. I would love to have multiple programming
> languages so that application developers can decide what works best for them.
I would hope you weren't against Miniscript because Sapio is built on top of it
:) But whatever have fun, I can't do this all day.
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, January 4th, 2022 at 3:06 PM, Prayank <[email protected]> wrote:
> What I have done related to OP_CTV?
>
> https://twitter.com/prayankgahlot/status/1456643891885592579
>
> What am I currently working on that is not shared publicly and will do in
> next few weeks?
>
> Review pull request 21702 and write contracts using Sapio based on few ideas
> that I already have.
>
> What is this assessment based on?
>
> A few months are enough for the recent bounty to find bugs if possible and
> other things pending to be completed.
>
>> you haven't thought about alternative proposals for any particular use case
>> (vaults for example have multiple current alternative proposals and most
>> likely many future ones)
>
> I have read enough about alternative proposals and some of them don't even
> compete with OP_CTV, they can all be implemented and complement each other.
> Vaults is not the only thing that I care about and it would be better if we
> don't assume about research done by others.
>
>> A new programming language (Sapio) sounds great but do you you need it for
>> your use case rather than an alternative high level language like Minsc?
>> Sapio makes use of Miniscript which hasn't been finalized yet or updated for
>> Taproot. Surely that needs to be done first otherwise Sapio is built on top
>> of something that isn't ready? When you make the claims such as a consensus
>> change is ready to go the burden is on you to convince me and other skeptics
>> why. The status quo is the default. "I think it is ready or will be ready"
>> doesn't mean much unless you have done the work.
>
> TBH I am not against Miniscript and still waiting for its support in Core
> which might take another few years. I would love to have multiple programming
> languages so that application developers can decide what works best for them.
>
> I don't understand what work are you expecting me to do in this case to share
> my opinion about a soft fork.
>
>> It is not enough for one individual to say it is ready to be activated,
>> anyone who is expressing that view should understand why the opcode has been
>> designed in the way it has and why it is so important that we should
>> dedicate months of community time to getting a single opcode activated this
>> year.
>
> I have dedicated enough time reading everything related to OP_CTV and discuss
> things that were posted earlier here by Jeremy Rubin. Not sure how many
> skeptics did the same or even tried to discuss anything until recent bounty
> was announced.
>
>> You regularly NACK Core PRs yet you seem willing to wave a consensus change
>> through with no outstanding questions and zero skepticism.
>
> I would NACK and write the reasons in this pull request as well if I find any
> issues and PR author is not addressing them. I had lots of questions at
> conceptual level which have been answered on different platforms and I cannot
> document each conversation. Its a Concept ACK from me and none of the
> contributors could find any issues with PR right now so I don't want to stop
> people from improving Bitcoin.
>
>> As I understand there are IRC workshops next week on BIP 119 [1] that I'd
>> encourage you to join so you can start getting into a position where you can
>> engage with the skeptics on technical concerns. Regrettably (as I said I
>> find this work interesting) I don't feel like I can participate because
>> deployment and activation is being included and I think it is irresponsible
>> to be discussing those at this point. In my view activation should not even
>> be speculated upon until it is clear there is overwhelming community support
>> for a soft fork being activated.
>
> I would be attending the workshops and had even requested Jeremy to use
> Twitch because it would help more people understand things with audio, screen
> sharing etc. I would love to see skeptics participate and discuss technical
> things.
>
>> I don't feel like I can participate because deployment and activation is
>> being included and I think it is irresponsible to be discussing those at
>> this point.
>
> If you don't participate in the workshops you might miss few things. However,
> either Jeremy or one of the participants will ensure they share the summary
> here or even logs would be available.
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>
> Jan 4, 2022, 19:45 by [email protected]:
>
>>> It should be ready to go in a few months IMO
>>
>> What is this assessment based on? I am assuming you haven't done a code
>> review of the opcode, you haven't coded up a real world use case of OP_CTV
>> (or even a primitive proof of concept), you haven't thought about
>> alternative proposals for any particular use case (vaults for example have
>> multiple current alternative proposals and most likely many future ones). A
>> new programming language (Sapio) sounds great but do you you need it for
>> your use case rather than an alternative high level language like Minsc?
>> Sapio makes use of Miniscript which hasn't been finalized yet or updated for
>> Taproot. Surely that needs to be done first otherwise Sapio is built on top
>> of something that isn't ready? When you make the claims such as a consensus
>> change is ready to go the burden is on you to convince me and other skeptics
>> why. The status quo is the default. "I think it is ready or will be ready"
>> doesn't mean much unless you have done the work.
>>
>> You are well aware of the review process in Core for non-consensus changes.
>> For consensus changes you really should be digging even deeper, the bar
>> should be higher and all questions you and others have should be explored in
>> depth. It is not enough for one individual to say it is ready to be
>> activated, anyone who is expressing that view should understand why the
>> opcode has been designed in the way it has and why it is so important that
>> we should dedicate months of community time to getting a single opcode
>> activated this year.
>>
>> I have more sympathy for those who don't follow Bitcoin Core development and
>> Bitcoin Core review on an ongoing basis (note as I said that the bar for
>> consensus changes should be significantly higher than a non-consensus PR).
>> The use cases sound cool and the work is genuinely interesting. But honestly
>> for someone who has followed Bitcoin Core development, review for a while
>> now you really should know better than bandy around statements like "it
>> should be ready to go in a few months" when you currently haven't scratched
>> the surface on the utility and safety of this opcode. You regularly NACK
>> Core PRs yet you seem willing to wave a consensus change through with no
>> outstanding questions and zero skepticism.
>>
>>> If I had to select between a soft fork without any use cases and one with
>>> use cases, I would go with the one that has some use cases with code,
>>> documentation etc. You should propose a new opcode but OP_CTV is not
>>> claiming to cure cancer.
>>
>> Multiple proven built out use cases, sure. Multiple is better than single
>> when you have done the work to ensure they are actually the right tool for
>> those multiple use cases. This work hasn't been done on any of these use
>> cases. The curing cancer analogy was used to elucidate the point that claims
>> should be deeply explored rather than just accepted as true.
>>
>>>> To contrast with his approach, the authors and contributors of another
>>>> future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t
>>>> promoting an imminent soft fork activation attempt and instead are
>>>> building out and testing one of the speculated use cases, eltoo payment
>>>> channels [4].
>>
>>> Because its not ready?
>>
>> As I said it is not ready because the ANYPREVOUT contributors are building
>> out and testing a use case. The high bar on readiness should be applied to
>> all proposals not merely the ones where the authors/contributors decide to
>> impose a high bar themselves.
>>
>> I don't really want to spend my year imploring people to dig deeper on this
>> before indicating they support an imminent activation attempt. Some people
>> don't have the understanding to dig deeper, some people don't have the time
>> and some don't have either. However, if an activation of OP_CTV is attempted
>> this year I am sure it will be contentious [0]. Anyone who cares about
>> Bitcoin development and the ongoing technical work in a multitude of areas
>> should be strongly against a contentious soft fork activation attempt
>> wasting the time of developers and the entire ecosystem even if they don't
>> have the understanding or time to appreciate the reasons why it is
>> contentious.
>>
>> As I understand there are IRC workshops next week on BIP 119 [1] that I'd
>> encourage you to join so you can start getting into a position where you can
>> engage with the skeptics on technical concerns. Regrettably (as I said I
>> find this work interesting) I don't feel like I can participate because
>> deployment and activation is being included and I think it is irresponsible
>> to be discussing those at this point. In my view activation should not even
>> be speculated upon until it is clear there is overwhelming community support
>> for a soft fork being activated.
>>
>> [0]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>> [1]:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019719.html
>>
>> --
>>
>> Michael Folkson
>> Email: michaelfolkson at protonmail.com
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Tuesday, January 4th, 2022 at 11:53 AM, Prayank via bitcoin-dev
>> <[email protected]> wrote:
>>
>>> Hi Michael,
>>>
>>>> If OP_CTV is ready to go now and has overwhelming community support (I
>>>> don’t think either is true) it should surely have been included in the
>>>> Taproot soft fork (perhaps delayed) rather than going through the months
>>>> of activation wrangling and community outreach twice.
>>>
>>> It should be ready to go in a few months IMO and makes no sense to bundle
>>> everything with Taproot soft fork. Things can remain separate and still
>>> considered good enough based on the changes proposed.
>>>
>>>> It should be made clear to any individual(s) that attempt this of the
>>>> knock on impacts and potential short term damage they are inflicting on
>>>> the entire ecosystem.
>>>
>>> I don't see any damage with a soft fork that is being discussed since
>>> years, documented properly, includes code for implementation and examples,
>>> recently got crowdfunding to incentivize review process and improve
>>> security.
>>>
>>>> It seems to me like the author and primary promoter of this proposal
>>>> (Jeremy Rubin) is pushing for an imminent attempted activation of a soft
>>>> fork containing exclusively OP_CTV [2].
>>>
>>> He is doing nothing unexpected and got reasons to support OP_CTV being
>>> implemented soon.
>>>
>>>> To contrast with his approach, the authors and contributors of another
>>>> future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t
>>>> promoting an imminent soft fork activation attempt and instead are
>>>> building out and testing one of the speculated use cases, eltoo payment
>>>> channels [4].
>>>
>>> Because its not ready?
>>>
>>>> Similar work has not been done for any of the speculated use cases of
>>>> OP_CTV.
>>>
>>> There is no comparison between the two. If someone has worked on one of the
>>> speculated uses cases, it makes no difference.
>>>
>>> If we still compare something because of our bias, maybe Sapio is something
>>> that would be more helpful for Bitcoin developers.
>>>
>>>> Instead Jeremy is encouraging people to “soft signal” for soft fork
>>>> activation of OP_CTV presumably in the hope that the building out and
>>>> testing of use cases can be completed post activation.
>>>
>>> We had soft signals from mining pools for Taproot as well and still waiting
>>> for projects to use Taproot. Even miners signaling with speedy trial was
>>> not a guarantee they would follow new consensus rules later. I don't see
>>> anything wrong in looking for people who support a proposal and documenting
>>> it.
>>>
>>>> This is totally irresponsible in my view. A long list of speculated use
>>>> cases means nothing on its own. I can propose a new opcode OP_MAGIC and
>>>> claim it will cure cancer with no potential downsides and hence we should
>>>> have a soft fork activating it as soon as possible.
>>>
>>> If I had to select between a soft fork without any use cases and one with
>>> use cases, I would go with the one that has some use cases with code,
>>> documentation etc. You should propose a new opcode but OP_CTV is not
>>> claiming to cure cancer.
>>>
>>>> I would hope there would be sufficient skepticism that this proposal
>>>> wouldn’t see the light of day.
>>>
>>> I am confident this proposal will be used by lot of Bitcoin projects and
>>> improve privacy, security, decentralization, demand for block space etc.
>>>
>>>> I feel the top priority is to bring some attention to the danger of us
>>>> stumbling into an attempted contentious soft fork activation attempt.
>>>
>>> I feel the danger is a few people able to stop soft forks that improve
>>> Bitcoin because of their bias and opinions which are mostly non-technical.
>>>
>>>> Enabling covenants on Bitcoin is a big step change with barely any
>>>> existing research on the topic and attempting to rush it through by the
>>>> back door so soon after Taproot activation should be resisted.
>>>
>>> Nobody has stopped anyone from doing research. There is no backdoor and
>>> everything is public. So soon? I am not sure if there are any issues with a
>>> soft fork in next few months if its ready.
>>>
>>> --
>>> Prayank
>>>
>>> A3B1 E430 2298 178F
_______________________________________________
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
