From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 02 Sep 2024 17:39:47 -0700 Received: from mail-yb1-f189.google.com ([209.85.219.189]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1slHaE-0000Se-D7 for bitcoindev@gnusha.org; Mon, 02 Sep 2024 17:39:47 -0700 Received: by mail-yb1-f189.google.com with SMTP id 3f1490d57ef6-e163641feb9sf10361605276.0 for ; Mon, 02 Sep 2024 17:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1725323980; x=1725928780; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=C2cXyQpJcU3rM8w0kBb+bX/rNW+EsZrJokMd7/kJE8U=; b=P9wZf0xRCv+YZdIpsBky51nPynXP+X8kf8FTv6verz3obC3cdV15jtA6YgP8ym5RJ2 8LEf/LcPU+cNAxujUz+XzsdDg6PLN+CVDDDgTJpFlaNlTviEUPfWT9teZ116rkS0yiyk zg1k1+VFY1JO5WzuJCCUtJoLy3l61vo/BsTfbX5Izifmt4Sbw84MzEIhMh9+xOjnnGs8 wyW8d9UnAQ/V3gDCx+K//+WImsWVRu/PxtsxW05vhQ6+bt/JiQBg9MVaKnlUQ3R9j1VM KvrT+x/KopR44MQ+3kzJ4khxCwHOsSdIZrLlaAdIVeG4dcCMe+E2kaLt6e6hSkzdkhPI H9pQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725323980; x=1725928780; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=C2cXyQpJcU3rM8w0kBb+bX/rNW+EsZrJokMd7/kJE8U=; b=e7rPiRymm6q7yed4QyIO8DRKvMyEcX2UeycbytXGOO4JCWrVoBZ6O2tk7OqGp/oaDR jBiU+RAgEx3qiuLPSPCgfWk1lYA3cZoiXKFXAt3G1Sc79dM0r4N+1ETGNT5VDJUVBCpz k/vuu5Q7qi9lkhg8yUp2Dh29fmcCDIHv4ycAlVYvf+tUvJr9+ZQu3EZnq8Sky8ywSElL 6px5eh9fnRt05xZFsmHN5Q+Afugsd3dRS5M3oRUOkAQ0w+kFR8+Gxt4z27MlIm9bO9bn qJtw7Ln4ZKw30NRhl9/YugGfrOqjdKjH2dzn6kTILgfcqJt7gTThZo54P6ojimwzf12R UA+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725323980; x=1725928780; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=C2cXyQpJcU3rM8w0kBb+bX/rNW+EsZrJokMd7/kJE8U=; b=vv0KMVOlHgLB9tiviMCi8Bi4Tht8aorunlgpxJB6ONU7PmaJ8E6EK8hyg66Vvozvwo xWdUE0AjYdQRVe5smdLNngSvRGPzJIy/dfAU/Kv9wJutCiUzqEe2YPCnZxbaKPMk2arl oPc4NLkP6KNQ5zGbFCPrCrScapEuDnRn1K8oSeaXi6IMpvQO+43TslntTV35Kf84mvPX qoY1RnLwj1EBmi/1qS5s543QPGzPimN7f7PlHSSHv/fuAdS6JRXLKSzn63yMdS6ja5di HestOYfNCwHlX0FVbv13xShShreL/wsnBs9gunJ4EBvPy1YMb6oB2nY1lqNy9EknqeJK 5HkA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXaWts2rwnhDsmt3bIbe2kY4C5+80fT0ggyxOzUsd1x+eEFdc3kV1LqAKQbTj6+7bxpcDrYT4IxjvdJ@gnusha.org X-Gm-Message-State: AOJu0YxJTCmFVaIG/4BNjbfdom14pT5oQ4QDUTcVXXCK4wJuvefzAq/T qY252I8G7blFYP0CnwJJQwIEAkWXDpX3QE9jvdmAz5heWGWLalnb X-Google-Smtp-Source: AGHT+IGLMz3RRlBhRpbanP0Vaad9EO+cKH9jTga4baRoHcKmHPXaXHu9Z/XvXsK1tK3H+rsNFxDwgw== X-Received: by 2002:a05:6902:1745:b0:e1a:9286:bc5b with SMTP id 3f1490d57ef6-e1a9286bdd9mr5382375276.21.1725323979650; Mon, 02 Sep 2024 17:39:39 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6902:1547:b0:e16:3642:2a73 with SMTP id 3f1490d57ef6-e1a582643adls122998276.2.-pod-prod-04-us; Mon, 02 Sep 2024 17:39:37 -0700 (PDT) X-Received: by 2002:a05:690c:102:b0:64b:4a9f:540d with SMTP id 00721157ae682-6d40f9286f4mr113678047b3.31.1725323977791; Mon, 02 Sep 2024 17:39:37 -0700 (PDT) Received: by 2002:a05:690c:6906:b0:66a:8967:a513 with SMTP id 00721157ae682-6d3cdd376f4ms7b3; Mon, 2 Sep 2024 17:35:08 -0700 (PDT) X-Received: by 2002:a05:690c:700b:b0:6d6:3cd6:cddc with SMTP id 00721157ae682-6d63cd6d7b0mr64831227b3.45.1725323706318; Mon, 02 Sep 2024 17:35:06 -0700 (PDT) Date: Mon, 2 Sep 2024 17:35:06 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <7f50cfd7-a4d8-4dc9-8daf-ab9d4229824fn@googlegroups.com> References: <04b61777-7f9a-4714-b3f2-422f99e54f87n@googlegroups.com> <7f50cfd7-a4d8-4dc9-8daf-ab9d4229824fn@googlegroups.com> Subject: [bitcoindev] Re: OP_CAT Research Fund sponsored by StarkWare MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_281512_2040249165.1725323706122" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_281512_2040249165.1725323706122 Content-Type: multipart/alternative; boundary="----=_Part_281513_531772300.1725323706122" ------=_Part_281513_531772300.1725323706122 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, > While I welcome the effort, its worth pointing out that bounties like=20 this have a very long history > of generating no interesting results because people who might otherwise= =20 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= =20 has been a complete stale in all consensus discussions related to soft-fork changes about covenants= =20 or contracting primitives extending bitcoin script is the lack of following some trial-and-error=20 design & development process. In the similar fashion and with the same level of rigors as we have seen=20 with schnorr / taproot changes themselves, where the idea of a merkle tree to commit to a set of scripts= =20 is as old as 2013 [0]. Let's recall briefly some steps of taproot design & development process, as= =20 it did happen. With taproot, there has been for years a competing debate of technical=20 ideas between the templated approach (what is today bip341 / bip340) and the approach allowing more flexibility= =20 for the application / protocol designer (bip144 or the bip116 / bip117 combination). Following this debate= =20 of idea, there was a bip proposal to enshrine the taproot idea in a concrete technical idea in May 2019 [1]= =20 (Though was the coalescing of merkle ideas in a single proposal done in a public, open and fair process ? I=20 believe there were complaints from Maaku that is was done in a more or less close-fashion at CoreDev NYC in March=20 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= =20 of mechanism at the consensus-level in bitcoin, there was an open review process on IRC at the autumn of 2019,= =20 where all attendees were able to ask technical questions to the taproot bip proposal authors [3]. In=20 parallel, there was a serie of industry workshops made by Bitcoin Optech to present what the consensus changes=20 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= =20 one of the full-node client in the early year of 2020 [5], PR which was merged after an extensive code=20 review cycle at the end of the year of 2020 [6]. Subsequent open technical discussions happened on the mailing= =20 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=20 Taproot. Concerning what did happen following Taproot activation at the end of 2021,= =20 there has been multiple initiatives to improve the bitcoin script system, most notably by Jeremy=20 with CTV early in 2021 [8]. This proposal was the culmination of years of R&D by Jeremy, as if my=20 memory is correct he did some workshops about CTV and covenant along the years e.g at one of the Miami=20 conference. While this proposal didn't gather enough signaling for an activation, some= =20 experienced protocol devs have drawn lessons about this design, development and activation attempt. During= =20 the mid-summer I launched a serie of IRC meetings for covenant devs on an open and public channel [9],= =20 which was more or less regularly attended by a lot of folks. The goal of organizing regular open online=20 meetings was to progressively find where covenants devs converge (and where they actually diverge) about their= =20 bitcoin technical ideas. In another line of fashion, there was the bitcoin-inquisition fork (yes the= =20 naming is from the Monty Python) by AJ [10] with the objectives to propose and implement an idea and=20 demonstrate it's technically or economically worthwile. The bitcoin contracting primitives WG has been more or less=20 discontinued by myself (maintainers welcome!), and I don't think the bitcoin-inquisition fork has been that active (we run= =20 out of expert eyes to review sophisticated consensus changes...). So I think I agree with the viewpoint that indeed skilled people who can=20 come with interesting results are rarely motivated by bounties. However this viewpoint is missing some other= =20 side of the picture, namely having a communication space in the bitcoin ecosystem, where novel ideas can be=20 expressed in an open and public fashion, instead of seeing a communication space locked-down by some bitcoin FOSS=20 veterans (as they fear for the sustainability of their ivory tower jobs like the usual bureaucract at your local=20 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=20 standards of scientific and engineering discussions is one of the key element, I can only invite that bounties be more consumed= =20 to nurture open and public process like IRC meetings, sorting out and archiving well the decade-long of ideas about covenants and= =20 bitcoin script extensions or putting back on foot major open in-person conferences like Scaling Bitcoin, that were disrupted= =20 by the pandemie. (...I don't think CoreDev and other invitation-only dev meetings is an=20 appropriate forum anymore, as someone regularly invited, in my opinion it becomes more a who you know on the social graph= =20 style of in-person meetings, that it is persisting as a meritocracy of ideas, written code and other technical=20 contributions...) If we ignore the lessons of the past, I think we'll be condemned to repeat= =20 them like we have seen with the blocksize war, where there was on one-side skilled devs cloister-walled on= =20 the bitcoin core codebase, that codebase full of bugs, and on the other side industry companies and=20 application builders aiming to bring some user traffic to pay for the on-chain fees. I believe there was wrongs= =20 and rights on each side. I think those considerations about working hard to re-insitute or improve= =20 the open and public communication space in which a design & development conversation about consensus changes= =20 under high intellectual standards can happen are valuable. Especially, as it is more and more likely that=20 Bitcoin development process becomes more targeted by nation-states or other political actors such as=20 Greenpeace. Afterall, it was a very long time ago that Gavin as a bitcoin maintainer was invited to give highlights= =20 about Bitcoin to a very particular service [12]. On those last regards, I think it can be only helpful if future open=20 conferences about Bitcoin scalability and consensus changes are done in geopolitically neutral locations (e.g=20 Singapor, Switzerland, some Caribbean Islands, Dubai, Turkey, etc...). Best, Antoine ots hash: 34721270da9b1748b47396950b4418c7a4337a4b531fb75a2aeffc87f8b52a15 [0] https://bitcointalk.org/index.php?topic=3D255145.msg2757327#msg2757327 [1]=20 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.htm= l [2]=20 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015951.htm= l [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]=20 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018641.h= tml [8] https://rubin.io/bitcoin/2021/11/28/advent-1/ [9] https://github.com/ariard/bitcoin-contracting-primitives-wg [10]=20 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/0209= 21.html [11] https://rubin.io/bitcoin/2021/11/28/advent-1/ [12] https://bitcointalk.org/?topic=3D6652.0 Le jeudi 29 ao=C3=BBt 2024 =C3=A0 17:21:27 UTC+1, /dev /fd0 a =C3=A9crit : > Hi Victor, > > I am not interested in submitting any proposals based on the guidelines= =20 > , however below are some=20 > interesting observations and research related to OP_CAT: > > Drivechain: https://sha-gate-demo.netlify.app/=20 > AOPP 2.0:=20 > https://groups.google.com/g/bitcoindev/c/6SgD6_rmNAQ/m/Q3cTqaqEDQAJ > AMM : https://xcancel.com/super_testnet/status/1826674357860811036 > On-chain DEX:=20 > https://gitlab.com/GeneralProtocols/anyhedge/contracts/-/blame/developmen= t/contracts/v0.12/artifact.json?ref_type=3Dheads#L93 > Zero-conf: https://gitlab.com/-/snippets/3735654 > > /dev/fd0 > floppy disk guy > On Thursday, August 29, 2024 at 1:27:53=E2=80=AFPM UTC Victor Kolobov wro= te: > >> Hey all, >> >> >> StarkWare has announced a $1 million bounty for compelling arguments=20 >> either in favor of or against the activation of OP_CAT. This bounty is= =20 >> overseen by a committee which includes the following members: >> >> -=20 >> =20 >> Andrew Poelstra (Chair) - Blockstream >> -=20 >> =20 >> Victor Kolobov (Secretary General) - StarkWare >> -=20 >> =20 >> Avihu Levy - StarkWare >> -=20 >> =20 >> Clara Shinkleman - Chaincode >> -=20 >> =20 >> Ethan Heilman - BastionZero >> -=20 >> =20 >> Louis Guthman - StarkWare >> -=20 >> =20 >> Olaoluwa Osuntokun - Lightning Labs >> -=20 >> =20 >> Robin Linus - ZeroSync >> -=20 >> =20 >> Tadge Dryja=20 >> =20 >> The bounty is intended to gather well-reasoned arguments from the=20 >> community, either supporting or opposing the activation of OP_CAT. Topic= s=20 >> of interest include but are not limited to: the security implications of= =20 >> OP_CAT activation on Bitcoin, OP_CAT-based computing and locking script= =20 >> logic on Bitcoin, applications and protocols utilizing OP_CAT on Bitcoin= ,=20 >> and general research related to OP_CAT and its impact.=20 >> >> Please apply here ! >> > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/= bitcoindev/adbc4f2a-f9ba-48e5-85f0-bf7d548a46d0n%40googlegroups.com. ------=_Part_281513_531772300.1725323706122 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 interestin= g results
> are rarely motivated by bounties.

From my ex= perience, I both agree and disagree with that viewpoint.

Since t= aproot activation in 2021, I think that one of the main reason there has be= en a complete stale
in all consensus discussions related to soft-fork = changes about covenants or contracting primitives
extending bitcoin sc= ript 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 year= s 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 / bip11= 7 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 M= aaku
that is was done in a more or less close-fashion at CoreDev NYC i= n March 2018, of which a transcript is here [2]
Was this discussed mor= e at the CoreDev one in Tokyo 2018 ?).

