Date: Thu, 30 Mar 2023 18:12:46 +0000
To: Zac Greenwood <zachgrw@gmail.com>
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <v7l8qpYTrt0POXPCeN4FJIDtZnItd8u7Gs9qd3FKiVoduEXfisATmmRA0SfYAKFR0mzZFY8-4zgzA0R2dJqIW4p_gXchZMECoY9I_-6fX6w=@protonmail.com>
In-Reply-To: <CAJ4-pEDq7kqLR9bAguShazdH6H92Y-pgNsOdEuqj=HaTWom88w@mail.gmail.com>
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>
 <CAJ4-pEDq7kqLR9bAguShazdH6H92Y-pgNsOdEuqj=HaTWom88w@mail.gmail.com>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] BIP for OP_VAULT
Precedence: list

Hi Zac,

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

https://dune.com/queries/2008613/3326984

> Your other arguments are nonsensical so excuse me for ignoring them.

There were zero browser extensions that could sign PSBT to be used in diffe=
rent bitcoin projects that have web interface earlier. Now there are severa=
l open source extensions that could be used to sign PSBT. If such developme=
nt and interest by developers from other chains to build things on bitcoin =
makes no sense to you that there is nothing much to debate here.

Humans have inscribed things on money since thousands of years when bitcoin=
 didn't even exist. Trying to fight this and going against market wont work=
.

I do not agree with other things mentioned in your email.

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

------- Original Message -------
On Thursday, March 30th, 2023 at 4:09 PM, Zac Greenwood <zachgrw@gmail.com>=
 wrote:


> Hi alicexbtc,
>=20
> Under no circumstance should Bitcoin add any functionality intended to su=
pport private businesses that rely on on-chain storage for their business m=
odel.
>=20
> Regarding =E2=80=9CFees paid: 150 BTC=E2=80=9D (uh, *citation needed*):
>=20
> To optimize for profitability a business would generally attempt to opera=
te using zero- or low-fee transactions. Therefore they tend to contribute c=
omparatively little fees but are depriving public use of these cheap transa=
ctions. Worse, they exert a constant upward pressure on fee levels, making =
it more expensive for everyone else to transact.
>=20
> Unlike miners, node operators do not receive any compensation. They howev=
er 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 f=
ailed and has been long gone. They foot the bill.
>=20
> 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 c=
rap but perhaps you wish to clarify why this might be something to be =
=E2=80=9Cexcited about=E2=80=9D.
>=20
> Your other arguments are nonsensical so excuse me for ignoring them.
>=20
>=20
> Zac
>=20
>=20
> On Thu, 30 Mar 2023 at 03:57, alicexbt <alicexbt@protonmail.com> wrote:
>=20
> > Hi Zac,
> >=20
> > Let me share what those parasites achieved:
> >=20
> > - 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 transacti=
ons
> > - 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-=
chain auction of ordinals that is MEV resistant although I had shared it ea=
rlier which involves more steps: https://twitter.com/1440000bytes/status/16=
34368411760476161
> > - Investors exploring about funding projects
> > - Bitcoin more than Bitcoin and people excited about it
> >=20
> > We can have difference of opinion, however I want bitcoin to be money a=
nd money means different things for people in this world. Please respect th=
at else it will become like Linux, something used by 1% of world.
> >=20
> > /dev/fd0
> > floppy disk guy
> >=20
> > Sent with Proton Mail secure email.
> >=20
> > ------- Original Message -------
> > On Wednesday, March 29th, 2023 at 12:40 PM, Zac Greenwood via bitcoin-d=
ev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >=20
> >=20
> > > 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 block=
chain.
> > >
> > > If anything, business models relying on the ability to abuse the bloc=
kchain 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 th=
is 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 defi=
nes
> > > > OP_VAULT to have the behaviour specced for OP_FORWARD_LEAF_UPDATE a=
bove,
> > > > 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 co=
me
> > > > close to making it possible to do a fair, non-custodial, on-chain a=
uction
> > > > 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 bi=
dder,
> > > > and can be spent in two ways:
> > > >
> > > > 1) it can be updated to a new bidder, if the bid is raised by at le=
ast
> > > > 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 bidde=
r
> > > > 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 ab=
ove),
> > > > 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 addr=
ess.
> > > > * 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 T=
OALT
> > > > .. 1ADD").
> > > >
> > > > Finally, make that script the sole tapleaf, accompanied by a NUMS p=
oint
> > > > as the internal public key, calculate the taproot address correspon=
ding
> > > > 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 stac=
k,
> > > > 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 thi=
s
> > > > 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 qu=
ine,
> > > > 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 twi=
ce,
> > > > 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 potenti=
al
> > > > scalper might want to put in an early low ball bid, then prevent
> > > > higher bidders from winning the auction, take control of the ordina=
l,
> > > > 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 enti=
rely.
> > > >
> > > > Obviously, this is a pretty limited auction mechanism in various wa=
ys;
> > > > eg maybe you'd rather specify K as a percentage than an absoute inc=
rement;
> > > > maybe you'd like to have the auction definitely finish by some part=
icular
> > > > time; maybe you'd like to be able to have the auction be able to co=
ntinue
> > > > above 21.47 BTC (2**31 sats); maybe you'd like to do a dutch auctio=
n
> > > > rather than an english auction. I think you can probably do all tho=
se
> > > > things with this set of opcodes and clever scripting, though it pro=
bably
> > > > 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/7f747fba82675f28c239df690a=
07b75529bd0960/bip-0345.mediawiki
> > > >
> > > > [1] https://twitter.com/jamesob/status/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/tap=
script_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 will=
ing
> > > > 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