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] Minimum fees
Hi Giuseppe, One side-effect this has is that until enough fees accumulate in the mempool to satisfy min_fees, the rational behaviour for miners would be to try and fork the chain tip, competing for the fees in the latest block (+whatever got into the mempool in the meanwhile and can fit in). This could lead to increased reorgs/orphan rates and chain instability. It could also lead to miners preferring to set their low_fee to zero, to avoid other miners from forking their blocks off. I'm also not sure that this would actually change much. If humanity is willing to spend X BTC/day on mining fees, it doesn't really matter if it's spread out through fewer or more blocks. shesek On Wed, Mar 1, 2023 at 10:25 PM Giuseppe B via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello everyone, > > I'm relatively new here so what I'm proposing could have already been > discussed, or may be flawed or inapplicable. I apologize for that. > > I was picturing a situation where block rewards are almost zero, and the > base layer is mainly used as a settlement layer for relatively few large > transactions, since the majority of smaller ones goes through LN. > > In such a case it may very well be that even if transaction amounts are > very consistent, transaction fees end up being very small since there is > enough space for everyone in a block. Users wouldn't mind paying higher > fees as they know that that would increase the network security, however > nobody wants to be the only one doing that. Miners would of course like > being paid more. So everyone involved would prefer higher fees but they > just stay low because that's the only rational individual choice. > > Therefore I was imagining the introduction of a new protocol rule, > min_fees, that would work like this: > - the miner that gets to mine a block appends a min_fee field to the > block, specifying the minimum fees that need to be contained in the > following block in order for it to be valid. > - one can also mine an empty block and reset the min_fee, to avoid the > chain getting stuck. > > min_fees could either represent the total fees of the following block, or > the minimal fee for each single transaction, as a percentage of the value > transacted. Both seem to have some merits and some potential drawbacks. Of > course min_fees=0 would correspond to the current situation. > > It looks to me that this could have the potential to bring the equilibrium > closer to a socially optimal one (as opposed to individually optimal), and > to benefit the network security in the long term. Of course it's just a > rough sketch and it would deserve a much deeper analysis. I was just > interested in knowing if you think that the principle has some merit or if > it's not even worth discussing it for some reason that I'm not considering. > > Cheers, > > Giuseppe. > > ___ > 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] Minimum fees
Hello everyone, I'm relatively new here so what I'm proposing could have already been discussed, or may be flawed or inapplicable. I apologize for that. I was picturing a situation where block rewards are almost zero, and the base layer is mainly used as a settlement layer for relatively few large transactions, since the majority of smaller ones goes through LN. In such a case it may very well be that even if transaction amounts are very consistent, transaction fees end up being very small since there is enough space for everyone in a block. Users wouldn't mind paying higher fees as they know that that would increase the network security, however nobody wants to be the only one doing that. Miners would of course like being paid more. So everyone involved would prefer higher fees but they just stay low because that's the only rational individual choice. Therefore I was imagining the introduction of a new protocol rule, min_fees, that would work like this: - the miner that gets to mine a block appends a min_fee field to the block, specifying the minimum fees that need to be contained in the following block in order for it to be valid. - one can also mine an empty block and reset the min_fee, to avoid the chain getting stuck. min_fees could either represent the total fees of the following block, or the minimal fee for each single transaction, as a percentage of the value transacted. Both seem to have some merits and some potential drawbacks. Of course min_fees=0 would correspond to the current situation. It looks to me that this could have the potential to bring the equilibrium closer to a socially optimal one (as opposed to individually optimal), and to benefit the network security in the long term. Of course it's just a rough sketch and it would deserve a much deeper analysis. I was just interested in knowing if you think that the principle has some merit or if it's not even worth discussing it for some reason that I'm not considering. Cheers, Giuseppe. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Fee-redistribution contracts
On 2023-02-27 03:32, Rastislav Budinsky via bitcoin-dev wrote: When a miner mines a block he takes all the fees currently. However with the proposed solution he takes only fraction M and remaining fraction C is sent to one of more contracts. One contract at its simplest collects fees from the miner and at the same time redistributes it back to the miner. Hi Rastislav, I think you've incorrectly made the assumption that the only way a miner can profit from confirming a transaction is by collecting its transaction fees. Miners can (and many have) accept payment through alternative means, which the Bitcoin technical community often calls "out-of-band fees".[1] For example, some miners have provided a "transaction accelerator" service that accepts fiat-denominated credit cards to increase their prioritization of certain transactions and I'm personally aware of a large web wallet provider that would occasionally pay miners out of band to confirm hundreds or thousands of transactions rather than fix its broken fee estimation. Out-of-band fees aren't frequently used in Bitcoin today because they have no advantage over correctly estimated in-band fees, and good fee estimation is very accessible to modern wallets. However, if the consensus rules are changed to require each miner pay a percentage of its in-band fees to future miners, then there would be a strong incentive for them to prefer out-of-band fees that weren't subject to this redistribution scheme. I think may have seen a variation on the scheme you propose play out in real life. Here's how it works where I live: the government imposes taxes on goods, services, and income. Ostensibly, it redistributes the collected funds back to citizens in the future by providing government services. When I go to pay someone who trusts my discretion, they often offer me a discounted rate if I pay in a way that isn't reported to the government (e.g., I pay with cash); even with the discount provided to me, they get to keep more of their income than if they had reported the transaction to the government. In the case of a government, tax evasion can be reduced by the deployment of investigators and enforcers. In Bitcoin, we have no control over activity that happens outside of the protocol and so even a modest incentive to pay fees out of band might quickly lead to almost all fees being paid out of band. This prevents the effective redistribution of fees as in your proposal. Additionally, previous discussions on this mailing list about paying out-of-band fees have highlighted that larger miners have an advantage over smaller miners in collecting miner-specific fee payments, undermining the essential decentralization of Bitcoin's transaction confirmation mechanism (moreso than it is already weakened by fundamental economies of scale in mining). In short, I think serious consideration of your proposal can only proceed if it adequately addresses the problem of out-of-band fees. That said, thank you and your co-authors for putting serious thought into Bitcoin's long-term economic incentives. -Dave [1] https://bitcoinsearch.xyz/?q=out%20of%20band%20fees=n_50_n ___ 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
