Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8EC1EC002F for ; Thu, 30 Mar 2023 10:39:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 56C5E60B06 for ; Thu, 30 Mar 2023 10:39:55 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 56C5E60B06 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=XMFOjg8z X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 7kT4YhoiukQe for ; Thu, 30 Mar 2023 10:39:53 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 44A3A60AF0 Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) by smtp3.osuosl.org (Postfix) with ESMTPS id 44A3A60AF0 for ; Thu, 30 Mar 2023 10:39:53 +0000 (UTC) Received: by mail-yb1-xb34.google.com with SMTP id e65so22798963ybh.10 for ; Thu, 30 Mar 2023 03:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680172792; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=TqYRwaODfWDI06Q58hQVztQbAPPbCiv4GB7G+C0yHa0=; b=XMFOjg8zkjoN69rU9lU60afKu8iGYZRtNrH2gE8j5Ee9lwmAQuQWZ/TqahkTDdd216 v9vjpGGyZMT7k0P6h9wuDOI6AWphppTLWZw7Jb9r7ELv9yHO2koEUJjM5ybKZ6yozGve G24e2j7D7pz/p0mQXz/n1BOQHbccDi6sWE4sTQzrP32qPJU+1fiuMiTPRz72/TgVKvUW m2YAhRXJ5y9+HPQOOjnAYP8Os1QNKWOYob1JAAPNBdR4WcDsDfaMOEM7apbYjebOb5mj FxNg2mFMvUiAcMxu5ZvP0W/sthiX5KflPSOabNGs4NxRjGh/0Ey3qKU/Z9FG4nw0xsrg Ulwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680172792; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TqYRwaODfWDI06Q58hQVztQbAPPbCiv4GB7G+C0yHa0=; b=iHaCbwdI4eImfRRq6ZZj8OCk/lMf16hZGonxc8G3p6actdrDf2Obe9bEslERfX2pvm UohyqAXEazTfEs9w/ruzW4krutNWC3usM1XiV4SZfZhVJL7MFFDEMrs1cqbsAKKMSppy KDW1CxVzeEt4TNpZUCuO7Y5I3mhRVu8sU/0rVe/L/u+46y3x/dnR5qezsKOv1tijqHW7 PZ4JOhpiCwxJO1h1JnVBnqqLR/rVjuD6sJP5IKPpsQ9aOYw7niv1ynuznxSbVQ9gfhG5 qg8voMJ8T310kKR1hi/vZ9Ef2Q536Ax/ajxe4LbJwk1/AwAuA/o9MjQYQMLC4i/OaWQ+ r/sw== X-Gm-Message-State: AAQBX9f8HsmvBLHJNiBesjACXpC0NbFfQFnqGlJWLWsC0uAm56+MRmJy PSIWOctCEAUV1Dsd+Xzj0FPw3sVerrVOraGX6HM= X-Google-Smtp-Source: AKy350btrrwoBSJ5/QahRcHfEkSi1Y1BIrJPiyIYmSV4W0Vha+t2gS+b45tdjphFVxD0TsWrRQ7bv0pkJJSdkhSUBO0= X-Received: by 2002:a05:6902:102b:b0:b46:4a5e:3651 with SMTP id x11-20020a056902102b00b00b464a5e3651mr14738697ybt.9.1680172792014; Thu, 30 Mar 2023 03:39:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Zac Greenwood Date: Thu, 30 Mar 2023 18:39:40 +0800 Message-ID: To: alicexbt Content-Type: multipart/alternative; boundary="0000000000006deb2d05f81bb69d" X-Mailman-Approved-At: Fri, 31 Mar 2023 09:54:10 +0000 Cc: Bitcoin Protocol Discussion , Anthony Towns 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2023 10:39:55 -0000 --0000000000006deb2d05f81bb69d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi alicexbtc, Under no circumstance should Bitcoin add any functionality intended to support private businesses that rely on on-chain storage for their business model. Regarding =E2=80=9CFees paid: 150 BTC=E2=80=9D (uh, *citation needed*): To optimize for profitability a business would generally attempt to operate using zero- or low-fee transactions. Therefore they tend to contribute comparatively little fees but are depriving public use of these cheap transactions. Worse, they exert a constant upward pressure on fee levels, making it more expensive for everyone else to transact. Unlike miners, node operators do not receive any compensation. They however incur additional cost for bandwidth, electricity and processing time to not only support some current business but all businesses in the past that ever tried to turn a profit at their expense, so also after such business failed and has been long gone. They foot the bill. Lastly, I don=E2=80=99t believe there is any value in having for instance O= rdinals spam the blockchain with images of wojaks, bored apes and other crap but perhaps you wish to clarify why this might be something to be =E2=80=9Cexci= ted about=E2=80=9D. Your other arguments are nonsensical so excuse me for ignoring them. Zac On Thu, 30 Mar 2023 at 03:57, alicexbt wrote: > Hi Zac, > > Let me share what those parasites achieved: > > - Fees paid: 150 BTC > - Lot of users and developers trying bitcoin that either never tried or > gave up early in 2013-15 > - Mempools of nodes of being busy on weekends and got lots of transaction= s > - PSBT became cool and application devs are trying their best to use it i= n > different ways > - Some developers exploring taproot and multisig > - AJ shared things how covenants could help in fair, non-custodial, > on-chain auction of ordinals that is MEV resistant although I had shared = it > earlier which involves more steps: > https://twitter.com/1440000bytes/status/1634368411760476161 > - Investors exploring about funding projects > - Bitcoin more than Bitcoin and people excited about it > > We can have difference of opinion, however I want bitcoin to be money and > money means different things for people in this world. Please respect tha= t > else it will become like Linux, something used by 1% of world. > > /dev/fd0 > floppy disk guy > > Sent with Proton Mail secure email. > > ------- Original Message ------- > On Wednesday, March 29th, 2023 at 12:40 PM, Zac Greenwood via bitcoin-dev= < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > I=E2=80=99m not sure why any effort should be spent on theorizing how n= ew > opcodes might be used to facilitate parasitical use cases of the blockcha= in. > > > > If anything, business models relying on the ability to abuse the > blockchain as a data store must be made less feasible, not more. > > > > Zac > > > > > > On Fri, 24 Mar 2023 at 20:10, Anthony Towns via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > > 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 define= s > > > 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 leas= t > > > 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 addres= s. > > > * 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 TOA= LT > > > .. 1ADD"). > > > > > > Finally, make that script the sole tapleaf, accompanied by a NUMS poi= nt > > > as the internal public key, calculate the taproot address correspondi= ng > > > 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 wi= th > > > 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' >=3D 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 quin= e, > > > 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-o= ut > > > 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 b= id > > > 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/7f747fba82675f28c239df690a07b75529bd= 0960/bip-0345.mediawiki > > > > > > [1] https://twitter.com/jamesob/status/1639019107432513537 > > > > > > [2] > https://cointelegraph.com/news/scammers-dream-yuga-s-auction-model-for-bi= tcoin-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_opc= odes.md > > > > > > [5] Setting K too low probably invites griefing, where a bidder may b= e > > > able to use rbf pinning vectors to prevent people who would be willin= g > > > 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 > --0000000000006deb2d05f81bb69d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi alicexbtc,

