From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 24 Jun 2026 09:36:03 -0700 Received: from mail-ot1-f59.google.com ([209.85.210.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wcQa1-0000Lu-Fw for bitcoindev@gnusha.org; Wed, 24 Jun 2026 09:36:03 -0700 Received: by mail-ot1-f59.google.com with SMTP id 46e09a7af769-7e9330847e8sf45907a34.0 for ; Wed, 24 Jun 2026 09:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1782318955; x=1782923755; 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=QgTDbr3zKMaMsGPMoP3h/1t1tVqgNlmaBus6gR0YV1E=; b=nEI34yBHyj6/A8QSIknUbclhG0t3JinDcrrDuIhJrRA4J38JNYcpqii3X2FeVdwmhH KVM+UVw3zjTROqA/qdBG4uT+/DulZtn4CnJXK+lynHYnqwTHrVEPKoV6UBbJFtSjges/ tTONB24hv7lGkcwNoa/63km5kt3yd2pt1y03RPp7E1RXILw0lkS9t7S0Yn3M2SjYCQvB F49rPYBsktdOnDZyspomMTATZ5rZa2VNKNN8CtwNszqh6h12q0ATLIznp2bmg5zJaeqI NayTEI7CX2DjhM1kOh8tMUgWLbtMofuRXA+6yvd4SHVHy6EALSdTUuf4yEiYDtSQ4Dcy 65Cw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782318955; x=1782923755; 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=QgTDbr3zKMaMsGPMoP3h/1t1tVqgNlmaBus6gR0YV1E=; b=iKAO7k+aeSXWxQODhMBEpyuh6onE6rqqZsqy1tkbaQyxdCOtX3231Qm1FMAtuh2B4o AzKSAEqzWKoTQN8SDnVd6aA+C1GSWrkQPOP4fWMFzTDStQ/uwajtqPCDWxp5c+6IJmuE iHslU4gwyIMFk5t1E0+9DLegE9knutlx0I8tmEYolafaT0kB8ugApMrPDD+QMMxXOTBW +oIon1dL0U2QunulbxgVZx16zdd+k/aefFeyS6jqrSph/b0yHiekNqSKefPt0IZoXY6Y B7BeIoIslmScKagl1o+h4FrgYeyL24xthELYfCWQi4go4kJh14QFvs81jd5fjaQyS7k5 3orA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782318955; x=1782923755; 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=QgTDbr3zKMaMsGPMoP3h/1t1tVqgNlmaBus6gR0YV1E=; b=oS3TqHyVL04JEQSgDnwdsNvH9BIS13O0T4VjuKpnzyDX7851F/05w1JeIm1h2bkAFb +I8tp/HU8Zd2v0442+wIQDDbJRYvrKJIgJT272/fJe3ek1tra6kf0JAT5ghMRq2iq0/n H2RWC6eR8GXFjFxCbkCUOXrMjKP79PawE+NVXwRPxmk1/5lbDmwFkemiRi3YNERctM5z nMUb4qRuDVUSwn90ipwcH9MMVt70YLWpvtNdmlDDl9C4e4WucpLcmw00GVacDYo7g60B ZstcxWKDdqX4rh10WmCUVQj+UbSwmgCW6leO8i2H4sli7VYMMgrnKWs/zN7uw7yOHtH6 sDqA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ8SiwK/XqVsNAq+RYycDQVAn2Mpy5Km/s2Q+xAsgn3qUc4LKezHXeZwhCjaMCrNqZghQEFflkMe39tw@gnusha.org X-Gm-Message-State: AOJu0Yzp4jwmxjx3NDWiwnSUJYF6sNLT5WFR0Xr0T6710n0aikRq7n5u DroTXbLMeB1P33c5nTiZ/hEE4ojmCVPTQeb7K0S2hueUHSqDg7WyI227 X-Received: by 2002:a4a:e905:0:b0:69e:9af9:ab47 with SMTP id 006d021491bc7-6a1127cc75bmr5209027eaf.34.1782318955081; Wed, 24 Jun 2026 09:35:55 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUf3Q4bowNVvdoAa4rwnUHynvTWesC11YJ78jKo6dPAPlA==" Received: by 2002:a05:6871:c783:20b0:3c9:732d:60f2 with SMTP id 586e51a60fabf-446dfb0c760ls2085710fac.1.-pod-prod-02-us; Wed, 24 Jun 2026 09:35:50 -0700 (PDT) X-Received: by 2002:a05:6808:3207:b0:489:a8b7:e450 with SMTP id 5614622812f47-48f275337a1mr6051753b6e.7.1782318950682; Wed, 24 Jun 2026 09:35:50 -0700 (PDT) Received: by 2002:a05:690c:c5c2:b0:809:cfd1:4c3a with SMTP id 00721157ae682-809cfd14f18ms7b3; Wed, 24 Jun 2026 09:33:54 -0700 (PDT) X-Received: by 2002:a05:690c:ed6:b0:7ff:5a5:4080 with SMTP id 00721157ae682-806c177aa0amr83796287b3.10.1782318833626; Wed, 24 Jun 2026 09:33:53 -0700 (PDT) Date: Wed, 24 Jun 2026 09:33:53 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <57b53aee-d46c-452b-959e-0e9645e1c45fn@googlegroups.com> In-Reply-To: References: Subject: [bitcoindev] Re: Accountable Computing On-Chain Contracts for AI Agents Supervision MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_16552_1040528924.1782318833161" 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_16552_1040528924.1782318833161 Content-Type: multipart/alternative; boundary="----=_Part_16553_2075628430.1782318833161" ------=_Part_16553_2075628430.1782318833161 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 Hello, The ideas behind this post came initially from chatting with researchers on this subject at top tier universities, though for the curious here the kind of paper being used for the brainstorming=20 (https://dl.acm.org/doi/pdf/10.1145/3372297.3417278). On the pure matter of contract protocol for AI agents being executed on the bitcoin blockchain, there has been some generic "blockchain" research done at low tiered conf. Using the bitcoin blockchain for AI agent is an old=20 idea [0]. I think the existent real world cryptography is too early, most notably=20 functional homomorphic encryption, the other ask for more refinement [1]. I don't have= =20 more time to dedicate on it with backbone dev and consenus review changes, but= =20 the intellectual problems behind are fascinating, for the bored academic=20 researchers, of which I'm not. Best, Antoine OTS hash: 0a5e357b81f2821a53a1fa5805c2d78f30e638aa9710c65685c533f78ddbfc3f [0] https://bitcointalk.org/index.php?topic=3D53855.0 [1]=20 https://gnusha.org/pi/bitcoindev/CAEM=3Dy+UnxB2vKQpJAa-z-qGZQfpR1ZeW3UyuFFZ= 6_WTWFYGfjw@mail.gmail.com/T/?_=20 "Signing a Bitcoin Transaction with Lamport Signature..." Le Friday, June 19, 2026 =C3=A0 7:47:51=E2=80=AFAM UTC+1, Antoine Riard a = =C3=A9crit : > Hi list, > > With the ongoing discussions on defining a basic format for the > data-carrying annex accompanying P2TR spends comes the question > why it would be useful for. One usage explored in this post is to > be used as an authenticated data payload emplacement and nonce marker > as a component of accountable computing contracts being leveraged > for AI agents supervision [0]. > > ## Robinson Crusoe and the AI agent > > Let's start with an exposition of the problem in isolation. > > A random hacker, called Robinson Crusoe, has failed on a desert island > and he has to reinvent all the basic tools of modern life for his > survival. The hacker avails a single item on his desert island, a > random AI agent application running on a crank handle powered thinkpad. > The random AI agent, let's call it Alice, has access to the whole world > information. > > Our Robinson Crusoe would like to ask questions to the random AI > agent, e.g "what is the easiest way to kickstart a warming fire > at nights ?" or "what is the best method for desalineating seawater?". > Robinson does not have an idea of what the _correct_ AI answer looks > like, and a _wrong_ answer might be a source of harm, e.g getting > sicks of drinking badly desalineated water. > > Formally, Robinson and Alice are playing a game, where the question > cost is measured by the scarce sun energy to power Alice and Robinson > has time-bounded constraints to get correct information or "knowledge" > to the practical survival problems Robinson is facing. > > There is a non-null cost in turning the crank to submit prompts to > Alice and ideally, Rob would like to only turn the crank to power Alice > only if Alice is able to provide a _correct_ answer to the submitted > prompts. There might be a halting problem where Alice is not even able > to provide a _correct_ answer limited by the model performance. > > Robinson and Alice are stuck in a noteworthy information asymmetry, > such as asymmetry being measurable from Robinson's subjective viewpoint > on an energy scale. > > ## The principal-agent relationship and the "fronting" user-agent problem > > In the discipline of economics, the problem of principal-agent > relations is a well-studied issue [1]. Basically, any large social > organization can know incentives problems due to the structural > dissociation between the organization managers and the beneficiaries > of the organization results e.g the shareholders. > > > There is a concern in the incentives problems for the agents operating > in the best interest of the principals, e.g that they are maximizing > the benefice yielded by their managements of the social organization. > > Translated in the world of AI agents, human users are "fronting" > tokens for a solution of which the correctness is uncertain bearing > the sole risks of an AI agent token cost processing. In a more ideal > setup, human users would only pay an AI agent cost *if the solution > is correct*, the AI agent bearing the cost of imprecise solutions, > or even more the AI agent being put in an open competition between > them to "mine" a solution. > =20 > Accessory to the "fronting cost" of acquiring verified computations > from a crowd of AI agents, a group of principals would like to acquire > the verified computation with the minimal sharing of confidential > information. E.g the AI agent execution might be influenced by the > "knowledge" of the user raw information. > > In the following sections, we conjecture a simple protocol bringing > a solution to this AI agent "fronting" cost problem leveraging the > bitcoin blockchain and its scripting mechanism, and minimize AI > structured outputs being a market of "lemons". > > > ## The list of cryptographic and bitcoin primitives > > The taproot annex. With the introduction of the taproot output type > an unspecified consensus field embedded as the last of the witness > element and starting by the marker 0x50. It can be present or absent > in the witness, however this information is committed in the transaction > digest. > > The class of construction known as accountable computing contracts [2]. > While there are multiple ways to do it, basically an ACC it's a payment > that can only be executed if the receiving party verifiably run a specifi= ed > function on a specified set of inputs. > > A functional homomorphic encryption cryptosystem. A FHE is a a kind of > cryptosystem allowing to perform functions on the encrypted data without > first having to decrypt it. > > A zero-knowlewdge cryptosystem. A zero-knowledge cryptosystem is a > protocol in which one party can prove to another party that some random > statement in a defined language is true, without conveying any additional > information beyond the mere fact of the statement truth [3]. > > A contract orchestrer or watchtower system, to provide complete ample > data payloads or timeout the ACC after a defined duration. > > ## A Simple Accountable Computing Contract for Single Task Supervision > > Let's describe a simple accountable computing contract to supervise a=20 > single > AI agent task. Our Robinson Crusoe, back to the modern civilization from= =20 > the > desert island has joined a cryptographers club of red wine hobbyists. > > Our cryptographers clubs would like to make a global search of all the=20 > existent > red wine appellations in the world (napa valley, cote-rotie, brunello,=20 > bodega > monteviejo, etc, etc). Navigating the multitude of red wine good bottles= =20 > is a > not trivial problem and our cryptographers club would like a bottle=20 > satisfying > the palates of everyone for their annual global meeting, *without*=20 > exploding > the club's budget, and with *availability* for everyone of the solution, = if > there is one existent. > =20 > Let's call this information on the best red wine the random string or=20 > solution S. > > Let's call the bitcoin denominated reward for the solution S the reward R= . > > Let's call the input data for the problem, the data D. > > In our present example, the data D can be a superset of each cryptographe= r > participants's allergy to a grape variety. Each cryptographer would like = to > keep her or his allergy private, from the other cryptographers. > =20 > Let's call the verification constraints for the solution S the constraint= s=20 > C. > > In our present example, the constraints can be the wine's year, the=20 > geographical > origin, the price, the unctuosity, the acidity, the level of sugar, etc,= =20 > etc [4] > > Let's call the script locking the reward R under the constraint C, the=20 > lock L. > > Let's call the time by when a valid random string S must be submitted T. > > The characteristics of the AI agent are not defined. Neither the model, t= he > weights, the training code, the intermediate checkpoints, the pipeline or > whatever. The AI agent is simply denoted by A, a complete black box [5]. > > Running a simple accountable computing contract for a single AI agent tas= k > supervision can be described as publishing a data D, with a reward R lock= ed > under a lock L that can be unlocked by a string S respecting the=20 > constraints > C before the expiration of a time T. > > We now describe at the high-level how this can be theoretically achieved > by using the bitcoin blockchain in a trust-minimized fashion. > =20 > The init transaction is composed of an input contributing a collateral=20 > value > from each cryptographers and a signature committing to a data-carrying=20 > annex > embedding the data D. The sum of the collateral value is the reward R.=20 > > The output of the init transaction is a simple accountable computing lock > e.g do you know a zero-knowledge proof H(X) =3D Y where H is fixed point= =20 > encoding > the constraints C for the solution S before time T. It can be translated= =20 > in bitcoin > script with OP_SHA256 OP_EQUALVERIFY OP_CHECKLOCKTIMEVERIFY etc. The=20 > output > should also have a OP_CHECKSIG with a prefixed key and SIGHASH_NONE=20 > signature. > > A lead annex can be used to encode a meta-protocol to give "open"=20 > instructions > to the AI agent based on the problems to be solved. Either fitting the=20 > whole > problem formal description as a data payload "what's weather in stockholm= =20 > tmrw" > or a more complete description e.g LOAD =20 > . > > Once the init transaction is confirmed, the problem is solvable by any > lively AI agent scanning the bitcoin blockchain and earnmarking flagged > P2TR utxo annexes to "mine" for solutions. When such annex is found, the > agent reaches Robinson's contract orchestrer, download the full problem > description and attempts to solve it. > > The AI agent computation is considered as a "black box". When a solution = is > found which can be evaluated by the agent by running H(X) =3D Y, a=20 > zero-knowledge > proof can be generated by his local prover. This zero-knowledge proof can= =20 > be > committed in the claim transaction witness and this transaction submitted= =20 > for > inclusion to the chain. > > To avoid replay of the solution by a third-party and stealing the bounty, > the zero-knowledge proof should be randomized with a nonce and the claim > scriptpubkey solving the fixed challenge. The claim transaction is also > encoding in its annex the ciphered solution under the aggregated=20 > cryptographers > public key, and the validity of the ciphered solution. > > By using the aggregated cryptographers key, they can learn the structured > output of the open problem submitted to the anonymous crowd of agents. E.= g > that the best wine to go to drink for their cryptographers meeting is a > sonoma valley 2015. > > In theory, this simple flow can be tweaked, extended, improved on any cla= ss > of problems solvable by a chain-encodable proof.=20 > > Beyond, a single ACC could be decomposed in multiple ones, e.g when the > described problem doesn't fit the AI agent token context window's size, > or decomposed horizontally to buy cycles from hardware accelerators. > =20 > ## The Open Design Questions > > There are 2 open design questions, a cryptoeconomic one and a=20 > cryptographic one. > > The crypto economic one, there is an uncertainty on the generation cost o= f > the constraints for the user group wishing to have a verifiable computati= on > done by an AI agent. For the contract to be economically interesting for= =20 > them, > the expression cost should be strictly inferior to the resolution one. > > The cryptographic one, an ACC for an open set of AI agents, is ultimately= a > conjectural "open-ended" contract built from an anyone-can-spend. Replay > and feerates races by AI agents can be a real concern, so the pre-fixed > signature of the claim transaction should commit to the witness solution > and an algebraic relationship found between the zero-knowledge and the > signature nonce-committed-in-the-annex. While a solution through multiple > rounds of bitvm is plausible, it's less elegant. > > ## An Open Market of Verifiable and Confidential Computations > > The Bitcoin blockchain is a global system for electronic transactions=20 > without > relying on trust. This system is globally accessible to anyone in the wor= ld > availing an internet connection and a basic full-node software implementi= ng > the consensus rules and inter-compatible with the rest of the peer-to-pee= r > network. > > The transaction's spending mechanism has been vetted with a programmable > locking mechanism. While this scripting mechanism has been originally > design to emulate real-world contracts, e.g bonded contracts or third-par= ty > arbitrations, using it as a mechanism to supervise AI agents has not been > well studied, from the best knowledge of this author post [6] > > On one hand, energy sources, AI models and private data sets are unevenly > distributed over the world. On the other hand, crowd of users who might > be interested in crowd-buying computations that are randomly dispersed=20 > around > the world. Leveraging the bitcoin blockchain and its scripting mechanisms > offers a unique global system to enable a AI agents-powered market for > verifiable and confidential computations, while minimizing information > asymmetries, among all the players. > > Bitcoin, tools for the people. > =20 > Cheers, > Antoine > OTS hash: 42e9891e32471101b13cf8829b6bf24f1d0ad866b1c30b40f48812a128052d4= b > > PS: Thanks to some smart kids for conversations about this subject. > > [0] For more intuitions behind this post, the author can refer to > the book "Cybernetics: Or Control and Communication in the Animal > and the Machine", Norbert Wiener, 1948. > [1] "Agency Problems and the Theory of Firms", Eugene Fama, 1980. > [2] "Accountable Computing Contracts", Bitcoin Optech. > [3] "The knowledge complexity of interactive proof systems", Shafi > Goldwasser, Silvio Micali and Charles Rackoff, 1989. > [4] This can be dubbed "The Red Wine Cryptographers Problem". It > is not scientifically demonstrated that a cryptographer dinner without > good wine is worth it. > [5] The author of this post confess he doesn't have Yann Le Cun, > Yoshua Bengio or Geoffrey Hinton's levels of mastery in the discipline > of machine learning. > [6] "Transactions and Scripts: DUP HASH160...", Satoshi Nakamoto,=20 > June 17 2010 > --=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 visit https://groups.google.com/d/msgid/bitcoindev/= 57b53aee-d46c-452b-959e-0e9645e1c45fn%40googlegroups.com. ------=_Part_16553_2075628430.1782318833161 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello,

The ideas behind this post came initially from chattin= g with researchers
on this subject at top tier universities, though fo= r the curious here the
kind of paper being used for the brainstorming = (https://dl.acm.org/doi/pdf/10.1145/3372297.3417278).

On the pur= e matter of contract protocol for AI agents being executed on the
bitc= oin blockchain, there has been some generic "blockchain" research done
at low tiered conf. Using the bitcoin blockchain for AI agent is an old id= ea [0].

I think the existent real world cryptography is too earl= y, most notably functional
homomorphic encryption, the other ask for m= ore refinement [1]. I don't have more
time to dedicate on it with back= bone dev and consenus review changes, but the
intellectual problems be= hind are fascinating, for the bored academic researchers,
of which I'm= not.

Best,
Antoine
OTS hash: 0a5e357b81f2821a53a1fa58= 05c2d78f30e638aa9710c65685c533f78ddbfc3f

[0] https://bitcointalk= .org/index.php?topic=3D53855.0
[1] https://gnusha.org/pi/bitcoindev/CA= EM=3Dy+UnxB2vKQpJAa-z-qGZQfpR1ZeW3UyuFFZ6_WTWFYGfjw@mail.gmail.com/T/?_ "Si= gning a Bitcoin Transaction with Lamport Signature..."


Le Friday, June 19, 2026 =C3=A0 7:47:51=E2=80=AFAM UTC+1, Antoine Riard= a =C3=A9crit=C2=A0:
Hi list,

With the ongoing discussions on de= fining a basic format for the
data-carrying annex accompanying P2TR spen= ds comes the question
why it would be useful for. One usage explored in = this post is to
be used as an authenticated data payload emplacement and= nonce marker
as a component of accountable computing contracts being le= veraged
for AI agents supervision [0].

## Robinson Crusoe and the= AI agent

Let's start with an exposition of the problem in isola= tion.

A random hacker, called Robinson Crusoe, has failed on a deser= t island
and he has to reinvent all the basic tools of modern life for h= is
survival. The hacker avails a single item on his desert island, a
= random AI agent application running on a crank handle powered thinkpad.
= The random AI agent, let's call it Alice, has access to the whole world=
information.

Our Robinson Crusoe would like to ask questions to = the random AI
agent, e.g "what is the easiest way to kickstart a wa= rming fire
at nights ?" or "what is the best method for desali= neating seawater?".
Robinson does not have an idea of what the _cor= rect_ AI answer looks
like, and a _wrong_ answer might be a source of ha= rm, e.g getting
sicks of drinking badly desalineated water.

Forma= lly, Robinson and Alice are playing a game, where the question
cost is m= easured by the scarce sun energy to power Alice and Robinson
has time-bo= unded constraints to get correct information or "knowledge"
to= the practical survival problems Robinson is facing.

There is a non-= null cost in turning the crank to submit prompts to
Alice and ideally, R= ob would like to only turn the crank to power Alice
only if Alice is abl= e to provide a _correct_ answer to the submitted
prompts. There might be= a halting problem where Alice is not even able
to provide a _correct_ a= nswer limited by the model performance.

Robinson and Alice are stuck= in a noteworthy information asymmetry,
such as asymmetry being measurab= le from Robinson's subjective viewpoint
on an energy scale.

#= # The principal-agent relationship and the "fronting" user-agent = problem

In the discipline of economics, the problem of principal-age= nt
relations is a well-studied issue [1].=C2=A0 Basically, any large soc= ial
organization can know incentives problems due to the structural
d= issociation between the organization managers and the beneficiaries
of t= he organization results e.g the shareholders.


There is a concern= in the incentives problems for the agents operating
in the best interes= t of the principals, e.g that they are maximizing
the benefice yielded b= y their managements of the social organization.

Translated in the wo= rld of AI agents, human users are "fronting"
tokens for a solu= tion of which the correctness is uncertain bearing
the sole risks of an = AI agent token cost processing. In a more ideal
setup, human users would= only pay an AI agent cost *if the solution
is correct*, the AI agent be= aring the cost of imprecise solutions,
or even more the AI agent being p= ut in an open competition between
them to "mine" a solution.=C2=A0
Accessory to the "fronting cost" of acquiring verifie= d computations
from a crowd of AI agents, a group of principals would li= ke to acquire
the verified computation with the minimal sharing of confi= dential
information. E.g the AI agent execution might be influenced by t= he
"knowledge" of the user raw information.

In the foll= owing sections, we conjecture a simple protocol bringing
a solution to t= his AI agent "fronting" cost problem leveraging the
bitcoin bl= ockchain and its scripting mechanism, and minimize AI
structured outputs= being a market of "lemons".


## The list of cryptograp= hic and bitcoin primitives

The taproot annex. With the introduction = of the taproot output type
an unspecified consensus field embedded as th= e last of the witness
element and starting by the marker 0x50. It can be= present or absent
in the witness, however this information is committed= in the transaction
digest.

The class of construction known as ac= countable computing contracts [2].
While there are multiple ways to do i= t, basically an ACC it's a payment
that can only be executed if the = receiving party verifiably run a specified
function on a specified set o= f inputs.

A functional homomorphic encryption cryptosystem. A FHE is= a a kind of
cryptosystem allowing to perform functions on the encrypted= data without
first having to decrypt it.

A zero-knowlewdge crypt= osystem. A zero-knowledge cryptosystem is a
protocol in which one party = can prove to another party that some random
statement in a defined langu= age is true, without conveying any additional
information beyond the mer= e fact of the statement truth [3].

A contract orchestrer or watchtow= er system, to provide complete ample
data payloads or timeout the ACC af= ter a defined duration.

## A Simple Accountable Computing Contract f= or Single Task Supervision

Let's describe a simple accountable c= omputing contract to supervise a single
AI agent task. Our Robinson Crus= oe, back to the modern civilization from the
desert island has joined a = cryptographers club of red wine hobbyists.

Our cryptographers clubs = would like to make a global search of all the existent
red wine appellat= ions in the world (napa valley, cote-rotie, brunello, bodega
monteviejo,= etc, etc). Navigating the multitude of red wine good bottles is a
not t= rivial problem and our cryptographers club would like a bottle satisfyingthe palates of everyone for their annual global meeting, *without* explod= ing
the club's budget, and with *availability* for everyone of the s= olution, if
there is one existent.
=C2=A0
Let's call this info= rmation on the best red wine the random string or solution S.

Let= 9;s call the bitcoin denominated reward for the solution S the reward R.
Let's call the input data for the problem, the data D.

In o= ur present example, the data D can be a superset of each cryptographer
p= articipants's allergy to a grape variety. Each cryptographer would like= to
keep her or his allergy private, from the other cryptographers.
= =C2=A0
Let's call the verification constraints for the solution S th= e constraints C.

In our present example, the constraints can be the = wine's year, the geographical
origin, the price, the unctuosity, the= acidity, the level of sugar, etc, etc [4]

Let's call the script= locking the reward R under the constraint C, the lock L.

Let's = call the time by when a valid random string S must be submitted T.

T= he characteristics of the AI agent are not defined. Neither the model, the<= br>weights, the training code, the intermediate checkpoints, the pipeline o= r
whatever. The AI agent is simply denoted by A, a complete black box [5= ].

Running a simple accountable computing contract for a single AI a= gent task
supervision can be described as publishing a data D, with a re= ward R locked
under a lock L that can be unlocked by a string S respecti= ng the constraints
C before the expiration of a time T.

We now de= scribe at the high-level how this can be theoretically achieved
by using= the bitcoin blockchain in a trust-minimized fashion.
=C2=A0 =C2=A0
T= he init transaction is composed of an input contributing a collateral value=
from each cryptographers and a signature committing to a data-carrying = annex
embedding the data D. The sum of the collateral value is the rewar= d R.

The output of the init transaction is a simple accountable com= puting lock
e.g do you know a zero-knowledge proof H(X) =3D Y where H is= fixed point encoding
the constraints C for the solution S before time T= . It can be translated in bitcoin
script =C2=A0with OP_SHA256 OP_EQUALVE= RIFY OP_CHECKLOCKTIMEVERIFY etc. The output
should also have a OP_CHECKS= IG with a prefixed key and SIGHASH_NONE signature.

A lead annex can = be used to encode a meta-protocol to give "open" instructions
= to the AI agent based on the problems to be solved. Either fitting the whol= e
problem formal description as a data payload "what's weather = in stockholm tmrw"
or a more complete description e.g LOAD <hype= rlink_to_full_desc> <commitment_desc>.

Once the init transa= ction is confirmed, the problem is solvable by any
lively AI agent scann= ing the bitcoin blockchain and earnmarking flagged
P2TR utxo annexes to = "mine" for solutions. When such annex is found, the
agent reac= hes Robinson's contract orchestrer, download the full problem
descri= ption and attempts to solve it.

The AI agent computation is consider= ed as a "black box". When a solution is
found which can be eva= luated by the agent by running H(X) =3D Y, a zero-knowledge
proof can be= generated by his local prover. This zero-knowledge proof can be
committ= ed in the claim transaction witness and this transaction submitted for
i= nclusion to the chain.

To avoid replay of the solution by a third-pa= rty and stealing the bounty,
the zero-knowledge proof should be randomiz= ed with a nonce and the claim
scriptpubkey solving the fixed challenge. = The claim transaction is also
encoding in its annex the ciphered solutio= n under the aggregated cryptographers
public key, and the validity of th= e ciphered solution.

By using the aggregated cryptographers key, the= y can learn the structured
output of the open problem submitted to the a= nonymous crowd of agents. E.g
that the best wine to go to drink for thei= r cryptographers meeting is a
sonoma valley 2015.

In theory, this= simple flow can be tweaked, extended, improved on any class
of problems= solvable by a chain-encodable proof.

Beyond, a single ACC could be= decomposed in multiple ones, e.g when the
described problem doesn't= fit the AI agent token context window's size,
or decomposed horizon= tally to buy cycles from hardware accelerators.
=C2=A0
## The Open De= sign Questions

There are 2 open design questions, a cryptoeconomic o= ne and a cryptographic one.

The crypto economic one, there is an unc= ertainty on the generation cost of
the constraints for the user group wi= shing to have a verifiable computation
done by an AI agent. For the cont= ract to be economically interesting for them,
the expression cost should= be strictly inferior to the resolution one.

The cryptographic one, = an ACC for an open set of AI agents, is ultimately a
conjectural "o= pen-ended" contract built from an anyone-can-spend. Replay
and feer= ates races by AI agents can be a real concern, so the pre-fixed
signatur= e of the claim transaction should commit to the witness solution
and an = algebraic relationship found between the zero-knowledge and the
signatur= e nonce-committed-in-the-annex. While a solution through multiple
rounds= of bitvm is plausible, it's less elegant.

## An Open Market of = Verifiable and Confidential Computations

The Bitcoin blockchain is a= global system for electronic transactions without
relying on trust. Thi= s system is globally accessible to anyone in the world
availing an inter= net connection and a basic full-node software implementing
the consensus= rules and inter-compatible with the rest of the peer-to-peer
network.
The transaction's spending mechanism has been vetted with a progr= ammable
locking mechanism. While this scripting mechanism has been origi= nally
design to emulate real-world contracts, e.g bonded contracts or th= ird-party
arbitrations, using it as a mechanism to supervise AI agents h= as not been
well studied, from the best knowledge of this author post [6= ]

On one hand, energy sources, AI models and private data sets are u= nevenly
distributed over the world. On the other hand, crowd of users wh= o might
be interested in crowd-buying computations that are randomly dis= persed around
the world. Leveraging the bitcoin blockchain and its scrip= ting mechanisms
offers a unique global system to enable a AI agents-powe= red market for
verifiable and confidential computations, while minimizin= g information
asymmetries, among all the players.

Bitcoin, tools = for the people.
=C2=A0
Cheers,
Antoine
OTS hash: 42e9891e324711= 01b13cf8829b6bf24f1d0ad866b1c30b40f48812a128052d4b

PS: Thanks to som= e smart kids for conversations about this subject.

[0] For more intu= itions behind this post, the author can refer to
the book "Cybernet= ics: Or Control and Communication in the Animal
and the Machine", N= orbert Wiener, 1948.
[1] "Agency Problems and the Theory of Firms&q= uot;, Eugene Fama, 1980.
[2] "Accountable Computing Contracts"= , Bitcoin Optech.
[3] "The knowledge complexity of interactive proo= f systems", Shafi
Goldwasser, Silvio Micali and Charles Rackoff, 19= 89.
[4] This can be dubbed "The Red Wine Cryptographers Problem&quo= t;. It
is not scientifically demonstrated that a cryptographer dinner wi= thout
good wine is worth it.
[5] The author of this post confess he d= oesn't have Yann Le Cun,
Yoshua Bengio or Geoffrey Hinton's leve= ls of mastery in the discipline
of machine learning.
[6] "Transa= ctions and Scripts: DUP HASH160...", Satoshi Nakamoto,
June 17 201= 0

--
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 visit https://groups.google.com/d/msgid/bitcoind= ev/57b53aee-d46c-452b-959e-0e9645e1c45fn%40googlegroups.com.
------=_Part_16553_2075628430.1782318833161-- ------=_Part_16552_1040528924.1782318833161--