OP_CAT Research Fund sponsored by StarkWare
368 views
Skip to first unread message
Victor Kolobov
Aug 29, 2024, 9:27:53 AMAug 29
to Bitcoin Development Mailing List
Hey all,
StarkWare has announced a $1 million bounty for compelling arguments either in favor of or against the activation of OP_CAT. This bounty is overseen by a committee which includes the following members:
Andrew Poelstra (Chair) - Blockstream
Victor Kolobov (Secretary General) - StarkWare
Avihu Levy - StarkWare
Clara Shinkleman - Chaincode
Ethan Heilman - BastionZero
Louis Guthman - StarkWare
Olaoluwa Osuntokun - Lightning Labs
Robin Linus - ZeroSync
Tadge Dryja
The bounty is intended to gather well-reasoned arguments from the community, either supporting or opposing the activation of OP_CAT. Topics of interest include but are not limited to: the security implications of OP_CAT activation on Bitcoin, OP_CAT-based computing and locking script logic on Bitcoin, applications and protocols utilizing OP_CAT on Bitcoin, and general research related to OP_CAT and its impact.
Please apply here!
Matt Corallo
Aug 29, 2024, 10:10:07 AMAug 29
to Victor Kolobov, Bitcoin Development Mailing List
While I welcome the effort, its worth pointing out that bounties like this have a very long history
of generating no interesting results because people who might otherwise generate interesting results
are rarely motivated by bounties.
Matt
On 8/29/24 9:18 AM, 'Victor Kolobov' via Bitcoin Development Mailing List wrote:
> Hey all,
>
>
> StarkWare has announced a $1 million bounty for compelling arguments either in favor of or against
> the activation of OP_CAT. This bounty is overseen by a committee which includes the following members:
>
> *
>
> Andrew Poelstra (Chair)- Blockstream
>
> *
>
> Victor Kolobov (Secretary General)- StarkWare
>
> *
>
> Avihu Levy- StarkWare
>
> *
>
> Clara Shinkleman- Chaincode
>
> *
>
> Ethan Heilman- BastionZero
>
> *
>
> Louis Guthman- StarkWare
>
> *
>
> Olaoluwa Osuntokun- Lightning Labs
>
> *
>
> Robin Linus- ZeroSync
>
> *
>
> --
> You received this message because you are subscribed to the Google Groups "Bitcoin Development
> Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> bitcoindev+...@googlegroups.com <mailto:bitcoindev+...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/bitcoindev/04b61777-7f9a-4714-b3f2-422f99e54f87n%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/04b61777-7f9a-4714-b3f2-422f99e54f87n%40googlegroups.com?utm_medium=email&utm_source=footer>.
of generating no interesting results because people who might otherwise generate interesting results
are rarely motivated by bounties.
Matt
On 8/29/24 9:18 AM, 'Victor Kolobov' via Bitcoin Development Mailing List wrote:
> Hey all,
>
>
> StarkWare has announced a $1 million bounty for compelling arguments either in favor of or against
> the activation of OP_CAT. This bounty is overseen by a committee which includes the following members:
>
>
> Andrew Poelstra (Chair)- Blockstream
>
> *
>
> Victor Kolobov (Secretary General)- StarkWare
>
> *
>
> Avihu Levy- StarkWare
>
> *
>
> Clara Shinkleman- Chaincode
>
> *
>
> Ethan Heilman- BastionZero
>
> *
>
> Louis Guthman- StarkWare
>
> *
>
> Olaoluwa Osuntokun- Lightning Labs
>
> *
>
> Robin Linus- ZeroSync
>
> *
>
> Tadge Dryja
>
> The bounty is intended to gather well-reasoned arguments from the community, either supporting or
> opposing the activation of OP_CAT. Topics of interest include but are not limited to: the security
> implications of OP_CAT activation on Bitcoin, OP_CAT-based computing and locking script logic on
> Bitcoin, applications and protocols utilizing OP_CAT on Bitcoin, and general research related to
> OP_CAT and its impact.
>
>
> Please apply here <https://starkware.co/submission-proposals/>!
> Tadge Dryja
>
> The bounty is intended to gather well-reasoned arguments from the community, either supporting or
> opposing the activation of OP_CAT. Topics of interest include but are not limited to: the security
> implications of OP_CAT activation on Bitcoin, OP_CAT-based computing and locking script logic on
> Bitcoin, applications and protocols utilizing OP_CAT on Bitcoin, and general research related to
> OP_CAT and its impact.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "Bitcoin Development
> Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> bitcoindev+...@googlegroups.com <mailto:bitcoindev+...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/bitcoindev/04b61777-7f9a-4714-b3f2-422f99e54f87n%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/04b61777-7f9a-4714-b3f2-422f99e54f87n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Greg Tonoski
Aug 29, 2024, 10:10:18 AMAug 29
to Bitcoin Development Mailing List, Victor Kolobov
@Admin
I am reporting this thread as spam. "Posts must concern development of bitcoin protocol and be technical or academic (patches, PRs, BIPs, academic papers)."
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/04b61777-7f9a-4714-b3f2-422f99e54f87n%40googlegroups.com.
/dev /fd0
Aug 29, 2024, 12:21:27 PMAug 29
to Bitcoin Development Mailing List
Hi Victor,
I am not interested in submitting any proposals based on the guidelines, however below are some interesting observations and research related to OP_CAT:
Drivechain: https://sha-gate-demo.netlify.app/
On-chain DEX: https://gitlab.com/GeneralProtocols/anyhedge/contracts/-/blame/development/contracts/v0.12/artifact.json?ref_type=heads#L93
Zero-conf: https://gitlab.com/-/snippets/3735654
/dev/fd0
floppy disk guy
Antoine Riard
Sep 2, 2024, 8:39:40 PMSep 2
to Bitcoin Development Mailing List
Hi all,
> While I welcome the effort, its worth pointing out that bounties like this have a very long history
> of generating no interesting results because people who might otherwise generate interesting results
> are rarely motivated by bounties.
From my experience, I both agree and disagree with that viewpoint.
Since taproot activation in 2021, I think that one of the main reason there has been a complete stale
in all consensus discussions related to soft-fork changes about covenants or contracting primitives
extending bitcoin script is the lack of following some trial-and-error design & development process.
In the similar fashion and with the same level of rigors as we have seen with schnorr / taproot changes
themselves, where the idea of a merkle tree to commit to a set of scripts is as old as 2013 [0].
Let's recall briefly some steps of taproot design & development process, as it did happen.
With taproot, there has been for years a competing debate of technical ideas between the templated approach
(what is today bip341 / bip340) and the approach allowing more flexibility for the application / protocol
designer (bip144 or the bip116 / bip117 combination). Following this debate of idea, there was a bip proposal
to enshrine the taproot idea in a concrete technical idea in May 2019 [1] (Though was the coalescing of merkle
ideas in a single proposal done in a public, open and fair process ? I believe there were complaints from Maaku
that is was done in a more or less close-fashion at CoreDev NYC in March 2018, of which a transcript is here [2]
Was this discussed more at the CoreDev one in Tokyo 2018 ?).
> While I welcome the effort, its worth pointing out that bounties like this have a very long history
> of generating no interesting results because people who might otherwise generate interesting results
> are rarely motivated by bounties.
Since taproot activation in 2021, I think that one of the main reason there has been a complete stale
in all consensus discussions related to soft-fork changes about covenants or contracting primitives
extending bitcoin script is the lack of following some trial-and-error design & development process.
In the similar fashion and with the same level of rigors as we have seen with schnorr / taproot changes
themselves, where the idea of a merkle tree to commit to a set of scripts is as old as 2013 [0].
Let's recall briefly some steps of taproot design & development process, as it did happen.
With taproot, there has been for years a competing debate of technical ideas between the templated approach
(what is today bip341 / bip340) and the approach allowing more flexibility for the application / protocol
designer (bip144 or the bip116 / bip117 combination). Following this debate of idea, there was a bip proposal
to enshrine the taproot idea in a concrete technical idea in May 2019 [1] (Though was the coalescing of merkle
ideas in a single proposal done in a public, open and fair process ? I believe there were complaints from Maaku
that is was done in a more or less close-fashion at CoreDev NYC in March 2018, of which a transcript is here [2]
Was this discussed more at the CoreDev one in Tokyo 2018 ?).
Following the debate between technical ideas aiming to bring the same kind of mechanism at the consensus-level
in bitcoin, there was an open review process on IRC at the autumn of 2019, where all attendees were able to
ask technical questions to the taproot bip proposal authors [3]. In parallel, there was a serie of industry
workshops made by Bitcoin Optech to present what the consensus changes would allow to build or improve in
the ecosystem in multiple geographical locations [4].
Following those meetings, there was an implementation pull request open in one of the full-node client in
the early year of 2020 [5], PR which was merged after an extensive code review cycle at the end of the year
of 2020 [6]. Subsequent open technical discussions happened on the mailing list early in 2021 to propose an
in-depth technical analysis of some claimed short-coming of taproot [7].
That's a rough summary of the design & development process followed for Taproot.
in bitcoin, there was an open review process on IRC at the autumn of 2019, where all attendees were able to
ask technical questions to the taproot bip proposal authors [3]. In parallel, there was a serie of industry
workshops made by Bitcoin Optech to present what the consensus changes would allow to build or improve in
the ecosystem in multiple geographical locations [4].
Following those meetings, there was an implementation pull request open in one of the full-node client in
the early year of 2020 [5], PR which was merged after an extensive code review cycle at the end of the year
of 2020 [6]. Subsequent open technical discussions happened on the mailing list early in 2021 to propose an
in-depth technical analysis of some claimed short-coming of taproot [7].
That's a rough summary of the design & development process followed for Taproot.
Concerning what did happen following Taproot activation at the end of 2021, there has been multiple
initiatives to improve the bitcoin script system, most notably by Jeremy with CTV early in 2021 [8].
This proposal was the culmination of years of R&D by Jeremy, as if my memory is correct he did some
workshops about CTV and covenant along the years e.g at one of the Miami conference.
While this proposal didn't gather enough signaling for an activation, some experienced protocol devs have
drawn lessons about this design, development and activation attempt. During the mid-summer I launched a
serie of IRC meetings for covenant devs on an open and public channel [9], which was more or less regularly
attended by a lot of folks. The goal of organizing regular open online meetings was to progressively find
where covenants devs converge (and where they actually diverge) about their bitcoin technical ideas.
In another line of fashion, there was the bitcoin-inquisition fork (yes the naming is from the Monty Python)
by AJ [10] with the objectives to propose and implement an idea and demonstrate it's technically or economically
worthwile. The bitcoin contracting primitives WG has been more or less discontinued by myself (maintainers welcome!),
and I don't think the bitcoin-inquisition fork has been that active (we run out of expert eyes to review sophisticated
consensus changes...).
initiatives to improve the bitcoin script system, most notably by Jeremy with CTV early in 2021 [8].
This proposal was the culmination of years of R&D by Jeremy, as if my memory is correct he did some
workshops about CTV and covenant along the years e.g at one of the Miami conference.
While this proposal didn't gather enough signaling for an activation, some experienced protocol devs have
drawn lessons about this design, development and activation attempt. During the mid-summer I launched a
serie of IRC meetings for covenant devs on an open and public channel [9], which was more or less regularly
attended by a lot of folks. The goal of organizing regular open online meetings was to progressively find
where covenants devs converge (and where they actually diverge) about their bitcoin technical ideas.
In another line of fashion, there was the bitcoin-inquisition fork (yes the naming is from the Monty Python)
by AJ [10] with the objectives to propose and implement an idea and demonstrate it's technically or economically
worthwile. The bitcoin contracting primitives WG has been more or less discontinued by myself (maintainers welcome!),
and I don't think the bitcoin-inquisition fork has been that active (we run out of expert eyes to review sophisticated
consensus changes...).
So I think I agree with the viewpoint that indeed skilled people who can come with interesting results are
rarely motivated by bounties. However this viewpoint is missing some other side of the picture, namely having
a communication space in the bitcoin ecosystem, where novel ideas can be expressed in an open and public fashion,
instead of seeing a communication space locked-down by some bitcoin FOSS veterans (as they fear for the sustainability
of their ivory tower jobs like the usual bureaucract at your local regulatory body who has never got a job in real life,
wasn't one of Jeremy's critic about the consensus design process ? [11]).
So if we think that open and public communication space promoting high standards of scientific and engineering discussions
is one of the key element, I can only invite that bounties be more consumed to nurture open and public process like IRC meetings,
sorting out and archiving well the decade-long of ideas about covenants and bitcoin script extensions or putting back on foot
major open in-person conferences like Scaling Bitcoin, that were disrupted by the pandemie.
rarely motivated by bounties. However this viewpoint is missing some other side of the picture, namely having
a communication space in the bitcoin ecosystem, where novel ideas can be expressed in an open and public fashion,
instead of seeing a communication space locked-down by some bitcoin FOSS veterans (as they fear for the sustainability
of their ivory tower jobs like the usual bureaucract at your local regulatory body who has never got a job in real life,
wasn't one of Jeremy's critic about the consensus design process ? [11]).
So if we think that open and public communication space promoting high standards of scientific and engineering discussions
is one of the key element, I can only invite that bounties be more consumed to nurture open and public process like IRC meetings,
sorting out and archiving well the decade-long of ideas about covenants and bitcoin script extensions or putting back on foot
major open in-person conferences like Scaling Bitcoin, that were disrupted by the pandemie.
(...I don't think CoreDev and other invitation-only dev meetings is an appropriate forum anymore, as someone regularly
invited, in my opinion it becomes more a who you know on the social graph style of in-person meetings, that it is persisting
invited, in my opinion it becomes more a who you know on the social graph style of in-person meetings, that it is persisting
as a meritocracy of ideas, written code and other technical contributions...)
If we ignore the lessons of the past, I think we'll be condemned to repeat them like we have seen with the
blocksize war, where there was on one-side skilled devs cloister-walled on the bitcoin core codebase, that
codebase full of bugs, and on the other side industry companies and application builders aiming to bring
some user traffic to pay for the on-chain fees. I believe there was wrongs and rights on each side.
I think those considerations about working hard to re-insitute or improve the open and public communication
space in which a design & development conversation about consensus changes under high intellectual standards
can happen are valuable. Especially, as it is more and more likely that Bitcoin development process becomes
more targeted by nation-states or other political actors such as Greenpeace. Afterall, it was a very long
time ago that Gavin as a bitcoin maintainer was invited to give highlights about Bitcoin to a very particular
service [12].
If we ignore the lessons of the past, I think we'll be condemned to repeat them like we have seen with the
blocksize war, where there was on one-side skilled devs cloister-walled on the bitcoin core codebase, that
codebase full of bugs, and on the other side industry companies and application builders aiming to bring
some user traffic to pay for the on-chain fees. I believe there was wrongs and rights on each side.
I think those considerations about working hard to re-insitute or improve the open and public communication
space in which a design & development conversation about consensus changes under high intellectual standards
can happen are valuable. Especially, as it is more and more likely that Bitcoin development process becomes
more targeted by nation-states or other political actors such as Greenpeace. Afterall, it was a very long
time ago that Gavin as a bitcoin maintainer was invited to give highlights about Bitcoin to a very particular
service [12].
On those last regards, I think it can be only helpful if future open conferences about Bitcoin scalability
and consensus changes are done in geopolitically neutral locations (e.g Singapor, Switzerland, some Caribbean
Islands, Dubai, Turkey, etc...).
Best,
Antoine
ots hash: 34721270da9b1748b47396950b4418c7a4337a4b531fb75a2aeffc87f8b52a15
and consensus changes are done in geopolitically neutral locations (e.g Singapor, Switzerland, some Caribbean
Islands, Dubai, Turkey, etc...).
Best,
Antoine
ots hash: 34721270da9b1748b47396950b4418c7a4337a4b531fb75a2aeffc87f8b52a15
[0] https://bitcointalk.org/index.php?topic=255145.msg2757327#msg2757327
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015951.html
[3] https://github.com/ajtowns/taproot-review
[4] https://bitcoinops.org/en/workshops/
[5] https://github.com/bitcoin/bitcoin/pull/17977
[6] https://github.com/bitcoin/bitcoin/pull/19997
[7] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018641.html
[8] https://rubin.io/bitcoin/2021/11/28/advent-1/
[9] https://github.com/ariard/bitcoin-contracting-primitives-wg
[10] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
[11] https://rubin.io/bitcoin/2021/11/28/advent-1/
[12] https://bitcointalk.org/?topic=6652.0
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015951.html
[3] https://github.com/ajtowns/taproot-review
[4] https://bitcoinops.org/en/workshops/
[5] https://github.com/bitcoin/bitcoin/pull/17977
[6] https://github.com/bitcoin/bitcoin/pull/19997
[7] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018641.html
[8] https://rubin.io/bitcoin/2021/11/28/advent-1/
[9] https://github.com/ariard/bitcoin-contracting-primitives-wg
[10] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
[11] https://rubin.io/bitcoin/2021/11/28/advent-1/
[12] https://bitcointalk.org/?topic=6652.0
Reply all
Reply to author
Forward
0 new messages