path: root/98/8a757b29e0d61a6193dbed8372a4bd2ad8fd0f

Return-Path: <aj@erisian.com.au>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 67D36C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 24 Mar 2023 12:10:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 50230615E9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 24 Mar 2023 12:10:21 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 50230615E9
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ifWTmanlKfth
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 24 Mar 2023 12:10:20 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org DBBA4615DE
Received: from cerulean.erisian.com.au (azure.erisian.com.au [172.104.61.193])
 by smtp3.osuosl.org (Postfix) with ESMTPS id DBBA4615DE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 24 Mar 2023 12:10:19 +0000 (UTC)
Received: from 60.42.96.58.static.exetel.com.au ([58.96.42.60]
 helo=sapphire.erisian.com.au)
 by cerulean.erisian.com.au with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2)
 (envelope-from <aj@erisian.com.au>)
 id 1pfgFG-0003CG-9M; Fri, 24 Mar 2023 22:10:15 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
 Fri, 24 Mar 2023 22:10:05 +1000
Date: Fri, 24 Mar 2023 22:10:05 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZB2THW3WT2wiU7Ni@erisian.com.au>
References: <CAPfvXfJQKb7i8GBvTEvTTz-3dU_5mH8jOv8Nm4Q8gPt=KxrqLQ@mail.gmail.com>
 <CAB3F3DveCDz6yy-rd3ttV8+4sMufsvB+9J-qVK95yh9aLYX+Mw@mail.gmail.com>
 <ZAAqIZZO1KK32Th9@erisian.com.au>
 <CAB3F3DtGpVHkyT_=KLS42rvdP=dgnMvChhR1Rs0BHO5yOEabmw@mail.gmail.com>
 <CAPfvXf+4iX0h-nSuyTai_VvJHkDvAyKtgSk6DsaEwE8N3wnYEg@mail.gmail.com>
 <ZAcx7oEZxC9BiWvg@erisian.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZAcx7oEZxC9BiWvg@erisian.com.au>
X-Spam_score: -1.0
X-Spam_bar: -
Cc: Greg Sanders <gsanders87@gmail.com>
Subject: Re: [bitcoin-dev] BIP for OP_VAULT
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Mar 2023 12:10:21 -0000

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.