I built some tooling a while ago in Rust, but it's kind of a mess.

I write them using the bitcoin-cash crate, which as a feature tracks the preimages of hashes and names of bytestrings, and then run that in iguana.

Here's a basic example: https://github.com/be-cash/iguana/blob/master/examples/p2reversepk/src/main.rs

While the basic idea is super cool and it works quite well for me, it's not easy to use IMO, and requires a lot of flaky setup.

However, I think now that we have ecash-lib, we could think about doing this in the future:

• Adding a mode that traces preimages of hashes + the ability to name byte slices
• Adding a DSL or so that describes Scripts with named stack items
• Adding a Script interpreter that uses ecash-lib
• Moving Iguana over to ecash-lib so it can be run with a simple npm install
• Adding a playground mode to iguana so people can write scripts in there super quickly

Maybe we can hire Rosco Kalis for some of these? He's built CashScript (which I never use), but it's super cool and relatively easy to use. Not sure if he'd come to the "dark side" though, so to speak.

No; it's only required for the contract here, because we enforce the first two outputs here, and the third one can be filled in by the buyer, which is the one the NFT is sent to via the OP_RETURN.

Not sure if that makes a ton of sense but that's the "magic" of the Script

the complexity is such that I don't think "lack of simple tools" is the main problem

Even today, ETH maintains a high level of complexity -- yet still manages to attract large teams of talented developers. sometimes they even manage to write contracts that aren't hacked.

imo we need to focus on making the value proposition of new tech discoveries on utxo blockchains extremely clear. Devs come to ETH bc that's where the funding is. The funding is there bc that's where the trading activity is. The trading activity is there because there is a very clear "what's in it for me" for both buyers (traders) and sellers (liquidity providers / stakers).

So, we need to have a clear "what's in it for me" to traders. This is a good first step, since people like to quickly and easily create NFTs, and I think it's a safe assumption they would like this even more if they could also sell them.

Getting a uniswap-esque experience -- allowing users to make markets by providing liquidity in a trading pair -- would be another major win. The uniswap experience is quite complex, unreliable, can result in wild swings and losses -- and yet it still dominates the market and on many days exceeds $1 billion in volume.

Not sure exactly why we're using the term covenant, but basically a covenant is a contract that doesn't need to be enforced by an authority, it simply becomes void once one party violates it.

I guess it's similar enough to Script, where the transaction gets rejected if one party violates it, or like in many more BTC-esque Scripts like a Hash-Timelock-Contract where if one party violates the terms, the other party can still recover the funds, without needing an arbiter.

I use "covenant" for everything Script related these days, partially because it sounds hip and based and "smart contract" sounds lame and cringe.

Also, we really wanna avoid legal misunderstandings, in two ways:

• These are not actual contracts that have any legal binding, they're just smart locks on your UTXOs
• FinCEN considers smart contracts like virtual ATMs, so they can do unlicensed money transmission if used inproperly, as the TornadoCash situation shows.

Bitcoin's "contracts" are fundamentally different from ETH's, esp. legally speaking; so I think using a different term seems like a good idea.

tbh kinda fun to see you reverse-engineering this whole thing over time, I actually that's the best way to transfer this knowledge

Yes, it gets rejected by the network, it violates consensus rules. The idea behind Agora is to write a Script in such a way that any tx that doesn't send the correct amounts to the correct parties is invalid in the "consensus rule" term.

Here, we use OP_EQUALVERIFY, which verifies that the actual outputs that are in the transaction match the ones the seller wants them to be—which translates to "buyer has to send seller X amount of XEC for these tokens".

I can go into more detail in the test, README or doc comments of AgoraOneshot if you'd like

README pls