Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2023-03-24 🗒️ Summary of this message: A proposed ...
📅 Original date posted:2023-03-24
🗒️ Summary of this message: A proposed update to Bitcoin's scripting language includes new opcodes for conditional transactions. These could enable non-custodial, on-chain auctions of ordinals.
📝 Original message: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.
🗒️ Summary of this message: A proposed update to Bitcoin's scripting language includes new opcodes for conditional transactions. These could enable non-custodial, on-chain auctions of ordinals.
📝 Original message: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.