Under no circumstance should Bitcoin add any functionality int= ended to support private businesses that rely on on-chain storage for their= business model.=C2=A0

R= egarding =E2=80=9CFees paid: 150 BTC=E2=80=9D (uh, *citation needed*):

To optimize for profitabilit= y a business would generally attempt to operate using zero- or low-fee tran= sactions. Therefore they tend to contribute =C2=A0comparatively little fees= but are depriving public use of these cheap transactions. Worse, they exer= t a constant upward pressure on fee levels, making it more expensive for ev= eryone else to transact.

Unlike miners, node operators do not receive any compensation. They howeve= r incur additional cost for bandwidth, electricity and processing time to n= ot only support some current business but all businesses in the past that e= ver tried to turn a profit at their expense, so also after such business fa= iled and has been long gone. They foot the bill.
Lastly, I don=E2=80=99t believe there is any value= in having for instance Ordinals spam the blockchain with images of wojaks,= bored apes and other crap but perhaps you wish to clarify why this might b= e something to be =E2=80=9Cexcited about=E2=80=9D.
<= br>
Your other arguments are nonsensical so excuse m= e for ignoring them.


Zac

=

O= n Thu, 30 Mar 2023 at 03:57, alicexbt <alicexbt@protonmail.com> wrote:
Hi Zac,

Let me share what those parasites achieved:

- Fees paid: 150 BTC
- Lot of users and developers trying bitcoin that either never tried or gav= e up early in 2013-15
- Mempools of nodes of being busy on weekends and got lots of transactions<= br> - PSBT became cool and application devs are trying their best to use it in = different ways
- Some developers exploring taproot and multisig
- AJ shared things how covenants could help in fair, non-custodial, on-chai= n auction of ordinals that is MEV resistant although I had shared it earlie= r which involves more steps: https://twit= ter.com/1440000bytes/status/1634368411760476161
- Investors exploring about funding projects
- Bitcoin more than Bitcoin and people excited about it