Following the d= ebate between technical ideas aiming to bring the same kind of mechanism at= the consensus-level
in bitcoin, there was an open review process on I= RC at the autumn of 2019, where all attendees were able to
ask technic= al questions to the taproot bip proposal authors [3]. In parallel, there wa= s a serie of industry
workshops made by Bitcoin Optech to present what= the consensus changes would allow to build or improve in
the ecosyste= m in multiple geographical locations [4].

Following those meetin= gs, there was an implementation pull request open in one of the full-node c= lient in
the early year of 2020 [5], PR which was merged after an exte= nsive 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 p= ropose an
in-depth technical analysis of some claimed short-coming of = taproot [7].

That's a rough summary of the design & developm= ent process followed for Taproot.

Concerning wha= t did happen following Taproot activation at the end of 2021, there has bee= n multiple
initiatives to improve the bitcoin script system, most nota= bly by Jeremy with CTV early in 2021 [8].
This proposal was the culmin= ation 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 Mi= ami conference.

While this proposal didn't gather enough signali= ng for an activation, some experienced protocol devs have
drawn lesson= s about this design, development and activation attempt. During the mid-sum= mer I launched a
serie of IRC meetings for covenant devs on an open an= d public channel [9], which was more or less regularly
attended by a l= ot of folks. The goal of organizing regular open online meetings was to pro= gressively find
where covenants devs converge (and where they actually= diverge) about their bitcoin technical ideas.

