path: root/87/db5d638aba6fb0b0c1d6964eb0b1176c8272c5

Return-Path: <steven.j.lee@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A4119C002F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 30 Mar 2023 00:16:55 +0000 (UTC)
Received: by mail-pf1-x430.google.com with SMTP id fb38so11431365pfb.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <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> <ZB2THW3WT2wiU7Ni@erisian.com.au>
 <CAJ4-pEAyuHi-1iBzYWbpUNi2-YkxFLVBKAWTV=TyP1TVTFYMfA@mail.gmail.com>
 <C4SV8-jdNABNgVA8aE8Du6WITwynrcq9st7wkSN4k6Px4zhWKWZdSlAvYhTLRXe3yDMC5uNhRNoMGAdMqKReVYUjr-0dGGv9H2u2L9v7gtY=@protonmail.com>
In-Reply-To: <C4SV8-jdNABNgVA8aE8Du6WITwynrcq9st7wkSN4k6Px4zhWKWZdSlAvYhTLRXe3yDMC5uNhRNoMGAdMqKReVYUjr-0dGGv9H2u2L9v7gtY=@protonmail.com>
From: Steve Lee <steven.j.lee@gmail.com>
Date: Wed, 29 Mar 2023 17:16:43 -0700
Message-ID: <CABu3BAdL-FRMkfqVY+y=JUX7VGSL4RZt8hP_LhE9hYytaS8rmw@mail.gmail.com>
To: alicexbt <alicexbt@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000918df105f8130290"
X-Mailman-Approved-At: Thu, 30 Mar 2023 09:26:55 +0000
Cc: Anthony Towns <aj@erisian.com.au>
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: 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

<div dir=3D"ltr">&quot;want bitcoin to be money and money means different t=
hings for people in this world&quot;<br><br>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.</div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Wed, Mar 29, 2023 at 4:56=E2=80=AFPM alice=
xbt via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">Hi Zac,<br>
<br>
Let me share what those parasites achieved:<br>
<br>
- Fees paid: 150 BTC<br>
- Lot of users and developers trying bitcoin that either never tried or gav=
e up early in 2013-15<br>
- 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<br>
- Some developers exploring taproot and multisig<br>
- 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: <a href=3D"https://twitter.com/1440000bytes/st=
atus/1634368411760476161" rel=3D"noreferrer" target=3D"_blank">https://twit=
ter.com/1440000bytes/status/1634368411760476161</a><br>
- Investors exploring about funding projects<br>
- Bitcoin more than Bitcoin and people excited about it <br>
<br>
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. <br>
<br>
/dev/fd0<br>
floppy disk guy<br>
<br>
Sent with Proton Mail secure email.<br>
<br>
------- Original Message -------<br>
On Wednesday, March 29th, 2023 at 12:40 PM, Zac Greenwood via bitcoin-dev &=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
k">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
<br>
<br>
&gt; 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.<br>
&gt;<br>
&gt; If anything, business models relying on the ability to abuse the block=
chain as a data store must be made less feasible, not more.<br>
&gt;<br>
&gt; Zac<br>
&gt;<br>
&gt;<br>
&gt; On Fri, 24 Mar 2023 at 20:10, Anthony Towns via bitcoin-dev &lt;<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoi=
n-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; On Tue, Mar 07, 2023 at 10:45:34PM +1000, Anthony Towns via bitco=
in-dev wrote:<br>
&gt; &gt; &gt; I think there are perhaps four opcodes that are interesting =
in this class:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; idx sPK OP_FORWARD_TARGET<br>
&gt; &gt; &gt; -- sends the value to a particular output (given by idx), an=
d<br>
&gt; &gt; &gt; requires that output have a particular scriptPubKey (given<b=
r>
&gt; &gt; &gt; by sPK).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; idx [...] n script OP_FORWARD_LEAF_UPDATE<br>
&gt; &gt; &gt; -- sends the value to a particular output (given by idx), an=
d<br>
&gt; &gt; &gt; requires that output to have almost the same scriptPubKey as=
 this<br>
