Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id A4119C002F for ; Thu, 30 Mar 2023 00:16:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 6B03861505 for ; Thu, 30 Mar 2023 00:16:57 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 6B03861505 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=lMsBwZYo 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 eyt3AudjvJfC for ; Thu, 30 Mar 2023 00:16:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 8C37A61497 Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by smtp3.osuosl.org (Postfix) with ESMTPS id 8C37A61497 for ; Thu, 30 Mar 2023 00:16:55 +0000 (UTC) Received: by mail-pf1-x430.google.com with SMTP id fb38so11431365pfb.7 for ; Wed, 29 Mar 2023 17:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680135415; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DVtS2msJ+slnbZE28t0gK7U/kIol1DX9SGyT1kcEyb8=; b=lMsBwZYoj7Q2xboRGSxuqXTY//VNj3xrlXw5NBXwCR8ZtDBFt3pugu1OsTGizi03Y6 UGi5hMm21wLrcCaKPdvVReY477nQG3UolNVPDsocw0VlDRTtPlmKkpfQnZY0ER/hchrC RlOQoF3fw0I/NPW9/EIggFStcyaadhbdz7/411cGlpjauRKgkhMqVOilZbQHndxTxbLq ZLTpDe+uMPMRhGO7EZ7t433JRowMTOM/J7mPOw9YUGYvPxFCejoWApuVdG3cNfO8hW5z 1j6kHvoRmOWMM9+qul3nrPGBc0wCEOVvxE/L9kMc1gcSnsbvypVlOI5fsnVoeExpBF+n vSDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680135415; 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=DVtS2msJ+slnbZE28t0gK7U/kIol1DX9SGyT1kcEyb8=; b=Frjo4PEudlHAM7flMmJebt/pAB0ZIwPSU6apI1ORtcF4BN0bCZvvDRR0RmJfMTv84Y Y+SgR1BigtUpKexQTg5kmHJNl97F0tFIJLHOvp8xl3Cz1iuUGDnw7YcpkoJeLojEXlBm R2hPTccQP20mnomfSaq9MRzPeFAczNn3pVX8HI4VT1QWq7uPYcOh29CcT6h0Wjp0xnen 0tSHcW8uZ5JdUgJsj/WPZcfeWDIzHxKPRxhQtPEIIh38/YXzRbMKwWjB51LK/ZL7H9HY kEB4IzroSwrCfSxFihEts5Rkh5dYWg9aTIxPHpNyT3GAx3j6apCFX++oZBeucDrO7vhB lX4A== X-Gm-Message-State: AAQBX9dwMloWKA+723RFvhcxoGz8yyVfU2GPJ5ajrFw2fpFjLgGznKPw guANxSbx8QTPEHuqpkK8NRQ4DYDEVjqVLMLrAnXYvDeXSGQ= X-Google-Smtp-Source: AKy350Y0LVY3ouI6LE56vpldFtgTTYhyL8FQ7EH80pAWC6AccdU7MBY97hr3UgYp6kUUe65hgM/twHK4v9Zx2WJQqew= X-Received: by 2002:a63:ed42:0:b0:513:2293:eeab with SMTP id m2-20020a63ed42000000b005132293eeabmr5675969pgk.8.1680135414712; Wed, 29 Mar 2023 17:16:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Steve Lee Date: Wed, 29 Mar 2023 17:16:43 -0700 Message-ID: To: alicexbt , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000918df105f8130290" X-Mailman-Approved-At: Thu, 30 Mar 2023 09:26:55 +0000 Cc: 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 00:16:57 -0000 --000000000000918df105f8130290 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable "want bitcoin to be money and money means different things for people in this world" I think we can all agree that a property of money is fungibility, and by its very definition NFTs are not fungible and thus not money. On Wed, Mar 29, 2023 at 4:56=E2=80=AFPM alicexbt via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> 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 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000918df105f8130290 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"want bitcoin to be money and money means different t= hings for people in this world"

I think we can all agree that a= property of money is fungibility, and by its very definition NFTs are not = fungible and thus not money.

On Wed, Mar 29, 2023 at 4:56=E2=80=AFPM alice= xbt via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000918df105f8130290--