In another line o= f fashion, there was the bitcoin-inquisition fork (yes the naming is from t= he Monty Python)
by AJ [10] with the objectives to propose and impleme= nt an idea and demonstrate it's technically or economically
worthwile.= The bitcoin contracting primitives WG has been more or less discontinued b= y myself (maintainers welcome!),
and I don't think the bitcoin-inquisi= tion fork has been that active (we run out of expert eyes to review sophist= icated
consensus changes...).

So I think I = agree with the viewpoint that indeed skilled people who can come with inter= esting results are
rarely motivated by bounties. However this viewpoin= t is missing some other side of the picture, namely having
a communica= tion space in the bitcoin ecosystem, where novel ideas can be expressed in = an open and public fashion,
instead of seeing a communication space lo= cked-down by some bitcoin FOSS veterans (as they fear for the sustainabilit= y
of their ivory tower jobs like the usual bureaucract at your local r= egulatory body who has never got a job in real life,
wasn't one of Jer= emy's critic about the consensus design process ? [11]).

So if w= e think that open and public communication space promoting high standards o= f scientific and engineering discussions
is one of the key element, I = can only invite that bounties be more consumed to nurture open and public p= rocess like IRC meetings,
sorting out and archiving well the decade-lo= ng of ideas about covenants and bitcoin script extensions or putting back o= n foot
major open in-person conferences like Scaling Bitcoin, that wer= e disrupted by the pandemie.

