Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 92066C002F for ; Thu, 30 Mar 2023 18:12:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 6ABF34208D for ; Thu, 30 Mar 2023 18:12:55 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 6ABF34208D Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=bUeXEIT7 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqwfWdtEl33G for ; Thu, 30 Mar 2023 18:12:53 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org C103B4208C Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19]) by smtp4.osuosl.org (Postfix) with ESMTPS id C103B4208C for ; Thu, 30 Mar 2023 18:12:52 +0000 (UTC) Date: Thu, 30 Mar 2023 18:12:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1680199969; x=1680459169; bh=jZlFZwg3maiW3gegmTegeDp1gHu+EGkNnhV5Tdnw6XE=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=bUeXEIT7BqqLygUUhtLZEUhAC98QNvt7JpBP9HgrzZGEf22I/GC0h3GSWq85cW8LP r/GwRXQOHFlQ5zfy4tzqWcTH6yHFYRmk+LrZlhdX3fGRR85zpduC3pZzNVDihaPdGW WkgR/XEVCak9SqS9vafX2gSSZhM2hvehIF/CFqFScJZJnqveEK35r4AqeevQedu+e3 N0yx4G6lGGkI9BXyCNGLg2CW5509Cr+wfMqMSODJ3eGmy8904y+GxNt2Mf2352E8VV tue9YbTILhFreF6o+IA22W9/YfI9JpiM5RIuE+Rh+4q6xZLhqu62qOHNxg8JRH4fT2 ojDgHcBH0DpSA== To: Zac Greenwood From: alicexbt Message-ID: In-Reply-To: References: Feedback-ID: 40602938:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 18:12:55 -0000 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 = 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 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 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 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