Zac Greenwood [ARCHIVE] on Nostr: 📅 Original date posted:2023-03-29 🗒️ Summary of this message: Efforts should ...
📅 Original date posted:2023-03-29
🗒️ Summary of this message: Efforts should not be made to facilitate parasitical use cases of the blockchain. Business models relying on blockchain abuse must be made less feasible.
📝 Original message:I’m not sure why any effort should be spent on theorizing how new opcodes
might be used to facilitate parasitical use cases of the blockchain.
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 at 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 defines
> 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 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 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 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 ("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 corresponding
> 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 with
> 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' >= 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 quine,
> 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 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 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 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/7f747fba82675f28c239df690a07b75529bd0960/bip-0345.mediawiki
>
> [1] https://twitter.com/jamesob/status/1639019107432513537
>
> [2]
> https://cointelegraph.com/news/scammers-dream-yuga-s-auction-model-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
>
> [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 willing
> to bid substantially higher from getting their bid confirmed on
> chain.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230329/66e43c91/attachment.html>;
🗒️ Summary of this message: Efforts should not be made to facilitate parasitical use cases of the blockchain. Business models relying on blockchain abuse must be made less feasible.
📝 Original message:I’m not sure why any effort should be spent on theorizing how new opcodes
might be used to facilitate parasitical use cases of the blockchain.
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 at 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 defines
> 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 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 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 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 ("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 corresponding
> 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 with
> 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' >= 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 quine,
> 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 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 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 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/7f747fba82675f28c239df690a07b75529bd0960/bip-0345.mediawiki
>
> [1] https://twitter.com/jamesob/status/1639019107432513537
>
> [2]
> https://cointelegraph.com/news/scammers-dream-yuga-s-auction-model-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
>
> [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 willing
> to bid substantially higher from getting their bid confirmed on
> chain.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230329/66e43c91/attachment.html>;