(...I don't think C= oreDev and other invitation-only dev meetings is an appropriate forum anymo= re, 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 persis= ting
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 bitco= in core codebase, that
codebase full of bugs, and on the other side in= dustry companies and application builders aiming to bring
some user tr= affic to pay for the on-chain fees. I believe there was wrongs and rights o= n each side.

I think those considerations about working hard to = re-insitute or improve the open and public communication
space in whic= h a design & development conversation about consensus changes under hig= h intellectual standards
can happen are valuable. Especially, as it is= more and more likely that Bitcoin development process becomes
more ta= rgeted by nation-states or other political actors such as Greenpeace. After= all, it was a very long
time ago that Gavin as a bitcoin maintainer wa= s invited to give highlights about Bitcoin to a very particular
servic= e [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 Singap= or, Switzerland, some Caribbean
Islands, Dubai, Turkey, etc...).
=
Best,
Antoine
ots hash: 34721270da9b1748b47396950b4418c7a43= 37a4b531fb75a2aeffc87f8b52a15

[0] https://bitcoi= ntalk.org/index.php?topic=3D255145.msg2757327#msg2757327
[1] https://l= ists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html
[2= ] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015951.h= tml
[3] https://github.com/ajtowns/taproot-review
[4] https://bit= coinops.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://gith= ub.com/ariard/bitcoin-contracting-primitives-wg
[10] https://lists.lin= uxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
[11]= https://rubin.io/bitcoin/2021/11/28/advent-1/
[12] https://bitcointal= k.org/?topic=3D6652.0
Le jeudi 29 ao=C3=BBt 2024 =C3=A0 17:21:27 UTC+1, /= dev /fd0 a =C3=A9crit=C2=A0:
Hi Victor,

I am not interested in submit= ting any proposals based on the guidelines, however below are some interesting observ= ations and research related to OP_CAT:

Drivechain:= =C2=A0https://sha-gate-demo.n= etlify.app/=C2=A0

/dev/fd0
floppy = disk guy
On Thursday, August 29, 2024 at 1:27:53=E2=80=AFPM UTC Victor Kolobov = wrote:

Hey all,

<= p dir=3D"ltr" style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans= -serif;font-size:small;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:12pt;font-family:Arial,sans-serif;color:rgb(0,0,0);= background-color:transparent;font-variant-numeric:normal;font-variant-east-= asian:normal;font-variant-alternates:normal;vertical-align:baseline">
= 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 b= y a committee which includes the following members:

  • Andrew Poe= lstra (Chair) - Blockstream

    • <= li dir=3D"ltr" style=3D"margin-left:15px;list-style-type:disc;font-size:12p= t;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparen= t;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-a= lternates:normal;vertical-align:baseline">

    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=C2=A0<= /span>

The bounty is intended to gather well-reasoned arguments f= rom the community, either supporting or opposing the activation of OP_CAT. = Topics of interest include but are not limited to: the security implication= s of OP_CAT activation on Bitcoin, OP_CAT-based computing and locking scrip= t logic on Bitcoin, applications and protocols utilizing OP_CAT on Bitcoin,= and general research related to OP_CAT and its impact.=C2=A0

Please apply=C2=A0here<= span style=3D"font-size:12pt;font-family:Arial,sans-serif;color:rgb(0,0,0);= background-color:transparent;font-variant-numeric:normal;font-variant-east-= asian:normal;font-variant-alternates:normal;vertical-align:baseline">!

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/adbc4f2a-f9ba-48e5-85f0-bf7d548a46d0n%40googlegroups.com.=
------=_Part_281513_531772300.1725323706122-- ------=_Part_281512_2040249165.1725323706122--