We can have difference of opinion, however I want bitcoin to be money and m= oney means different things for people in this world. Please respect that e= lse it will become like Linux, something used by 1% of world.

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, March 29th, 2023 at 12:40 PM, Zac Greenwood via bitcoin-dev &= lt;bitcoin-dev@lists.linuxfoundation.org> wrote:


> I=E2=80=99m not sure why any effort should be spent on theorizing how = new opcodes might be used to facilitate parasitical use cases of the blockc= hain.
>
> If anything, business models relying on the ability to abuse the block= chain as a data store must be made less feasible, not more.
>
> Zac
>
>
> On Fri, 24 Mar 2023 at 20:10, Anthony Towns via bitcoin-dev <bitcoi= n-dev@lists.linuxfoundation.org> wrote:
>
> > On Tue, Mar 07, 2023 at 10:45:34PM +1000, Anthony Towns via bitco= in-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), an= d
> > > 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), an= d
> > > requires that output to have almost the same scriptPubKey as= this
> > > input, _except_ that the current leaf is replaced by "s= cript",
> > > 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), an= d
> > > requires that output to have the same scriptPubKey as this i= nput
> > >
> > > amt OP_FORWARD_PARTIAL
> > > -- modifies the next OP_FORWARD_* opcode to only affect &quo= t;amt",
> > > rather than the entire balance. opcodes after that affect th= e
> > > 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 de= fines
> > OP_VAULT to have the behaviour specced for OP_FORWARD_LEAF_UPDATE= above,
> > and OP_VAULT_RECOVER to behave as OP_FORWARD_TARGET above. Despit= e
> > that, for this email I'm going to continue using the OP_FORWA= RD_*
> > naming convention.
> >
> > Given the recent controversy over the Yuga labs ordinal auction [= 2],
> > perhaps it's interesting to consider that these proposed opco= des 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 th= e 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 bid= der
> > wins, and the ordinal is moved to their address, while the funds<= br> > > from their winning bid are sent to the original vendor's addr= ess.
> >
> > 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 (&q= uot;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 corresp= onding
> > to that, and send the ordinal to that address as the first satosh= i.
> >
> > There are two ways to spend that script. With an empty witness st= ack,
> > 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 stac= k with
> > two items: your scriptPubKey and the new bid [X' V']. Exe= cution 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' >=3D V+K, stack contains [X' V' X]
> > 1 SWAP FORWARD_TARGET
> > -- output 1 pays to X (previous bidder's scriptPubKey), and t= he
> > entire value of this input goes there; stack contains [X' V&#= 39;]
> > DUP FORWARD_PARTIAL
> > -- execute "V' FORWARD_PARTIAL", stack contains [X&= #39; 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&qu= ot; 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<= br> > > three pushes (previously X V SSS) are replaced by X' V' S= SS.
> > 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 additiona= l 40
> > witness bytes for X'/V', so when making a bid, your tx wo= uld be
> > something like:
> >
> > tx header, 10vb
> > input 0: 103vb for the old bid including witness and control bloc= k
> > 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&= #39;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 th= e
> > various numbers (10000, 144, K, V, V').
> >
> > This approach seems pretty "MEV" resistant: you pay fee= s 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<= br> > > higher bidders from winning the auction, take control of the ordi= nal,
> > and resell it later, but unless they can prevent another miner fr= om
> > mining alternative bids for 144 blocks, they will fail at that. T= he 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 bi= d entirely.
> >
> > Obviously, this is a pretty limited auction mechanism in various = ways;
> > eg maybe you'd rather specify K as a percentage than an absou= te increment;
> > maybe you'd like to have the auction definitely finish by som= e 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 t= hose
> > things with this set of opcodes and clever scripting, though it p= robably
> > 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 b= y
> > OP_FORWARD_LEAF_UPDATE/OP_VAULT. Of course, without something lik= e
> > OP_PUSHCURRENTINPUTINDEX I don't think you could do it for or= dinals
> > either.
> >
> > Cheers,
> > aj
> >
> > [0] https://github.com/bitcoin/bips/blob/7f747fba82675f28c239df690a= 07b75529bd0960/bip-0345.mediawiki
> >
> > [1] https://twitter.com/jamesob/stat= us/1639019107432513537
> >
> > [2] https://cointelegraph.com/news/scammers-dream-yuga-s-auction-mo= del-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<= /a>
> >
> > [5] Setting K too low probably invites griefing, where a bidder m= ay be
> > able to use rbf pinning vectors to prevent people who would be wi= lling
> > to bid substantially higher from getting their bid confirmed on > > chain.
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundatio= n.org/mailman/listinfo/bitcoin-dev
--0000000000006deb2d05f81bb69d--