&gt; &gt; &gt; input, _except_ that the current leaf is replaced by &quot;s=
cript&quot;,<br>
&gt; &gt; &gt; with that script prefixed by &quot;n&quot; pushes (of values=
 given by [...])<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; idx OP_FORWARD_SELF<br>
&gt; &gt; &gt; -- sends the value to a particular output (given by idx), an=
d<br>
&gt; &gt; &gt; requires that output to have the same scriptPubKey as this i=
nput<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; amt OP_FORWARD_PARTIAL<br>
&gt; &gt; &gt; -- modifies the next OP_FORWARD_* opcode to only affect &quo=
t;amt&quot;,<br>
&gt; &gt; &gt; rather than the entire balance. opcodes after that affect th=
e<br>
&gt; &gt; &gt; remaining balance, after &quot;amt&quot; has been subtracted=
. if &quot;amt&quot; is<br>
&gt; &gt; &gt; 0, the next OP_FORWARD_* becomes a no-op.<br>
&gt; &gt;<br>
&gt; &gt; The BIP 345 draft has been updated [0] [1] and now pretty much de=
fines<br>
&gt; &gt; OP_VAULT to have the behaviour specced for OP_FORWARD_LEAF_UPDATE=
 above,<br>
&gt; &gt; and OP_VAULT_RECOVER to behave as OP_FORWARD_TARGET above. Despit=
e<br>
&gt; &gt; that, for this email I&#39;m going to continue using the OP_FORWA=
RD_*<br>
&gt; &gt; naming convention.<br>
&gt; &gt;<br>
&gt; &gt; Given the recent controversy over the Yuga labs ordinal auction [=
2],<br>
&gt; &gt; perhaps it&#39;s interesting to consider that these proposed opco=
des come<br>
&gt; &gt; close to making it possible to do a fair, non-custodial, on-chain=
 auction<br>
&gt; &gt; of ordinals [3].<br>
&gt; &gt;<br>
&gt; &gt; The idea here is that you create a utxo on chain that contains th=
e ordinal<br>
&gt; &gt; in question, which commits to the address of the current leading =
bidder,<br>
&gt; &gt; and can be spent in two ways:<br>
&gt; &gt;<br>
&gt; &gt; 1) it can be updated to a new bidder, if the bid is raised by at =
least<br>
&gt; &gt; K satoshis, in which case the previous bidder is refunded their<b=
r>
&gt; &gt; bid; or,<br>
&gt; &gt;<br>
&gt; &gt; 2) if there have been no new bids for a day, the current high bid=
der<br>
&gt; &gt; wins, and the ordinal is moved to their address, while the funds<=
br>
&gt; &gt; from their winning bid are sent to the original vendor&#39;s addr=
ess.<br>
&gt; &gt;<br>
&gt; &gt; I believe this can be implemented in script as follows,<br>
&gt; &gt; assuming the opcodes OP_FORWARD_TARGET(OP_VAULT_RECOVER),<br>
&gt; &gt; OP_FORWARD_LEAF_UPDATE(OP_VAULT), OP_FORWARD_PARTIAL (as specced =
above),<br>
&gt; &gt; and OP_PUSHCURRENTINPUTINDEX (as implemented in liquid/elements [=
4])<br>
&gt; &gt; are all available.<br>
&gt; &gt;<br>
&gt; &gt; First, figure out the parameters:<br>
&gt; &gt;<br>
&gt; &gt; * Set VENDOR to the scriptPubKey corresponding to the vendor&#39;=
s address.<br>
&gt; &gt; * Set K to the minimum bid increment [5].<br>
&gt; &gt; * Initially, set X equal to VENDOR.<br>
&gt; &gt; * Initially, set V to just below the reserve price (V+K is the<br=
>
&gt; &gt; minimum initial bid).<br>
&gt; &gt;<br>
&gt; &gt; Then construct the following script:<br>
&gt; &gt;<br>
&gt; &gt; [X] [V] [SSS] TOALT TOALT TOALT<br>
&gt; &gt; 0 PUSHCURRENTINPUTINDEX EQUALVERIFY<br>
&gt; &gt; DEPTH NOT IF<br>
&gt; &gt; 0 10000 FORWARD_PARTIAL<br>
&gt; &gt; 0 FROMALT FORWARD_TARGET<br>
&gt; &gt; 1 [VENDOR] FWD_TARGET<br>
&gt; &gt; 144<br>
&gt; &gt; ELSE<br>
&gt; &gt; FROMALT SWAP TUCK FROMALT<br>
&gt; &gt; [K] ADD GREATERTHANOREQUAL VERIFY<br>
&gt; &gt; 1 SWAP FORWARD_TARGET<br>
&gt; &gt; DUP FORWARD_PARTIAL<br>
&gt; &gt; 0 ROT ROT<br>
&gt; &gt; FROMALT DUP 3 SWAP FORWARD_LEAF_UPDATE<br>
&gt; &gt; 0<br>
&gt; &gt; ENDIF<br>
&gt; &gt; CSV<br>
&gt; &gt; 1ADD<br>
&gt; &gt;<br>
&gt; &gt; where &quot;SSS&quot; is a pushdata of the rest of the script (&q=
uot;TOALT TOALT TOALT<br>
&gt; &gt; .. 1ADD&quot;).<br>
&gt; &gt;<br>
&gt; &gt; Finally, make that script the sole tapleaf, accompanied by a NUMS=
 point<br>
