📅 Original date posted:2022-04-21
📝 Original message:Hi Russell,
Thank you for your feedback here.
> However, I'm still skeptical of the bare-CTV part of BIP-119 (and I'm told
> that bare-CTV hasn't even appeared on the CTV signet). Unlike the general
> smart-contracting case, bare-CTV does not have any branches. All it can do
> is commit to a subsequent transaction's outputs. At first glance this
> appears to be a waste because, for less bandwidth, that transaction could
> just realize those outputs immediately, so why would anyone want to delay
> the inevitable?
>
I can probably make some show up sometime soon. Note that James' vault uses
one at the top-level https://github.com/jamesob/simple-ctv-vault, but I
think the second use of it (since it's not segwit wrapped) wouldn't be
broadcastable since it's nonstandard.
>
> One reason might be that you want to commit to the output early during a
> high-fee time, and then complete the transaction later during a low-fee
> time. While there are fee-rate situations where this could result in lower
> fees than committing to the outputs all at once, it would be even cheaper
> still to just wait to do the payout at the low-fee time. I'm struggling to
> understand the advantages of the advanced commitment, along with all the
> overhead that entails. Doesn't it just cause more blockspace to be used
> overall?
>
One case where you actually use less space is if you have a few different
sets of customers at N different fee priority level. Then, you might need
to have N independent batches, or risk overpaying against the customer's
priority level. Imagine I have 100 tier 1 customers and 1000 tier 2
customers. If I batcher tier 1 with tier 2, to provide tier 1 guarantees
I'd need to pay tier 1 rate for 10x the customers. With CTV, I can combine
my batch into a root and N batch outputs. This eliminates the need for
inputs, signatures, change outputs, etc per batch, and can be slightly
smaller. Since the marginal benefit on that is still pretty small, having
bare CTV improves the margin of byte wise saving.
I give this as an example where CTV uses less space, it is detailed more
here: https://utxos.org/analysis/batching_sim/. This benefit might be
marginal and absurd, given these are already big transactions, but it may
_also_ be absurd that feerates only ever go up and congestion control is
not valuable.
Another example where this arises is where you have a transaction set you
need to pay top-of-mempool rate for the soonest confirmation you can get.
CTV has a decongesting effect, because your top-of-mempool transaction is
small, which doesn't trigger as much rivalrous behavior with other
transactors. Concretely, the current policy max txn size is 100kb, or 10%
of a block. If you bump out of next block window 10% of the mempool, then
if those transactors care to maintain their positioning, they will need to
put themselves into a higher percentile with e.g. RBF or CPFP. Whereas if
you put in a transaction that is just 100 bytes, you only bump out 100
bytes of rivals (0.01%), not 10%.
Lastly, perhaps a more realistic scenario, is where I am batching to 100
customers who all wish to do something else after I pay them. E.g., open a
lightning channel. Being able to use CTV noninteractive channels cuts
through the extra hop transaction (unless dual funded channels, unless the
channels are opened between two customers, then they can be dual funded
again). So using CTV here also saves in net blockspace (although, note,
this is sort of orthogonal to using CTV over the batch itself, just a good
example for the related question of 'doesn't ctv generally use more
blockspace').
> There are some other proposed use cases for bare-CTV. A bare-CTV can be
> used to delay a "trigger"-transaction. Some contracts, such as vaults, use
> a relative-locktime as part of their construction and it could make sense
> to make an output commitment but not realize those outputs yet until you
> are ready to start your relative-time lock clock. But bare-CTV doesn't
> support any co-signing ability here, so you are relying entirely on keeping
> the transaction data secret to prevent a third-party from triggering your
> relative-lock clock. More specifically for a vault scheme, since
> bare-CTV's are currently unaddressable, and AFAIK, there is no address
> format proposal yet, it is impossible to receive funds directly into a
> vault. You must shuffle received funds into your vault yourself, which
> seems very likely to negate the cost savings of using bare-CTV in the first
> place (please correct me if I'm wrong). Better to receive funds directly
> into a taproot-CTV vault, which has an address, and while you are at it,
> you could place the cold-key as the taproot key to save even more when
> using the cold-key to move vault funds.
>
>
This is not quite true, you can receive funds into a bare-CTV from your
vault software, and you can send into one from your vault software. What
doesn't work is exporting or creating an address for that. As a reminder
for those following along at home, not all standard output types have
addresses, even today. For example, OP_RETURN.
However, this is a standarness question. If the market _wanted_ such an
address, one could be adopted without requiring consensus processes.
Generally, the vault designs I work on use Sapio and therefore also use
Taproot since I have not added support for non-taproot scripts / removed
support for witness v0. I will eventually add these back, but it's a
marginal fee savings optimization and I'm focused primarily on feature
completeness.
> There might be even more exotic use cases of bare-CTV. For example you
> could commit to a transaction that has a second input that doesn't yet
> exist in the UTXO set in an attempt to coax it into existence. I don't know
> if there have been any proposals to take advantage of this.
>
There are, but it's not specific to how bare ctv works, it should work from
any CTV context.
>
> With that said, everything that bare-CTV can do, can also be done by
> tapscript-CTV; so it is just a matter of cost. I'm struggling to
> understand where this cost savings is and how much those savings are going
> to be given that bare-CTV is unaddressable and seems to ultimately occupy
> more-blockspace than if the outputs were directly committed to.
>
> I also believe the bare-CTV question is material, because if bare-CTV were
> not part of the spec, then I'd be advocating for using an OP_SUCCESS code
> from tapscript instead, and either use push-style semantics for CTV, which
> would be composed with EQUAL_VERIFY to mimic the currently proposed
> verification style-semantics, or a hybrid push-or-verify semantics that
> would either push or verify depending on the size of the input. (And I
> still think a more general TXHASH would be even better, though if I cannot
> convince aj then perhaps I'm wrong.)
>
Even if we got rid of bare ctv, segwit v0 CTV would still exist, so we
couldn't use OP_SUCCESSx there either. segwitv0 might be desired if someone
has e.g. hardware modules or MPC Threshold Crypto that only support ECDSA
signatures, but still want CTV.
>
> I'm not saying bare-CTV is necessarily a bad idea. I'm just struggling
> with its justification.
>
Fair. I wouldn't have a big problem removing it, if it were clear that were
it to become desired, we could add it back. I think the case for CTV in
Segwitv0 is stronger, which has the same implication for a PUSH variant of
CTV.
Thanks again,
Jeremy
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220421/c88f5d72/attachment.html>;
Jeremy Rubin [ARCHIVE] /
npub1xu…fzef0
2023-06-07 23:07:29
in reply to nevent1q…emjz
Author Public Key
npub1xukrzempxc95ags094lgrfvnvwm7gkuwj3d98qwrzgsynskyhp9qkfzef0Published at
2023-06-07 23:07:29Event JSON
{
"id": "12c305cb2f67c8bdeaf6251fde00d8b35ff80ada3f3461f069b36c708543357a",
"pubkey": "372c316761360b4ea20f2d7e81a59363b7e45b8e945a5381c3122049c2c4b84a",
"created_at": 1686179249,
"kind": 1,
"tags": [
[
"e",
"22a3ad61ac618e4cddbe45159911f56b4157e56398a7395c8636325af422c5e4",
"",
"root"
],
[
"e",
"5286d585dbad7b61160552cd5fbae2e8cf02007593affd10c5c3a556d4776943",
"",
"reply"
],
[
"p",
"6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d"
]
],
"content": "📅 Original date posted:2022-04-21\n📝 Original message:Hi Russell,\n\nThank you for your feedback here.\n\n\n\n\u003e However, I'm still skeptical of the bare-CTV part of BIP-119 (and I'm told\n\u003e that bare-CTV hasn't even appeared on the CTV signet). Unlike the general\n\u003e smart-contracting case, bare-CTV does not have any branches. All it can do\n\u003e is commit to a subsequent transaction's outputs. At first glance this\n\u003e appears to be a waste because, for less bandwidth, that transaction could\n\u003e just realize those outputs immediately, so why would anyone want to delay\n\u003e the inevitable?\n\u003e\n\nI can probably make some show up sometime soon. Note that James' vault uses\none at the top-level https://github.com/jamesob/simple-ctv-vault, but I\nthink the second use of it (since it's not segwit wrapped) wouldn't be\nbroadcastable since it's nonstandard.\n\n\n\n\n\u003e\n\u003e One reason might be that you want to commit to the output early during a\n\u003e high-fee time, and then complete the transaction later during a low-fee\n\u003e time. While there are fee-rate situations where this could result in lower\n\u003e fees than committing to the outputs all at once, it would be even cheaper\n\u003e still to just wait to do the payout at the low-fee time. I'm struggling to\n\u003e understand the advantages of the advanced commitment, along with all the\n\u003e overhead that entails. Doesn't it just cause more blockspace to be used\n\u003e overall?\n\u003e\n\nOne case where you actually use less space is if you have a few different\nsets of customers at N different fee priority level. Then, you might need\nto have N independent batches, or risk overpaying against the customer's\npriority level. Imagine I have 100 tier 1 customers and 1000 tier 2\ncustomers. If I batcher tier 1 with tier 2, to provide tier 1 guarantees\nI'd need to pay tier 1 rate for 10x the customers. With CTV, I can combine\nmy batch into a root and N batch outputs. This eliminates the need for\ninputs, signatures, change outputs, etc per batch, and can be slightly\nsmaller. Since the marginal benefit on that is still pretty small, having\nbare CTV improves the margin of byte wise saving.\n\nI give this as an example where CTV uses less space, it is detailed more\nhere: https://utxos.org/analysis/batching_sim/. This benefit might be\nmarginal and absurd, given these are already big transactions, but it may\n_also_ be absurd that feerates only ever go up and congestion control is\nnot valuable.\n\nAnother example where this arises is where you have a transaction set you\nneed to pay top-of-mempool rate for the soonest confirmation you can get.\nCTV has a decongesting effect, because your top-of-mempool transaction is\nsmall, which doesn't trigger as much rivalrous behavior with other\ntransactors. Concretely, the current policy max txn size is 100kb, or 10%\nof a block. If you bump out of next block window 10% of the mempool, then\nif those transactors care to maintain their positioning, they will need to\nput themselves into a higher percentile with e.g. RBF or CPFP. Whereas if\nyou put in a transaction that is just 100 bytes, you only bump out 100\nbytes of rivals (0.01%), not 10%.\n\nLastly, perhaps a more realistic scenario, is where I am batching to 100\ncustomers who all wish to do something else after I pay them. E.g., open a\nlightning channel. Being able to use CTV noninteractive channels cuts\nthrough the extra hop transaction (unless dual funded channels, unless the\nchannels are opened between two customers, then they can be dual funded\nagain). So using CTV here also saves in net blockspace (although, note,\nthis is sort of orthogonal to using CTV over the batch itself, just a good\nexample for the related question of 'doesn't ctv generally use more\nblockspace').\n\n\n\u003e There are some other proposed use cases for bare-CTV. A bare-CTV can be\n\u003e used to delay a \"trigger\"-transaction. Some contracts, such as vaults, use\n\u003e a relative-locktime as part of their construction and it could make sense\n\u003e to make an output commitment but not realize those outputs yet until you\n\u003e are ready to start your relative-time lock clock. But bare-CTV doesn't\n\u003e support any co-signing ability here, so you are relying entirely on keeping\n\u003e the transaction data secret to prevent a third-party from triggering your\n\u003e relative-lock clock. More specifically for a vault scheme, since\n\u003e bare-CTV's are currently unaddressable, and AFAIK, there is no address\n\u003e format proposal yet, it is impossible to receive funds directly into a\n\u003e vault. You must shuffle received funds into your vault yourself, which\n\u003e seems very likely to negate the cost savings of using bare-CTV in the first\n\u003e place (please correct me if I'm wrong). Better to receive funds directly\n\u003e into a taproot-CTV vault, which has an address, and while you are at it,\n\u003e you could place the cold-key as the taproot key to save even more when\n\u003e using the cold-key to move vault funds.\n\u003e\n\u003e\nThis is not quite true, you can receive funds into a bare-CTV from your\nvault software, and you can send into one from your vault software. What\ndoesn't work is exporting or creating an address for that. As a reminder\nfor those following along at home, not all standard output types have\naddresses, even today. For example, OP_RETURN.\n\nHowever, this is a standarness question. If the market _wanted_ such an\naddress, one could be adopted without requiring consensus processes.\n\nGenerally, the vault designs I work on use Sapio and therefore also use\nTaproot since I have not added support for non-taproot scripts / removed\nsupport for witness v0. I will eventually add these back, but it's a\nmarginal fee savings optimization and I'm focused primarily on feature\ncompleteness.\n\n\n\u003e There might be even more exotic use cases of bare-CTV. For example you\n\u003e could commit to a transaction that has a second input that doesn't yet\n\u003e exist in the UTXO set in an attempt to coax it into existence. I don't know\n\u003e if there have been any proposals to take advantage of this.\n\u003e\n\nThere are, but it's not specific to how bare ctv works, it should work from\nany CTV context.\n\n\u003e\n\u003e With that said, everything that bare-CTV can do, can also be done by\n\u003e tapscript-CTV; so it is just a matter of cost. I'm struggling to\n\u003e understand where this cost savings is and how much those savings are going\n\u003e to be given that bare-CTV is unaddressable and seems to ultimately occupy\n\u003e more-blockspace than if the outputs were directly committed to.\n\u003e\n\u003e I also believe the bare-CTV question is material, because if bare-CTV were\n\u003e not part of the spec, then I'd be advocating for using an OP_SUCCESS code\n\u003e from tapscript instead, and either use push-style semantics for CTV, which\n\u003e would be composed with EQUAL_VERIFY to mimic the currently proposed\n\u003e verification style-semantics, or a hybrid push-or-verify semantics that\n\u003e would either push or verify depending on the size of the input. (And I\n\u003e still think a more general TXHASH would be even better, though if I cannot\n\u003e convince aj then perhaps I'm wrong.)\n\u003e\n\nEven if we got rid of bare ctv, segwit v0 CTV would still exist, so we\ncouldn't use OP_SUCCESSx there either. segwitv0 might be desired if someone\nhas e.g. hardware modules or MPC Threshold Crypto that only support ECDSA\nsignatures, but still want CTV.\n\n\u003e\n\u003e I'm not saying bare-CTV is necessarily a bad idea. I'm just struggling\n\u003e with its justification.\n\u003e\n\n\nFair. I wouldn't have a big problem removing it, if it were clear that were\nit to become desired, we could add it back. I think the case for CTV in\nSegwitv0 is stronger, which has the same implication for a PUSH variant of\nCTV.\n\n\nThanks again,\n\nJeremy\n\n\n\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220421/c88f5d72/attachment.html\u003e",
"sig": "302b853085dc1df531421e3e1035426bdfe43e9d2f2d20b31ebaf78cd397306787ad6afc138f262f539ef3cda0b3da819e3ef50c3cf6cab9dcad41ffbea54957"
}