Re: [bitcoin-dev] BIP for OP_VAULT
Hi Zac, > Regarding “Fees paid: 150 BTC” (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 different bitcoin projects that have web interface earlier. Now there are several open source extensions that could be used to sign PSBT. If such development 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, > > Under no circumstance should Bitcoin add any functionality intended to > support private businesses that rely on on-chain storage for their business > model. > > Regarding “Fees paid: 150 BTC” (uh, *citation needed*): > > To optimize for profitability a business would generally attempt to operate > using zero- or low-fee transactions. Therefore they tend to contribute > comparatively little fees but are depriving public use of these cheap > transactions. Worse, they exert a constant upward pressure on fee levels, > making it more expensive for everyone else to transact. > > Unlike miners, node operators do not receive any compensation. They however > 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 failed > and has been long gone. They foot the bill. > > Lastly, I don’t believe there is any value in having for instance Ordinals > spam the blockchain with images of wojaks, bored apes and other crap but > perhaps you wish to clarify why this might be something to be “excited about”. > > Your other arguments are nonsensical so excuse me for ignoring them. > > > Zac > > > On Thu, 30 Mar 2023 at 03:57, alicexbt 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 transactions > > - 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 > > earlier which involves more steps: > > https://twitter.com/144bytes/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 that > > 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 > > wrote: > > > > > > > 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 > > > 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
Re: [bitcoin-dev] BIP for OP_VAULT
Hi alicexbtc, Under no circumstance should Bitcoin add any functionality intended to support private businesses that rely on on-chain storage for their business model. Regarding “Fees paid: 150 BTC” (uh, *citation needed*): To optimize for profitability a business would generally attempt to operate using zero- or low-fee transactions. Therefore they tend to contribute comparatively little fees but are depriving public use of these cheap transactions. Worse, they exert a constant upward pressure on fee levels, making it more expensive for everyone else to transact. Unlike miners, node operators do not receive any compensation. They however 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 failed and has been long gone. They foot the bill. Lastly, I don’t believe there is any value in having for instance Ordinals spam the blockchain with images of wojaks, bored apes and other crap but perhaps you wish to clarify why this might be something to be “excited about”. Your other arguments are nonsensical so excuse me for ignoring them. Zac On Thu, 30 Mar 2023 at 03:57, alicexbt 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 transactions > - 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 > earlier which involves more steps: > https://twitter.com/144bytes/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 that > 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’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@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
Re: [bitcoin-dev] BIP for OP_VAULT
"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 PM 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 transactions > - 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 > earlier which involves more steps: > https://twitter.com/144bytes/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 that > 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’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@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). > > >
Re: [bitcoin-dev] BIP for OP_VAULT
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 transactions
- 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 earlier
which involves more steps:
https://twitter.com/144bytes/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 that 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
wrote:
> 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
> 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 1 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,
Re: [bitcoin-dev] BIP for OP_VAULT
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@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 1 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 1 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.
Re: [bitcoin-dev] BIP for OP_VAULT
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 1 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 1 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
--
Re: [bitcoin-dev] BIP for OP_VAULT
Hi Luke, I think this works as with OP_FLU based construct, for the simplest single key case. e.g., single key hot wallet(or MuSig2/FROST wallet) 1 " OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKSIG" OP_FORWARD_LEAF_UPDATE The is appended at spending time. This allows the utxo to go to $recover cold storage at any point like before, otherwise the time matures and the funds can be spent by a single key. Rate-limiting like usual can be bolted on as well using OP_FORWARD_* opcodes, I'm pretty sure. This would as you note require wallet support, where the hot wallet would have to be aware of the vault, or be scanning inputs looking for this type of leaf. Unfortunately this doesn't extend to things like OP_CHECKSIGADD, since the pubkeys are all pushed first, then the opcodes run. OP_CHECKMULTISIG would have worked probably. To generalize I think you'd need recursive taproot, or a proper replacement for Bitcoin script :) Cheers, Greg On Mon, Mar 13, 2023 at 4:55 PM Luke Dashjr wrote: > In ordinary use cases, you wouldn't clawback; that would only be in the > extreme case of the wallet being compromised. So typical usage would just > be receive -> send, like wallets currently do. > > Luke > > > On 3/13/23 10:56, Greg Sanders wrote: > > Didn't finish sentence: but in practice would end up with pretty similar > usage flows imho, and as noted in PR, would take a different wallet > paradigm, > among other technical challenges. > > On Mon, Mar 13, 2023 at 10:55 AM Greg Sanders > wrote: > >> Hi Luke, >> >> Can you elaborate why the current idealized functionality of deposit -> >> trigger -> withdrawal is too complicated for >> everyday use but the above deposit -> withdrawal -> >> resolve(claim/clawback) wouldn't be? I admit at a high level >> it's a fine paradigm, but in practice would end >> >> Let's ignore implementation for the discussion, since that's in flux. >> >> Cheers, >> Greg >> >> On Sat, Mar 11, 2023 at 3:53 PM Luke Dashjr via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> I started reviewing the BIP, but stopped part way through, as it seems >>> to have a number of conceptual issues. >>> >>> I left several comments on the PR >>> (https://github.com/bitcoin/bips/pull/1421#pullrequestreview-1335925575), >>> >>> but ultimately I think it isn't simplified enough for day-to-day use, >>> and would harm privacy quite a bit. >>> >>> Instead, I would suggest a new approach where: >>> >>> 1) Joe receives funds with a taproot output like normal. >>> 2) Joe sends funds to Fred, but Fred cannot spend them until N blocks >>> later (covenant-enforced relative locktime). Ideally, this should >>> use/support a taproot keypath spend somehow. It would be nice to blind >>> the particular relative locktime somehow too, but that may be too >>> expensive. >>> 2b) If Joe's funds were stolen, Joe can spend Fred's UTXO within the N >>> block window to a recovery output. >>> >>> Unfortunately, the implementation details for this kind of setup are >>> non-obvious and will likely require yet another address format (or at >>> least recipient-wallet changes), but certainly seems within the scope of >>> possibility. >>> >>> Thoughts? >>> >>> Luke >>> >>> >>> On 2/13/23 16:09, James O'Beirne via bitcoin-dev wrote: >>> > Since the last related correspondence on this list [0], a number of >>> > improvements have been made to the OP_VAULT draft [1]: >>> > >>> > * There is no longer a hard dependence on package relay/ephemeral >>> > anchors for fee management. When using "authorized recovery," all >>> > vault-related transactions can be bundled with unrelated inputs and >>> > outputs, facilitating fee management that is self contained to the >>> > transaction. Consequently, the contents of this proposal are in >>> theory >>> > usable today. >>> > >>> > * Specific output locations are no longer hardcoded in any of the >>> > transaction validation algorithms. This means that the proposal is >>> now >>> > compatible with future changes like SIGHASH_GROUP, and >>> > transaction shapes for vault operations are more flexible. >>> > >>> > --- >>> > >>> > I've written a BIP that fully describes the proposal here: >>> > >>> > >>> https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawiki >>> > >>> > The corresponding PR is here: >>> > >>> > https://github.com/bitcoin/bips/pull/1421 >>> > >>> > My next steps will be to try for a merge to the inquisition repo. >>> > >>> > Thanks to everyone who has participated so far, but especially to AJ >>> and >>> > Greg for all the advice. >>> > >>> > James >>> > >>> > [0]: >>> > >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html >>> > [1]: https://github.com/bitcoin/bitcoin/pull/26857 >>> > >>> > ___ >>> > bitcoin-dev mailing list >>> > bitcoin-dev@lists.linuxfoundation.org >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>
Re: [bitcoin-dev] BIP for OP_VAULT
Hi Brandon, Thank you for chiming in, causing me to think a bit more deeply on the privacy issues and what seems possible. > I like that in James' current PR proposal we can explicitly batch via the implied input/output summation rules while avoiding address reuse. If we can retain some or all of that, I think it would be good for on chain efficiency and potentially privacy. Rotating trigger authorization keys maintains batchability and stops address reuse. Remember that anytime you share any path, like recovery path, for batching, it becomes obvious at spend-time. Rotating inner pubkeys only doesn't seem to help much. Coinjoins being the other batching scenario which could benefit perhaps are quite a heavy lift. You'd need the recovery policy(every other branch) to be agreed upon, have everyone unvault to this new joint vault, then mix, and withdrawal back to the original vault. If someone is going through all that effort, I suspect they'll just use a NUMS to reduce fingerprinting. > Many inputs with different internal keys can be combined to satisfy the total output value for a single output, as long as their scriptpubkeys with FLU and NUMS internal key are equal This enables avoiding address reuse within the vault. To reiterate, we can just cycle any key in the $trigger branch with OP_FLU, which accomplishes the same thing. Or in authorization-less $trigger, add a random number which is dropped. > Many inputs with the same scriptpubkey can be combined to satisfy a single CTV output template. This allows a user to unfsck themselves if they initiate a withdrawal that cannot be satisfied because they didn't send enough sats to satisfy their template. I think that would fit the deprecated OP_FORWARD_OUTPUTS, but OP_CTV commits to total number of inputs to remove txid malleability. I think the real solution to this mistake would be to hit the big red RECOVERY button that you're relying on for vault security anyways. Cheers, Greg On Mon, Mar 13, 2023 at 3:04 PM Brandon Black wrote: > Hi Gents, > > > > I don't think replacing the internal-public-key makes sense -- if it > > was immediately spendable via the keypath before there's no reason for > > it not to be immediately spendable now. > > > > Slavishly following the current proposal was the idea to make sure all > > functionality was captured; I agree with this change. > > I think we do need to replace the internal key with a hardcoded NUMS > point to allow us to batch multiple vault inputs which might have > different internal keys but the same OP_FLU/OP_VAULT_TRIGGER script to > the same time+template-restricted output. > > I like that in James' current PR proposal we can explicitly batch via > the implied input/output summation rules while avoiding address reuse. > If we can retain some or all of that, I think it would be good for on > chain efficiency and potentially privacy. > > My thoughts on batching: > > Many inputs with different internal keys can be combined to satisfy the > total output value for a single output, as long as their scriptpubkeys > with FLU and NUMS internal key are equal This enables avoiding address > reuse within the vault. > > Many inputs with the same scriptpubkey can be combined to satisfy a > single CTV output template. This allows a user to unfsck themselves if > they initiate a withdrawal that cannot be satisfied because they didn't > send enough sats to satisfy their template. > > Best, > > --Brandon > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP for OP_VAULT
Hi Gents, > > I don't think replacing the internal-public-key makes sense -- if it > was immediately spendable via the keypath before there's no reason for > it not to be immediately spendable now. > > Slavishly following the current proposal was the idea to make sure all > functionality was captured; I agree with this change. I think we do need to replace the internal key with a hardcoded NUMS point to allow us to batch multiple vault inputs which might have different internal keys but the same OP_FLU/OP_VAULT_TRIGGER script to the same time+template-restricted output. I like that in James' current PR proposal we can explicitly batch via the implied input/output summation rules while avoiding address reuse. If we can retain some or all of that, I think it would be good for on chain efficiency and potentially privacy. My thoughts on batching: Many inputs with different internal keys can be combined to satisfy the total output value for a single output, as long as their scriptpubkeys with FLU and NUMS internal key are equal This enables avoiding address reuse within the vault. Many inputs with the same scriptpubkey can be combined to satisfy a single CTV output template. This allows a user to unfsck themselves if they initiate a withdrawal that cannot be satisfied because they didn't send enough sats to satisfy their template. Best, --Brandon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP for OP_VAULT
In ordinary use cases, you wouldn't clawback; that would only be in the extreme case of the wallet being compromised. So typical usage would just be receive -> send, like wallets currently do. Luke On 3/13/23 10:56, Greg Sanders wrote: Didn't finish sentence: but in practice would end up with pretty similar usage flows imho, and as noted in PR, would take a different wallet paradigm, among other technical challenges. On Mon, Mar 13, 2023 at 10:55 AM Greg Sanders wrote: Hi Luke, Can you elaborate why the current idealized functionality of deposit -> trigger -> withdrawal is too complicated for everyday use but the above deposit -> withdrawal -> resolve(claim/clawback) wouldn't be? I admit at a high level it's a fine paradigm, but in practice would end Let's ignore implementation for the discussion, since that's in flux. Cheers, Greg On Sat, Mar 11, 2023 at 3:53 PM Luke Dashjr via bitcoin-dev wrote: I started reviewing the BIP, but stopped part way through, as it seems to have a number of conceptual issues. I left several comments on the PR (https://github.com/bitcoin/bips/pull/1421#pullrequestreview-1335925575), but ultimately I think it isn't simplified enough for day-to-day use, and would harm privacy quite a bit. Instead, I would suggest a new approach where: 1) Joe receives funds with a taproot output like normal. 2) Joe sends funds to Fred, but Fred cannot spend them until N blocks later (covenant-enforced relative locktime). Ideally, this should use/support a taproot keypath spend somehow. It would be nice to blind the particular relative locktime somehow too, but that may be too expensive. 2b) If Joe's funds were stolen, Joe can spend Fred's UTXO within the N block window to a recovery output. Unfortunately, the implementation details for this kind of setup are non-obvious and will likely require yet another address format (or at least recipient-wallet changes), but certainly seems within the scope of possibility. Thoughts? Luke On 2/13/23 16:09, James O'Beirne via bitcoin-dev wrote: > Since the last related correspondence on this list [0], a number of > improvements have been made to the OP_VAULT draft [1]: > > * There is no longer a hard dependence on package relay/ephemeral > anchors for fee management. When using "authorized recovery," all > vault-related transactions can be bundled with unrelated inputs and > outputs, facilitating fee management that is self contained to the > transaction. Consequently, the contents of this proposal are in theory > usable today. > > * Specific output locations are no longer hardcoded in any of the > transaction validation algorithms. This means that the proposal is now > compatible with future changes like SIGHASH_GROUP, and > transaction shapes for vault operations are more flexible. > > --- > > I've written a BIP that fully describes the proposal here: > > https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawiki > > The corresponding PR is here: > > https://github.com/bitcoin/bips/pull/1421 > > My next steps will be to try for a merge to the inquisition repo. > > Thanks to everyone who has participated so far, but especially to AJ and > Greg for all the advice. > > James > > [0]: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html > [1]: https://github.com/bitcoin/bitcoin/pull/26857 > > ___ > 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP for OP_VAULT
Didn't finish sentence: but in practice would end up with pretty similar usage flows imho, and as noted in PR, would take a different wallet paradigm, among other technical challenges. On Mon, Mar 13, 2023 at 10:55 AM Greg Sanders wrote: > Hi Luke, > > Can you elaborate why the current idealized functionality of deposit -> > trigger -> withdrawal is too complicated for > everyday use but the above deposit -> withdrawal -> > resolve(claim/clawback) wouldn't be? I admit at a high level > it's a fine paradigm, but in practice would end > > Let's ignore implementation for the discussion, since that's in flux. > > Cheers, > Greg > > On Sat, Mar 11, 2023 at 3:53 PM Luke Dashjr via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I started reviewing the BIP, but stopped part way through, as it seems >> to have a number of conceptual issues. >> >> I left several comments on the PR >> (https://github.com/bitcoin/bips/pull/1421#pullrequestreview-1335925575), >> >> but ultimately I think it isn't simplified enough for day-to-day use, >> and would harm privacy quite a bit. >> >> Instead, I would suggest a new approach where: >> >> 1) Joe receives funds with a taproot output like normal. >> 2) Joe sends funds to Fred, but Fred cannot spend them until N blocks >> later (covenant-enforced relative locktime). Ideally, this should >> use/support a taproot keypath spend somehow. It would be nice to blind >> the particular relative locktime somehow too, but that may be too >> expensive. >> 2b) If Joe's funds were stolen, Joe can spend Fred's UTXO within the N >> block window to a recovery output. >> >> Unfortunately, the implementation details for this kind of setup are >> non-obvious and will likely require yet another address format (or at >> least recipient-wallet changes), but certainly seems within the scope of >> possibility. >> >> Thoughts? >> >> Luke >> >> >> On 2/13/23 16:09, James O'Beirne via bitcoin-dev wrote: >> > Since the last related correspondence on this list [0], a number of >> > improvements have been made to the OP_VAULT draft [1]: >> > >> > * There is no longer a hard dependence on package relay/ephemeral >> > anchors for fee management. When using "authorized recovery," all >> > vault-related transactions can be bundled with unrelated inputs and >> > outputs, facilitating fee management that is self contained to the >> > transaction. Consequently, the contents of this proposal are in theory >> > usable today. >> > >> > * Specific output locations are no longer hardcoded in any of the >> > transaction validation algorithms. This means that the proposal is now >> > compatible with future changes like SIGHASH_GROUP, and >> > transaction shapes for vault operations are more flexible. >> > >> > --- >> > >> > I've written a BIP that fully describes the proposal here: >> > >> > >> https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawiki >> > >> > The corresponding PR is here: >> > >> > https://github.com/bitcoin/bips/pull/1421 >> > >> > My next steps will be to try for a merge to the inquisition repo. >> > >> > Thanks to everyone who has participated so far, but especially to AJ and >> > Greg for all the advice. >> > >> > James >> > >> > [0]: >> > >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html >> > [1]: https://github.com/bitcoin/bitcoin/pull/26857 >> > >> > ___ >> > 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 >> > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP for OP_VAULT
Hi Luke, Can you elaborate why the current idealized functionality of deposit -> trigger -> withdrawal is too complicated for everyday use but the above deposit -> withdrawal -> resolve(claim/clawback) wouldn't be? I admit at a high level it's a fine paradigm, but in practice would end Let's ignore implementation for the discussion, since that's in flux. Cheers, Greg On Sat, Mar 11, 2023 at 3:53 PM Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I started reviewing the BIP, but stopped part way through, as it seems > to have a number of conceptual issues. > > I left several comments on the PR > (https://github.com/bitcoin/bips/pull/1421#pullrequestreview-1335925575), > but ultimately I think it isn't simplified enough for day-to-day use, > and would harm privacy quite a bit. > > Instead, I would suggest a new approach where: > > 1) Joe receives funds with a taproot output like normal. > 2) Joe sends funds to Fred, but Fred cannot spend them until N blocks > later (covenant-enforced relative locktime). Ideally, this should > use/support a taproot keypath spend somehow. It would be nice to blind > the particular relative locktime somehow too, but that may be too > expensive. > 2b) If Joe's funds were stolen, Joe can spend Fred's UTXO within the N > block window to a recovery output. > > Unfortunately, the implementation details for this kind of setup are > non-obvious and will likely require yet another address format (or at > least recipient-wallet changes), but certainly seems within the scope of > possibility. > > Thoughts? > > Luke > > > On 2/13/23 16:09, James O'Beirne via bitcoin-dev wrote: > > Since the last related correspondence on this list [0], a number of > > improvements have been made to the OP_VAULT draft [1]: > > > > * There is no longer a hard dependence on package relay/ephemeral > > anchors for fee management. When using "authorized recovery," all > > vault-related transactions can be bundled with unrelated inputs and > > outputs, facilitating fee management that is self contained to the > > transaction. Consequently, the contents of this proposal are in theory > > usable today. > > > > * Specific output locations are no longer hardcoded in any of the > > transaction validation algorithms. This means that the proposal is now > > compatible with future changes like SIGHASH_GROUP, and > > transaction shapes for vault operations are more flexible. > > > > --- > > > > I've written a BIP that fully describes the proposal here: > > > > > https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawiki > > > > The corresponding PR is here: > > > > https://github.com/bitcoin/bips/pull/1421 > > > > My next steps will be to try for a merge to the inquisition repo. > > > > Thanks to everyone who has participated so far, but especially to AJ and > > Greg for all the advice. > > > > James > > > > [0]: > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html > > [1]: https://github.com/bitcoin/bitcoin/pull/26857 > > > > ___ > > 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 > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP for OP_VAULT
I started reviewing the BIP, but stopped part way through, as it seems to have a number of conceptual issues. I left several comments on the PR (https://github.com/bitcoin/bips/pull/1421#pullrequestreview-1335925575), but ultimately I think it isn't simplified enough for day-to-day use, and would harm privacy quite a bit. Instead, I would suggest a new approach where: 1) Joe receives funds with a taproot output like normal. 2) Joe sends funds to Fred, but Fred cannot spend them until N blocks later (covenant-enforced relative locktime). Ideally, this should use/support a taproot keypath spend somehow. It would be nice to blind the particular relative locktime somehow too, but that may be too expensive. 2b) If Joe's funds were stolen, Joe can spend Fred's UTXO within the N block window to a recovery output. Unfortunately, the implementation details for this kind of setup are non-obvious and will likely require yet another address format (or at least recipient-wallet changes), but certainly seems within the scope of possibility. Thoughts? Luke On 2/13/23 16:09, James O'Beirne via bitcoin-dev wrote: Since the last related correspondence on this list [0], a number of improvements have been made to the OP_VAULT draft [1]: * There is no longer a hard dependence on package relay/ephemeral anchors for fee management. When using "authorized recovery," all vault-related transactions can be bundled with unrelated inputs and outputs, facilitating fee management that is self contained to the transaction. Consequently, the contents of this proposal are in theory usable today. * Specific output locations are no longer hardcoded in any of the transaction validation algorithms. This means that the proposal is now compatible with future changes like SIGHASH_GROUP, and transaction shapes for vault operations are more flexible. --- I've written a BIP that fully describes the proposal here: https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawiki The corresponding PR is here: https://github.com/bitcoin/bips/pull/1421 My next steps will be to try for a merge to the inquisition repo. Thanks to everyone who has participated so far, but especially to AJ and Greg for all the advice. James [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html [1]: https://github.com/bitcoin/bitcoin/pull/26857 ___ 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
Re: [bitcoin-dev] BIP for OP_VAULT
On 10 March 2023 4:45:15 am AEST, Greg Sanders via bitcoin-dev wrote: >1) OP_FORWARD_SELF is a JET of OP_FLU in the revaulting common case. Maybe >obvious but I missed this initially and thought it was useful to be pointed >out. That was true for TLUV - iirc "FALSE FALSE 0 TLUV" would preserve the spk - but I don't think it's true for OP_FLU: you can't commit to preserving the current script without a way to observe the current script; trying to include a copy of the script in the script makes the script size infinite, and trying to include a hash of the script inside the script is cryptographically infeasible. You could just special case "0 0 OP_FLU" to result in the same script rather than an empty one though, which would avoid the need for a dedicated FWD_SELF opcode. (Not convinced calling things Jets when they're unrelated to simplicity makes sense) Cheers, aj -- Sent from my phone. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP for OP_VAULT
AJ,
Interesting stuff! Just a couple thoughts on these proposed opcodes, at
least one we discussed elsewhere:
1) OP_FORWARD_SELF is a JET of OP_FLU in the revaulting common case. Maybe
obvious but I missed this initially and thought it was useful to be pointed
out.
2) Using these extended primitives, you can do rate-limiting of the two
step unvaulting, or just a single step vault by committing to the partial
values. For the single stage case it's something like:
$recovery = Same As Before
$withdrawal = OP_CSV OP_DROP OP_CHECKSIG OP_DUP
OP_LESSTHANOREQUAL OP_VERIFY OP_FORWARD_PARTIAL OP_FORWARD_TARGET
OP_FORWARD_SELF
$withdrawal is spent by:
<0<=v<=V>
where "V" is the max allowed withdrawal value, and "deposit-delay" the
required gap in withdrawals
Due to the OP_LEQ, you are bound to ~21 BTC in value for this operation,
but for larger vaults it's pretty trivial to add larder fixed denominations
to "peel out" value until you get to your final ~21 BTC.
This rate-limiting(in either the two-stage or one-stage scheme) can limit
the risk of theft during a watchtower outage to a constant value per utxo
per time period of watchtower failure. As we've seen in the past with LN
infrastructure, software risks are often correlated, so it's a good idea to
build in belt and suspenders where we can or at least have them available
when possible.
Cheers,
Greg
On Tue, Mar 7, 2023 at 7:45 AM Anthony Towns wrote:
> On Mon, Mar 06, 2023 at 10:25:38AM -0500, James O'Beirne via bitcoin-dev
> wrote:
> > What Greg is proposing above is to in essence TLUV-ify this proposal.
>
> FWIW, the way I'm thinking about this is that the "OP_VAULT" concept is
> introducing two things:
>
> a) the concept of "forwarding" the input amount to specified
> outputs in a way that elegantly allows merging/splitting
>
> b) various restrictions on the form of the output scripts
>
> These concepts go together well, because restricting an output script is
> only an interesting thing to do if you're moving value from this input
> into it. And then it's just a matter of figuring out a nice way to pick
> opcodes that combine those two concepts in interesting ways.
>
> This is different from TLUV, in that TLUV only did part (b), and
> assumed you'd do part (a) manually somehow, eg via "OP_IN_OUT_AMOUNT"
> and arithmetic opcodes. The advantage of this new approach over that
> one is that it makes it really easy to get the logic right (I often
> forgot to include the IN_OUT_AMOUNT checks at all, for instance), and
> also makes spending multiple inputs to a single output really simple,
> something that would otherwise require kind-of gnarly logic.
>
> 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.
>
> Then each time you see OP_FORWARD_TARGET or OP_FORWARD_LEAF_UPDATE, you
> accumulate the value that's expected to be forwarded to the output by
> each input, and verify that the amount for that output is greater-or-equal
> to the accumulated value.
>
> > ## Required opcodes
> > - OP_VAULT: spent to trigger withdrawal
> > - OP_VAULT_RECOVER: spent to recover
>
> Naming here is OP_VAULT ~= OP_FORWARD_LEAF_UPDATE; OP_VAULT_RECOVER ~=
> OP_FORWARD_TARGET.
>
> > For each vault, vaulted coins are spent to an output with the taproot
> > structure
> >
> > taproot(internal_key, {$recovery_leaf, $trigger_leaf, ...})
> >
> > where
> >
> > $trigger_leaf =
> >
Re: [bitcoin-dev] BIP for OP_VAULT
On Mon, Mar 06, 2023 at 10:25:38AM -0500, James O'Beirne via bitcoin-dev wrote:
> What Greg is proposing above is to in essence TLUV-ify this proposal.
FWIW, the way I'm thinking about this is that the "OP_VAULT" concept is
introducing two things:
a) the concept of "forwarding" the input amount to specified
outputs in a way that elegantly allows merging/splitting
b) various restrictions on the form of the output scripts
These concepts go together well, because restricting an output script is
only an interesting thing to do if you're moving value from this input
into it. And then it's just a matter of figuring out a nice way to pick
opcodes that combine those two concepts in interesting ways.
This is different from TLUV, in that TLUV only did part (b), and
assumed you'd do part (a) manually somehow, eg via "OP_IN_OUT_AMOUNT"
and arithmetic opcodes. The advantage of this new approach over that
one is that it makes it really easy to get the logic right (I often
forgot to include the IN_OUT_AMOUNT checks at all, for instance), and
also makes spending multiple inputs to a single output really simple,
something that would otherwise require kind-of gnarly logic.
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.
Then each time you see OP_FORWARD_TARGET or OP_FORWARD_LEAF_UPDATE, you
accumulate the value that's expected to be forwarded to the output by
each input, and verify that the amount for that output is greater-or-equal
to the accumulated value.
> ## Required opcodes
> - OP_VAULT: spent to trigger withdrawal
> - OP_VAULT_RECOVER: spent to recover
Naming here is OP_VAULT ~= OP_FORWARD_LEAF_UPDATE; OP_VAULT_RECOVER ~=
OP_FORWARD_TARGET.
> For each vault, vaulted coins are spent to an output with the taproot
> structure
>
> taproot(internal_key, {$recovery_leaf, $trigger_leaf, ...})
>
> where
>
> $trigger_leaf =
>
Re: [bitcoin-dev] BIP for OP_VAULT
Hi James, I think everything except the hinted "withdrawal authorization" is spot on. For withdrawal authorization, I think we'll have to go deeper into the TLUV direction as AJ suggested for at least a couple reasons: 1) You need the withdrawal authorization committed at deposit time 2) You need to make sure cheeky opcodes cannot be prepended to the script at spend time OP_FORWARD_LEAF_UPDATE(OP_FLU) seems to fit the bill, at the cost of maybe adding another opcode for "refunds" as he notes. Cheers, Greg On Mon, Mar 6, 2023 at 10:25 AM James O'Beirne wrote: > I'm glad to see that Greg and AJ are forming a habit of hammering > this proposal into shape. Nice work fellas. > > To summarize: > > What Greg is proposing above is to in essence TLUV-ify this proposal. > > I.e. instead of relying on hashed commitments and recursive script > execution (e.g. + later presentation of preimage > script for execution), OP_VAULT would instead move through its > withdrawal process by swapping out tapleaf contents according to > specialized rules. If this is opaque (as it was to me), don't fret - > I'll describe it below in the "mechanics" section. > > > The benefits of this TLUVification are > > - we can avoid any nested/recursive script execution. I know the > recursive stuff rankles some greybeards even in spite of it being > bounded to a single call. I'm not sure I share the concern but > maintaining the status quo seems good. > > - the spec is easier to reason about, more or less. The opcodes > introduced don't have variadic witness requirements, and each opcode > is only consumed in a single way. > > - there's less general indirection. Instead of saying "okay, here's the > hash of the script I'm going to use to authorize trigger > transactions," we're just outright including the trigger auth script > in the tapleaf at the birth of the vault as regular 'ol script that is > evaluated before execution of the OP_VAULT instruction. > > Similarly, instead of relying on an implicit rule that an OP_VAULT can > be claimed by a recovery flow, we're relying on a specific tapleaf that > facilitates that recovery with OP_VAULT_RECOVER, described below. > > Basically, OP_VAULT would just be implemented in a way that feels > more native to Taproot primitives. > > Greg also introduces different opcodes to facilitate consistent > witness structure, rather than the variable ones we have now > since OP_VAULT and OP_UNVAULT can each be spent in two different > contexts. I've changed those a little here; instead of the three general > ones Greg gave, we whittled it down to two: OP_VAULT and > OP_VAULT_RECOVER. > > > So I think that, barring significant implementation complexity - which > I'll find out about soon and don't expect - this is a good change to the > proposal. As Greg noted, it doesn't really change anything about the > usage or expressiveness... other than the fact that, as a bonus, it > might allow an optional withdrawal authorization script (i.e. trigger > output => final target), which could be useful if e.g. some kind of > size-limiting opcode (e.g. OP_TX_MAXSIZE or something) came around in > the future as a kind of pinning fix. > > If that last bit lost you, don't worry - that is speculative, but the > point is that this rework composes well with other stuff. > > > # CTV use > > Another thing that has dawned on us is that we might as well just reuse > OP_CHECKTEMPLATEVERIFY for withdrawal target spends. Ben Carmen and > others realized early on that you can synthesize CTV-like behavior by > spending to a 0-delay OP_UNVAULT output, so something CTVish has always > implicitly been a part of the proposal. But CTV is better studied and > basically as simple as the OP_UNVAULT spend semantics, so the thought is > that we might as well reuse all the existing work (and scrutiny) from > CTV. > > As a concrete example, an issue with the existing proposal is that the > existing CTVish OP_UNVAULT behavior has txid malleability, since it > doesn't commit to nVersion or nLockTime or the input sequences. Using > CTV solves this issue. Otherwise we'd basically reinvent it - "something > something convergent evolution." > > I think this is a satisfying development, because there's clearly demand > for CTV use in other contexts (DLC efficiency, e.g.), and if it's > required behavior for practical vaults, I think pulling in the existing > BIP-119 that's been worked over for years reduces the conceptual > surface area added by OP_VAULT. > > > # New mechanics of the proposal > > So here I'm going to describe my rendering of Greg and AJ's suggestions. > > > ## Required opcodes > > - OP_VAULT: spent to trigger withdrawal > - OP_VAULT_RECOVER: spent to recover > - OP_CHECKTEMPLATEVERIFY: spent into final withdrawal target > > > Creating an initial deposit > --- > > For each vault, vaulted coins are spent to an output with the taproot > structure > > taproot(internal_key,
Re: [bitcoin-dev] BIP for OP_VAULT
I'm glad to see that Greg and AJ are forming a habit of hammering
this proposal into shape. Nice work fellas.
To summarize:
What Greg is proposing above is to in essence TLUV-ify this proposal.
I.e. instead of relying on hashed commitments and recursive script
execution (e.g. + later presentation of preimage
script for execution), OP_VAULT would instead move through its
withdrawal process by swapping out tapleaf contents according to
specialized rules. If this is opaque (as it was to me), don't fret -
I'll describe it below in the "mechanics" section.
The benefits of this TLUVification are
- we can avoid any nested/recursive script execution. I know the
recursive stuff rankles some greybeards even in spite of it being
bounded to a single call. I'm not sure I share the concern but
maintaining the status quo seems good.
- the spec is easier to reason about, more or less. The opcodes
introduced don't have variadic witness requirements, and each opcode
is only consumed in a single way.
- there's less general indirection. Instead of saying "okay, here's the
hash of the script I'm going to use to authorize trigger
transactions," we're just outright including the trigger auth script
in the tapleaf at the birth of the vault as regular 'ol script that is
evaluated before execution of the OP_VAULT instruction.
Similarly, instead of relying on an implicit rule that an OP_VAULT can
be claimed by a recovery flow, we're relying on a specific tapleaf that
facilitates that recovery with OP_VAULT_RECOVER, described below.
Basically, OP_VAULT would just be implemented in a way that feels
more native to Taproot primitives.
Greg also introduces different opcodes to facilitate consistent
witness structure, rather than the variable ones we have now
since OP_VAULT and OP_UNVAULT can each be spent in two different
contexts. I've changed those a little here; instead of the three general
ones Greg gave, we whittled it down to two: OP_VAULT and
OP_VAULT_RECOVER.
So I think that, barring significant implementation complexity - which
I'll find out about soon and don't expect - this is a good change to the
proposal. As Greg noted, it doesn't really change anything about the
usage or expressiveness... other than the fact that, as a bonus, it
might allow an optional withdrawal authorization script (i.e. trigger
output => final target), which could be useful if e.g. some kind of
size-limiting opcode (e.g. OP_TX_MAXSIZE or something) came around in
the future as a kind of pinning fix.
If that last bit lost you, don't worry - that is speculative, but the
point is that this rework composes well with other stuff.
# CTV use
Another thing that has dawned on us is that we might as well just reuse
OP_CHECKTEMPLATEVERIFY for withdrawal target spends. Ben Carmen and
others realized early on that you can synthesize CTV-like behavior by
spending to a 0-delay OP_UNVAULT output, so something CTVish has always
implicitly been a part of the proposal. But CTV is better studied and
basically as simple as the OP_UNVAULT spend semantics, so the thought is
that we might as well reuse all the existing work (and scrutiny) from
CTV.
As a concrete example, an issue with the existing proposal is that the
existing CTVish OP_UNVAULT behavior has txid malleability, since it
doesn't commit to nVersion or nLockTime or the input sequences. Using
CTV solves this issue. Otherwise we'd basically reinvent it - "something
something convergent evolution."
I think this is a satisfying development, because there's clearly demand
for CTV use in other contexts (DLC efficiency, e.g.), and if it's
required behavior for practical vaults, I think pulling in the existing
BIP-119 that's been worked over for years reduces the conceptual
surface area added by OP_VAULT.
# New mechanics of the proposal
So here I'm going to describe my rendering of Greg and AJ's suggestions.
## Required opcodes
- OP_VAULT: spent to trigger withdrawal
- OP_VAULT_RECOVER: spent to recover
- OP_CHECKTEMPLATEVERIFY: spent into final withdrawal target
Creating an initial deposit
---
For each vault, vaulted coins are spent to an output with the taproot
structure
taproot(internal_key, {$recovery_leaf, $trigger_leaf, ...})
where
internal_key =
unchanged from original proposal (some very safe recovery key)
$recovery_leaf =
[ ] OP_VAULT_RECOVER
$trigger_leaf =
Re: [bitcoin-dev] BIP for OP_VAULT
I read the draft and this seems to have some functionality that I am looking for. I'm pretty new to bitcoin-dev, but I'm persistent and have a lot of time on my hands. I would like multiple tapleaves be restricted on the amount that they can spend. Say an input of 1 BTC, has a locking script of a tapscript that has 1 of 3 pubkeys of Alice, Bob and Carol(participants). I want to restrict the outputs of their next transactions to .2, .3 and .5 BTC respectively. In the event of Bob spending their output, they are restricted to make a transaction that has a change output that has at least Alice and Carol's Amount, and a 1 or 2 tapscript or a 1 of 3 tapscript if Bob didn't spend all of their funds. In the event of two of the three participants separately broadcast their transactions, I'm hoping that the second sender, can combine the two transactions into a package where the outputs and witnesses would be adjusted where two participants share an output with their respective amounts, and the remainder participant still has their funds available. Is this clear? I don't have a lot of experience communicating complex ideas in writing. I've been looking at some BIP's like OP_CHECKTEMPLATEVERIFY as well which had some idea's I really liked like OP_AMOUNTVERIFY. I'm not aware of the risks that the community previously discussed about the topic. Andrew Sent with [Proton Mail](https://proton.me/) secure email. --- Original Message --- On Thursday, March 2nd, 2023 at 6:54 AM, Greg Sanders via bitcoin-dev wrote: > Greetings AJ, > > Glad I could resurrect the idea! > >> Then instead of `idx hash delay OP_TRIGGER_FORWARD` you > write `idx hash delay 2 "OP_CSV OP_DROP OP_FORWARD_OUTPUTS" > OP_FORWARD_LEAF_UPDATE` > > Interesting idea! (I'll let you be the one to scope creep the proposal :) ) > > To be pedantic, EXPR_TRIGGER would become: > > <2> OP_FORWARD_OUTPUTS> OP_FORWARD_LEAF_UPDATE > > and at spend time the idx and hash are put into the witness stack. > > To be clear, could be embedded in the
Re: [bitcoin-dev] BIP for OP_VAULT
Greetings AJ, Glad I could resurrect the idea! > Then instead of `idx hash delay OP_TRIGGER_FORWARD` you write `idx hash delay 2 "OP_CSV OP_DROP OP_FORWARD_OUTPUTS" OP_FORWARD_LEAF_UPDATE` Interesting idea! (I'll let you be the one to scope creep the proposal :) ) To be pedantic, EXPR_TRIGGER would become: <2> OP_FORWARD_LEAF_UPDATE and at spend time the idx and hash are put into the witness stack. To be clear, could be embedded in the
Re: [bitcoin-dev] BIP for OP_VAULT
On Wed, Mar 01, 2023 at 10:05:47AM -0500, Greg Sanders via bitcoin-dev wrote:
> Below is a sketch of a replacement for the two opcodes.
I like this! I tried to come up with something along similar lines for
similar reasons, but I think I tried too hard to reduce it to two opcodes
or something and got myself confused.
> `OP_TRIGGER_FORWARD`: Takes exactly three arguments:
> 1) output index to match against (provided at spend time normally)
> 2) target-outputs-hash: 32 byte hash to be forwarded to output given at (1)
> (provided at spend time normally)
> 3) spend-delay: value to be forwarded to output given at (1)
I think you could generalise this as follows:
idx .. npush script OP_FORWARD_LEAF_UPDATE
(OP_FLU :) with the behaviour being:
pop script from the stack
pop npush from the stack (error if non-minimal or <0)
pop npush entries from the stack,
prefix script with a minimal push of that entry
pop idx off the stack (error if idx is not a valid output)
calculate the spk corresponding to taking the current
input's spk and replacing the current leaf with the
given script
check the output at idx matches this spk, and the
value from this input accumulates to that output
Then instead of `idx hash delay OP_TRIGGER_FORWARD` you
write `idx hash delay 2 "OP_CSV OP_DROP OP_FORWARD_OUTPUTS"
OP_FORWARD_LEAF_UPDATE`
That's an additional 5 witness bytes, but a much more generic/composable
opcode.
Being able to prefix a script with push opcodes avoids the possibility
of being able to add OP_SUCCESS instructions, so I think this is a fairly
safe way of allowing a TLUV-ish script to be modified, especially compared
to OP_CAT.
I do recognise that it makes it take a variable number of stack elements
though :)
> As the derived tapscript, embedded in a output scriptpubkey of the form:
> `tr(NUMS,{...,EXPR_WITHDRAW})`, meaning we literally take the control block
> from the spending input, swap the inner pubkey for `NUMS`, use
> `EXPR_WITHDRAW` as the tapleaf, reconstruct the merkle root. If the output
> scriptpubkey doesnt match, fail.
I don't think replacing the internal-public-key makes sense -- if it
was immediately spendable via the keypath before there's no reason for
it not to be immediately spendable now.
> Could save 2 WU having OP_FORWARD_OUTPUTS take the directly
> as an argument, or keep it more general as I did.
Having OP_FORWARD_OUTPUTS not leave its input on the stack would let
you move the OP_CSV to the end and drop the OP_DROP too, saving 1 WU.
> Would love to know what you and others think about this direction. I
> apologies for any misunderstandings I have about the current OP_VAULT BIP!
I think the existing OP_VAULT cleverness would work here, allowing you
to spend two inputs to the same output, accumulating their values.
I don't think it quite gives you a way to "refund" values though -- so
that you can take a vault with 3 BTC, start the wait to spend
1.4 BTC, and then immediately decide to spend an additional 0.8 BTC on
something else, without the 0.8 BTC effectively having a doubled delay.
I think you could fix that with something as simple as an additional
"idx OP_FORWARD_REFUND" opcode, though -- then the restriction is just
that the output at the refund idx has the same sPK as this input, and
the total value of this input is accumulated amongst all the outputs
specified by OP_FORWARD opcodes. (Maybe you need to specify the refund
amount explicitly as well, to keep verification easy)
That would make maybe three new opcodes to cover the "accumulate value
from one or more inputs into specified outputs":
- OP_FORWARD_LEAF_UPDATE --> forward input value to modified spk
- OP_FORWARD_DESTINATION --> forward input value to given spk
- OP_FORWARD_REFUND --> forward part of input value to same spk
along with OP_CTV:
- OP_FORWARD_OUTPUTS --> pay to specific outputs
OP_VAULT's "accumulate value" behaviour here makes the OP_IN_OUT_AMOUNT
things from TLUV more implicit and automatic, which is nice. I think
doing TLUV payment pools wouldn't require much more than the ability to
combine OP_FLU and OP_FDEST in a single script, explicitly specifying
how much value is extracted via OP_FDEST with the rest assigned to OP_FLU.
Cheers,
aj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP for OP_VAULT
Hello James,
First off, thank you for crafting an interesting idea like this that is
aimed at solving a serious problem. I see a lot of excitement about the use
cases, and I think it's worth iterating on.
Attempting to keep the idealized functionality constant, I'd like to
explore a design detour. I'm attempting to decouple the 3 functionalities
of `OP_VAULT` and `OP_UNVAULT` into their constituent functions with names
I just made up.
The goals of this e-mail:
1) Removing variable number of arguments based on values of arguments for
the opcodes.
To me as a spec reader, I find it very difficult to parse what's precisely
happening when. I think the only/last opcode to support this behavior was
OP_CHECKMULTISIG(could be wrong), and now I know another reason why OP_CSA
construct is nicer going forward with taproot.
2) Remove the recursive evaluation functionality used for authentication,
without reducing the efficacy of the targeted solution. Recursive
evaluation has a fraught history in Bitcoin script, makes composing
functionality with tooling likely more difficult, and has a lot of
templated behavior. If we can rely on regular old tapscript to get us where
we need to go, I'd prefer that.
3) Increase legibility of the spec. There's a ton going on, breaking things
up and naming them based on the method rather than the goal may help here.
4) Not (greatly) increase the expressiveness of the proposal. It's a
targeted proposal, and I'd like to respect that. These covenant opcodes are
intended to be drop-in replacements for the OP_(UN)VAULT opcodes.
To recap, there are three things happen in idealized OP_VAULT scenario:
1) Money comes out, then has to wait (trigger transaction)
2) Money waits long enough, then withdrawals to dynamic set of outputs that
are declared at trigger time (withdrawal transaction)
3) Money to single specified output script picked up front, with no wait
(recovery)
Below is a sketch of a replacement for the two opcodes. Ignore my
inconsistency on VERIFY/non-VERIFY behavior, seeing if people agree with
this general direction:
`OP_TRIGGER_FORWARD`: Takes exactly three arguments:
1) output index to match against (provided at spend time normally)
2) target-outputs-hash: 32 byte hash to be forwarded to output given at (1)
(provided at spend time normally)
3) spend-delay: value to be forwarded to output given at (1)
Fails script immediately if there aren't enough inputs or they're the wrong
format.
These last two arguments are "forwarded" to output at index declared in
first argument, resulting in:
`EXPR_WITHDRAW: OP_CHECKSEQUENCEVERIFY OP_DROP
OP_FORWARD_OUTPUTS`
As the derived tapscript, embedded in a output scriptpubkey of the form:
`tr(NUMS,{...,EXPR_WITHDRAW})`, meaning we literally take the control block
from the spending input, swap the inner pubkey for `NUMS`, use
`EXPR_WITHDRAW` as the tapleaf, reconstruct the merkle root. If the output
scriptpubkey doesnt match, fail.
This TLUV-ish script/inner pubkey replacement is meant to allow arbitrary
other conditions, which is where the "recovery" path comes in for typical
usage.
If output at the target output index doesn't match the constructed script,
the evaluation fails.
`OP_FORWARD_DESTINATION`: Takes exactly two arguments:
1) `dest-vout-idx`: index of output that contains the so-called "recovery"
path
2) : the hash of the script destination
Fails immediately if the reconstructed output script doesn't match.
`OP_FORWARD_OUTPUTS` takes exactly one argument:
1) target-outputs-hash: commits to all outputs' scripts and values
Fails immediately if transaction's outputs(including value) hash doesn't
match.
**Typical usage**:
```
DEPOSITING TO VAULT SCRIPT:
EXPR_RECOVERY: OP_FORWARD_DESTINATION
EXPR_TRIGGER: OP_TRIGGER_FORWARD
tr(KEY, {EXPR_RECOVERY, EXPR_TRIGGER})
```
```
EXPR_WITHDRAW: OP_CHECKSEQUENCEVERIFY OP_DROP
OP_FORWARD_OUTPUTS
```
```
TRIGGERING WITHDRAWAL TIMER SCRIPT:
tr(NUMS, {EXPR_RECOVERY,EXPR_WITHDRAW}) <--- note EXPR_RECOVERY is forced
by the OP_TRIGGER_FORWARD TLUV action
```
Could save 2 WU having OP_FORWARD_OUTPUTS take the directly
as an argument, or keep it more general as I did.
Would love to know what you and others think about this direction. I
apologies for any misunderstandings I have about the current OP_VAULT BIP!
Cheers,
Greg
On Mon, Feb 13, 2023 at 4:09 PM James O'Beirne via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Since the last related correspondence on this list [0], a number of
> improvements have been made to the OP_VAULT draft [1]:
>
> * There is no longer a hard dependence on package relay/ephemeral
> anchors for fee management. When using "authorized recovery," all
> vault-related transactions can be bundled with unrelated inputs and
> outputs, facilitating fee management that is self contained to the
> transaction. Consequently, the contents of this proposal are in theory
> usable today.
>
> * Specific output locations are no
[bitcoin-dev] BIP for OP_VAULT
Since the last related correspondence on this list [0], a number of improvements have been made to the OP_VAULT draft [1]: * There is no longer a hard dependence on package relay/ephemeral anchors for fee management. When using "authorized recovery," all vault-related transactions can be bundled with unrelated inputs and outputs, facilitating fee management that is self contained to the transaction. Consequently, the contents of this proposal are in theory usable today. * Specific output locations are no longer hardcoded in any of the transaction validation algorithms. This means that the proposal is now compatible with future changes like SIGHASH_GROUP, and transaction shapes for vault operations are more flexible. --- I've written a BIP that fully describes the proposal here: https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawiki The corresponding PR is here: https://github.com/bitcoin/bips/pull/1421 My next steps will be to try for a merge to the inquisition repo. Thanks to everyone who has participated so far, but especially to AJ and Greg for all the advice. James [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html [1]: https://github.com/bitcoin/bitcoin/pull/26857 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