&gt; &gt; as the internal public key, calculate the taproot address corresp=
onding<br>
&gt; &gt; to that, and send the ordinal to that address as the first satosh=
i.<br>
&gt; &gt;<br>
&gt; &gt; There are two ways to spend that script. With an empty witness st=
ack,<br>
&gt; &gt; the following will be executed:<br>
&gt; &gt;<br>
&gt; &gt; [X] [V] [SSS] TOALT TOALT TOALT<br>
&gt; &gt; -- altstack now contains [SSS V X]<br>
&gt; &gt; 0 PUSHCURRENTINPUTINDEX EQUALVERIFY<br>
&gt; &gt; -- this input is the first, so the ordinal will move to the first=
<br>
&gt; &gt; output<br>
&gt; &gt; DEPTH NOT IF<br>
&gt; &gt; -- take this branch: the auction is over!<br>
&gt; &gt; 1 [VENDOR] FWD_TARGET<br>
&gt; &gt; -- output 1 gets the entire value of this input, and pays to<br>
&gt; &gt; the vendor&#39;s hardcoded scriptPubKey<br>
&gt; &gt; 0 10000 FORWARD_PARTIAL<br>
&gt; &gt; 0 FROMALT FORWARD_TARGET<br>
&gt; &gt; -- we forward at least 10k sats to output 0 (if there were 0 sats=
,<br>
&gt; &gt; the ordinal would end up in output 1 instead, which would be a<br=
>
&gt; &gt; bug), and output 0 pays to scriptPubKey &quot;X&quot;<br>
&gt; &gt; 144<br>
&gt; &gt; ELSE .. ENDIF<br>
&gt; &gt; -- skip over the other branch<br>
&gt; &gt; CSV<br>
&gt; &gt; -- check that this input has baked for 144 blocks (~1 day)<br>
&gt; &gt; 1ADD<br>
&gt; &gt; -- leave 145 on the stack, which is true. success!<br>
&gt; &gt;<br>
&gt; &gt; Alternatively, if you want to increase the bid you provide a stac=
k with<br>
&gt; &gt; two items: your scriptPubKey and the new bid [X&#39; V&#39;]. Exe=
cution this<br>
&gt; &gt; time looks like:<br>
&gt; &gt;<br>
&gt; &gt; [X] [V] [SSS] TOALT TOALT TOALT<br>
&gt; &gt; -- stack contains [X&#39; V&#39;], altstack now contains [SSS V X=
]<br>
&gt; &gt; 0 PUSHCURRENTINPUTINDEX EQUALVERIFY<br>
&gt; &gt; -- this input is the first, so the ordinal will move to the first=
<br>
&gt; &gt; output<br>
&gt; &gt; DEPTH NOT IF ... ELSE<br>
&gt; &gt; -- skip over the other branch (without violating minimalif rules)=
<br>
&gt; &gt; FROMALT SWAP TUCK FROMALT<br>
&gt; &gt; -- stack contains [X&#39; V&#39; X V&#39; V], altstack contains [=
SSS]<br>
&gt; &gt; [K] ADD GREATERTHANOREQUAL VERIFY<br>
&gt; &gt; -- check V&#39; &gt;=3D V+K, stack contains [X&#39; V&#39; X]<br>
&gt; &gt; 1 SWAP FORWARD_TARGET<br>
&gt; &gt; -- output 1 pays to X (previous bidder&#39;s scriptPubKey), and t=
he<br>
&gt; &gt; entire value of this input goes there; stack contains [X&#39; V&#=
39;]<br>
&gt; &gt; DUP FORWARD_PARTIAL<br>
&gt; &gt; -- execute &quot;V&#39; FORWARD_PARTIAL&quot;, stack contains [X&=
#39; V&#39;]<br>
&gt; &gt; 0 ROT ROT<br>
&gt; &gt; -- stack contains [0 X&#39; V&#39;]<br>
&gt; &gt; FROMALT DUP 3 SWAP FORWARD_LEAF_UPDATE<br>
&gt; &gt; -- execute &quot;0 X&#39; V&#39; SSS 3 SSS FORWARD_LEAF_UPDATE&qu=
ot; which checks<br>
&gt; &gt; that output 0 spends at least V&#39; satoshis back to the same<br=
>
&gt; &gt; script (because that&#39;s how we defined SSS), except the first<=
br>
&gt; &gt; three pushes (previously X V SSS) are replaced by X&#39; V&#39; S=
SS.<br>
&gt; &gt; 0<br>
&gt; &gt; ENDIF<br>
&gt; &gt; CSV<br>
&gt; &gt; -- &quot;0 CSV&quot; requires nSequnce to be set, which makes the=
 tx rbf&#39;able,<br>
&gt; &gt; which hopefully makes it harder to pin<br>
&gt; &gt; 1ADD<br>
&gt; &gt; -- ends with 1 on the stack; success!<br>
&gt; &gt;<br>
&gt; &gt; (The &quot;SSS n SSS FORWARD_LEAF_UPDATE&quot; construct is more =
or less a quine,<br>
&gt; &gt; ie a program that outputs its own source code)<br>
&gt; &gt;<br>
&gt; &gt; I think that script is about 211 witness bytes, with an additiona=
l 40<br>
&gt; &gt; witness bytes for X&#39;/V&#39;, so when making a bid, your tx wo=
uld be<br>
&gt; &gt; something like:<br>
&gt; &gt;<br>
&gt; &gt; tx header, 10vb<br>
&gt; &gt; input 0: 103vb for the old bid including witness and control bloc=
k<br>
&gt; &gt; input 1: 58vb for a taproot key path spend<br>
&gt; &gt; output 0: 43vb for the new bid<br>
&gt; &gt; output 1: 43vb for your change<br>
&gt; &gt;<br>
&gt; &gt; for a total of about 257vb -- slightly larger than a regular 2-in=
-2-out<br>
&gt; &gt; transaction, but not terribly much. Mostly because input 0 doesn&=
#39;t require<br>
&gt; &gt; a signature -- it&#39;s size is effectively 6 pubkeys: X, X&#39; =
VENDOR twice,<br>
&gt; &gt; and the script code twice, along with a little extra to encode th=
e<br>
&gt; &gt; various numbers (10000, 144, K, V, V&#39;).<br>
&gt; &gt;<br>
&gt; &gt; This approach seems pretty &quot;MEV&quot; resistant: you pay fee=
s via input 1 if<br>
&gt; &gt; your bid succeeds; if it doesn&#39;t, you don&#39;t pay any fees.=
 A potential<br>
&gt; &gt; scalper might want to put in an early low ball bid, then prevent<=
br>
&gt; &gt; higher bidders from winning the auction, take control of the ordi=
nal,<br>
&gt; &gt; and resell it later, but unless they can prevent another miner fr=
om<br>
&gt; &gt; mining alternative bids for 144 blocks, they will fail at that. T=
he bid<br>
&gt; &gt; is fixed by the bidder and committed to by the signature on input=
 1, so<br>
&gt; &gt; frontrunning a bid can&#39;t do anything beyond invalidate the bi=
d entirely.<br>
&gt; &gt;<br>
&gt; &gt; Obviously, this is a pretty limited auction mechanism in various =
ways;<br>
&gt; &gt; eg maybe you&#39;d rather specify K as a percentage than an absou=
te increment;<br>
&gt; &gt; maybe you&#39;d like to have the auction definitely finish by som=
e particular<br>
&gt; &gt; time; maybe you&#39;d like to be able to have the auction be able=
 to continue<br>
&gt; &gt; above 21.47 BTC (2**31 sats); maybe you&#39;d like to do a dutch =
auction<br>
&gt; &gt; rather than an english auction. I think you can probably do all t=
hose<br>
&gt; &gt; things with this set of opcodes and clever scripting, though it p=
robably<br>
&gt; &gt; gets ugly.<br>
&gt; &gt;<br>
&gt; &gt; I don&#39;t think this is easily extensible to taro or rgb style =
assets,<br>
&gt; &gt; as rather than being able to ensure the asset is transferred by<b=
r>
&gt; &gt; controlling the input/output positions, I think you&#39;d need to=
 build<br>
&gt; &gt; up merkle trees and do point tweaks beyond what&#39;s supported b=
y<br>
&gt; &gt; OP_FORWARD_LEAF_UPDATE/OP_VAULT. Of course, without something lik=
e<br>
&gt; &gt; OP_PUSHCURRENTINPUTINDEX I don&#39;t think you could do it for or=
dinals<br>
&gt; &gt; either.<br>
&gt; &gt;<br>
&gt; &gt; Cheers,<br>
&gt; &gt; aj<br>
&gt; &gt;<br>
&gt; &gt; [0] <a href=3D"https://github.com/bitcoin/bips/blob/7f747fba82675=
f28c239df690a07b75529bd0960/bip-0345.mediawiki" rel=3D"noreferrer" target=
=3D"_blank">https://github.com/bitcoin/bips/blob/7f747fba82675f28c239df690a=
07b75529bd0960/bip-0345.mediawiki</a><br>
&gt; &gt;<br>
&gt; &gt; [1] <a href=3D"https://twitter.com/jamesob/status/163901910743251=
3537" rel=3D"noreferrer" target=3D"_blank">https://twitter.com/jamesob/stat=
us/1639019107432513537</a><br>
&gt; &gt;<br>
&gt; &gt; [2] <a href=3D"https://cointelegraph.com/news/scammers-dream-yuga=
-s-auction-model-for-bitcoin-nfts-sees-criticism" rel=3D"noreferrer" target=
=3D"_blank">https://cointelegraph.com/news/scammers-dream-yuga-s-auction-mo=
del-for-bitcoin-nfts-sees-criticism</a><br>
&gt; &gt;<br>
&gt; &gt; [3] Inscriptions remain a wasteful way of publishing/committing<b=
r>
&gt; &gt; to content, however!<br>
&gt; &gt;<br>
&gt; &gt; [4] <a href=3D"https://github.com/ElementsProject/elements/blob/m=
aster/doc/tapscript_opcodes.md" rel=3D"noreferrer" target=3D"_blank">https:=
//github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md<=
/a><br>
&gt; &gt;<br>
&gt; &gt; [5] Setting K too low probably invites griefing, where a bidder m=
ay be<br>
&gt; &gt; able to use rbf pinning vectors to prevent people who would be wi=
lling<br>
&gt; &gt; to bid substantially higher from getting their bid confirmed on<b=
r>
&gt; &gt; chain.<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; bitcoin-dev mailing list<br>
&gt; &gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bit=
coin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundatio=
n.org/mailman/listinfo/bitcoin-dev</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000918df105f8130290--