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 
(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 
idea [0].

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

Best,
Antoine
OTS hash: 0a5e357b81f2821a53a1fa5805c2d78f30e638aa9710c65685c533f78ddbfc3f

[0] https://bitcointalk.org/index.php?topic=53855.0
[1] 
https://gnusha.org/pi/bitcoindev/CAEM=y+UnxB2vKQpJAa-z-qGZQfpR1ZeW3UyuFFZ6_WTWFYGfjw@mail.gmail.com/T/?_ 
"Signing a Bitcoin Transaction with Lamport Signature..."


Le Friday, June 19, 2026 à 7:47:51 AM UTC+1, Antoine Riard a écrit :

> 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.
>  
> 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 specified
> 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 
> single
> AI agent task. Our Robinson Crusoe, 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 appellations in the world (napa valley, cote-rotie, brunello, 
> bodega
> monteviejo, etc, etc). Navigating the multitude of red wine good bottles 
> is a
> not trivial problem and our cryptographers club would like a bottle 
> satisfying
> the palates of everyone for their annual global meeting, *without* 
> exploding
> the club's budget, and with *availability* for everyone of the solution, if
> there is one existent.
>  
> Let's call this information on the best red wine the random string or 
> 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 cryptographer
> participants's allergy to a grape variety. Each cryptographer would like to
> keep her or his allergy private, from the other cryptographers.
>  
> Let's call the verification constraints for the solution S the 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.
>
> The characteristics of the AI agent are not defined. Neither the model, the
> 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 task
> supervision can be described as publishing a data D, with a reward R locked
> under a lock L that can be unlocked by a string S respecting the 
> 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.
>    
> The 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 reward R. 
>
> The output of the init transaction is a simple accountable computing lock
> e.g do you know a zero-knowledge proof H(X) = Y where H is fixed point 
> encoding
> the constraints C for the solution S before time T. It can be translated 
> in bitcoin
> script  with OP_SHA256 OP_EQUALVERIFY OP_CHECKLOCKTIMEVERIFY etc. The 
> output
> should also have a OP_CHECKSIG 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 
> whole
> problem formal description as a data payload "what's weather in stockholm 
> tmrw"
> or a more complete description e.g LOAD <hyperlink_to_full_desc> 
> <commitment_desc>.
>
> 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) = Y, a 
> zero-knowledge
> proof can be generated by his local prover. This zero-knowledge proof can 
> be
> committed in the claim transaction witness and this transaction submitted 
> 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 
> 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 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 horizontally to buy cycles from hardware accelerators.
>  
> ## The Open Design Questions
>
> There are 2 open design questions, a cryptoeconomic one and a 
> cryptographic one.
>
> The crypto economic one, there is an uncertainty on the generation cost of
> the constraints for the user group wishing to have a verifiable computation
> done by an AI agent. For the contract 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 "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 
> without
> relying on trust. This system is globally accessible to anyone in the world
> availing an internet 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 programmable
> locking mechanism. While this scripting mechanism has been originally
> design to emulate real-world contracts, e.g bonded contracts or third-party
> 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 
> 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.
>  
> Cheers,
> Antoine
> OTS hash: 42e9891e32471101b13cf8829b6bf24f1d0ad866b1c30b40f48812a128052d4b
>
> 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, 
> June 17 2010
>

-- 
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/57b53aee-d46c-452b-959e-0e9645e1c45fn%40googlegroups.com.