Subject: [bitcoindev] Re: OP_CAT Research Fund sponsored by StarkWare

From: Antoine Riard <[email-masked]>
Date: Mon, 2 Sep 2024 17:35:06 -0700 (PDT)

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 ?).

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.

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...).

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.

(...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
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].

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

[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
Le jeudi 29 août 2024 à 17:21:27 UTC+1, /dev /fd0 a écrit :

> Hi Victor,
>
> I am not interested in submitting any proposals based on the guidelines 
> <https://starkware.co/submission-proposals/>, however below are some 
> interesting observations and research related to OP_CAT:
>
> Drivechain: https://sha-gate-demo.netlify.app/ 
> AOPP 2.0: 
> https://groups.google.com/g/bitcoindev/c/6SgD6_rmNAQ/m/Q3cTqaqEDQAJ
> AMM : https://xcancel.com/super_testnet/status/1826674357860811036
> 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
> On Thursday, August 29, 2024 at 1:27:53 PM UTC Victor Kolobov 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/>!
>>
>

-- 
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 [email-masked].
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/adbc4f2a-f9ba-48e5-85f0-bf7d548a46d0n%40googlegroups.com.