On Tue, Mar 07, 2023 at 10:45:34PM +1000, Anthony Towns via bitcoin-dev wrote: > I think there are perhaps four opcodes that are interesting in this class: > > idx sPK OP_FORWARD_TARGET > -- sends the value to a particular output (given by idx), and > requires that output have a particular scriptPubKey (given > by sPK). > > idx [...] n script OP_FORWARD_LEAF_UPDATE > -- sends the value to a particular output (given by idx), and > requires that output to have almost the same scriptPubKey as this > input, _except_ that the current leaf is replaced by "script", > with that script prefixed by "n" pushes (of values given by [...]) > > idx OP_FORWARD_SELF > -- sends the value to a particular output (given by idx), and > requires that output to have the same scriptPubKey as this input > > amt OP_FORWARD_PARTIAL > -- modifies the next OP_FORWARD_* opcode to only affect "amt", > rather than the entire balance. opcodes after that affect the > remaining balance, after "amt" has been subtracted. if "amt" is > 0, the next OP_FORWARD_* becomes a no-op.
The BIP 345 draft has been updated [0] [1] and now pretty much defines OP_VAULT to have the behaviour specced for OP_FORWARD_LEAF_UPDATE above, and OP_VAULT_RECOVER to behave as OP_FORWARD_TARGET above. Despite that, for this email I'm going to continue using the OP_FORWARD_* naming convention. Given the recent controversy over the Yuga labs ordinal auction [2], perhaps it's interesting to consider that these proposed opcodes come close to making it possible to do a fair, non-custodial, on-chain auction of ordinals [3]. The idea here is that you create a utxo on chain that contains the ordinal in question, which commits to the address of the current leading bidder, and can be spent in two ways: 1) it can be updated to a new bidder, if the bid is raised by at least K satoshis, in which case the previous bidder is refunded their bid; or, 2) if there have been no new bids for a day, the current high bidder wins, and the ordinal is moved to their address, while the funds from their winning bid are sent to the original vendor's address. I believe this can be implemented in script as follows, assuming the opcodes OP_FORWARD_TARGET(OP_VAULT_RECOVER), OP_FORWARD_LEAF_UPDATE(OP_VAULT), OP_FORWARD_PARTIAL (as specced above), and OP_PUSHCURRENTINPUTINDEX (as implemented in liquid/elements [4]) are all available. First, figure out the parameters: * Set VENDOR to the scriptPubKey corresponding to the vendor's address. * Set K to the minimum bid increment [5]. * Initially, set X equal to VENDOR. * Initially, set V to just below the reserve price (V+K is the minimum initial bid). Then construct the following script: [X] [V] [SSS] TOALT TOALT TOALT 0 PUSHCURRENTINPUTINDEX EQUALVERIFY DEPTH NOT IF 0 10000 FORWARD_PARTIAL 0 FROMALT FORWARD_TARGET 1 [VENDOR] FWD_TARGET 144 ELSE FROMALT SWAP TUCK FROMALT [K] ADD GREATERTHANOREQUAL VERIFY 1 SWAP FORWARD_TARGET DUP FORWARD_PARTIAL 0 ROT ROT FROMALT DUP 3 SWAP FORWARD_LEAF_UPDATE 0 ENDIF CSV 1ADD where "SSS" is a pushdata of the rest of the script ("TOALT TOALT TOALT .. 1ADD"). Finally, make that script the sole tapleaf, accompanied by a NUMS point as the internal public key, calculate the taproot address corresponding to that, and send the ordinal to that address as the first satoshi. There are two ways to spend that script. With an empty witness stack, the following will be executed: [X] [V] [SSS] TOALT TOALT TOALT -- altstack now contains [SSS V X] 0 PUSHCURRENTINPUTINDEX EQUALVERIFY -- this input is the first, so the ordinal will move to the first output DEPTH NOT IF -- take this branch: the auction is over! 1 [VENDOR] FWD_TARGET -- output 1 gets the entire value of this input, and pays to the vendor's hardcoded scriptPubKey 0 10000 FORWARD_PARTIAL 0 FROMALT FORWARD_TARGET -- we forward at least 10k sats to output 0 (if there were 0 sats, the ordinal would end up in output 1 instead, which would be a bug), and output 0 pays to scriptPubKey "X" 144 ELSE .. ENDIF -- skip over the other branch CSV -- check that this input has baked for 144 blocks (~1 day) 1ADD -- leave 145 on the stack, which is true. success! Alternatively, if you want to increase the bid you provide a stack with two items: your scriptPubKey and the new bid [X' V']. Execution this time looks like: [X] [V] [SSS] TOALT TOALT TOALT -- stack contains [X' V'], altstack now contains [SSS V X] 0 PUSHCURRENTINPUTINDEX EQUALVERIFY -- this input is the first, so the ordinal will move to the first output DEPTH NOT IF ... ELSE -- skip over the other branch (without violating minimalif rules) FROMALT SWAP TUCK FROMALT -- stack contains [X' V' X V' V], altstack contains [SSS] [K] ADD GREATERTHANOREQUAL VERIFY -- check V' >= V+K, stack contains [X' V' X] 1 SWAP FORWARD_TARGET -- output 1 pays to X (previous bidder's scriptPubKey), and the entire value of this input goes there; stack contains [X' V'] DUP FORWARD_PARTIAL -- execute "V' FORWARD_PARTIAL", stack contains [X' V'] 0 ROT ROT -- stack contains [0 X' V'] FROMALT DUP 3 SWAP FORWARD_LEAF_UPDATE -- execute "0 X' V' SSS 3 SSS FORWARD_LEAF_UPDATE" which checks that output 0 spends at least V' satoshis back to the same script (because that's how we defined SSS), except the first three pushes (previously X V SSS) are replaced by X' V' SSS. 0 ENDIF CSV -- "0 CSV" requires nSequnce to be set, which makes the tx rbf'able, which hopefully makes it harder to pin 1ADD -- ends with 1 on the stack; success! (The "SSS n SSS FORWARD_LEAF_UPDATE" construct is more or less a quine, ie a program that outputs its own source code) I think that script is about 211 witness bytes, with an additional 40 witness bytes for X'/V', so when making a bid, your tx would be something like: tx header, 10vb input 0: 103vb for the old bid including witness and control block input 1: 58vb for a taproot key path spend output 0: 43vb for the new bid output 1: 43vb for your change for a total of about 257vb -- slightly larger than a regular 2-in-2-out transaction, but not terribly much. Mostly because input 0 doesn't require a signature -- it's size is effectively 6 pubkeys: X, X' VENDOR twice, and the script code twice, along with a little extra to encode the various numbers (10000, 144, K, V, V'). This approach seems pretty "MEV" resistant: you pay fees via input 1 if your bid succeeds; if it doesn't, you don't pay any fees. A potential scalper might want to put in an early low ball bid, then prevent higher bidders from winning the auction, take control of the ordinal, and resell it later, but unless they can prevent another miner from mining alternative bids for 144 blocks, they will fail at that. The bid is fixed by the bidder and committed to by the signature on input 1, so frontrunning a bid can't do anything beyond invalidate the bid entirely. Obviously, this is a pretty limited auction mechanism in various ways; eg maybe you'd rather specify K as a percentage than an absoute increment; maybe you'd like to have the auction definitely finish by some particular time; maybe you'd like to be able to have the auction be able to continue above 21.47 BTC (2**31 sats); maybe you'd like to do a dutch auction rather than an english auction. I think you can probably do all those things with this set of opcodes and clever scripting, though it probably gets ugly. I don't think this is easily extensible to taro or rgb style assets, as rather than being able to ensure the asset is transferred by controlling the input/output positions, I think you'd need to build up merkle trees and do point tweaks beyond what's supported by OP_FORWARD_LEAF_UPDATE/OP_VAULT. Of course, without something like OP_PUSHCURRENTINPUTINDEX I don't think you could do it for ordinals either. Cheers, aj [0] https://github.com/bitcoin/bips/blob/7f747fba82675f28c239df690a07b75529bd0960/bip-0345.mediawiki [1] https://twitter.com/jamesob/status/1639019107432513537 [2] https://cointelegraph.com/news/scammers-dream-yuga-s-auction-model-for-bitcoin-nfts-sees-criticism [3] Inscriptions remain a wasteful way of publishing/committing to content, however! [4] https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md [5] Setting K too low probably invites griefing, where a bidder may be able to use rbf pinning vectors to prevent people who would be willing to bid substantially higher from getting their bid confirmed on chain. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev