> nobody's going to benefit from that possibility anyway. James O'Beirne's simple-ctv-vault appears to be using bare CTV outputs:
https://github.com/jamesob/simple-ctv-vault/blob/7dd6c4ca25debb2140cdefb79b302c65d1b24937/main.py#L217-L218 https://github.com/jamesob/simple-ctv-vault/blob/7dd6c4ca25debb2140cdefb79b302c65d1b24937/main.py#L324-L325 I guess this suggests that it was not tested on signet? On Fri, Apr 22, 2022 at 3:58 AM Anthony Towns via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Thu, Apr 21, 2022 at 10:05:20AM -0500, Jeremy Rubin via bitcoin-dev > wrote: > > 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. > > The whole point of testing is so that bugs like "wouldn't be broadcastable > since it's nonstandard" get fixed. If these things are still in the > "interesting thought experiment" stage, but nobody but Jeremy is > interested enough to start making them consistent with the proposed > consensus and policy rules, it seems very premature to be changing > consensus or policy rules. > > > 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. > > Bare CTV only saves bytes when *spending* -- but this is when you're > creating the 1100 outputs, so an extra 34 or 67 bytes of witness data > seems fairly immaterial (0.05% extra vbytes?). It doesn't make the small > commitment tx any smaller. > > ie, scriptPubKey looks like: > - bare ctv: [push][32 bytes][op_nop4] > - p2wsh: [op_0][push][32 bytes] > - p2tr: [op_1][push][32 bytes] > > while witness data looks like: > - bare ctv: empty scriptSig, no witness > - pw2sh: empty scriptSig, witness = "[push][32 bytes][op_nop4]" > - p2tr: empty scriptSig, witness = 33B control block, > "[push][32 bytes][op_nop4]" > > You might get more a benefit from bare ctv if you don't pay all 1100 > outputs in a single tx when fees go lower; but if so, you're also wasting > quite a bit more block space in that case due to the intermediate > transactions you're introducing, which makes it seem unlikely that > you care about the extra 9 or 17 vbytes bare CTV would save you per > intermediate tx... > > I admit that I am inclined towards micro-optimising things to save > those bytes if it's easy, which does incline me towards bare CTV; but > the closest thing we have to real user data suggests that nobody's going > to benefit from that possibility anyway. > > > 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. > > If you desire new features, then you might have to upgrade old hardware > that can't support them. > > Otherwise that would be an argument to never use OP_SUCCESSx: someone > might want to use whatever new feature we might imagine on hardware that > only supports ECDSA signatures. > > Cheers, > aj > _______________________________________________ > 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
