{"type":"rich","version":"1.0","author_name":"npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","author_url":"https://nostr.ae/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-04-21\n📝 Original message:On Thu, Apr 21, 2022 at 10:05:20AM -0500, Jeremy Rubin via bitcoin-dev wrote:\n\u003e I can probably make some show up sometime soon. Note that James' vault uses\n\u003e one at the top-level https://github.com/jamesob/simple-ctv-vault, but I\n\u003e think the second use of it (since it's not segwit wrapped) wouldn't be\n\u003e broadcastable since it's nonstandard.\n\nThe whole point of testing is so that bugs like \"wouldn't be broadcastable\nsince it's nonstandard\" get fixed. If these things are still in the\n\"interesting thought experiment\" stage, but nobody but Jeremy is\ninterested enough to start making them consistent with the proposed\nconsensus and policy rules, it seems very premature to be changing\nconsensus or policy rules.\n\n\u003e One case where you actually use less space is if you have a few different\n\u003e sets of customers at N different fee priority level. Then, you might need\n\u003e to have N independent batches, or risk overpaying against the customer's\n\u003e priority level. Imagine I have 100 tier 1 customers and 1000 tier 2\n\u003e customers. If I batcher tier 1 with tier 2, to provide tier 1 guarantees\n\u003e I'd need to pay tier 1 rate for 10x the customers. With CTV, I can combine\n\u003e my batch into a root and N batch outputs. This eliminates the need for\n\u003e inputs, signatures, change outputs, etc per batch, and can be slightly\n\u003e smaller. Since the marginal benefit on that is still pretty small, having\n\u003e bare CTV improves the margin of byte wise saving.\n\nBare CTV only saves bytes when *spending* -- but this is when you're\ncreating the 1100 outputs, so an extra 34 or 67 bytes of witness data\nseems fairly immaterial (0.05% extra vbytes?). It doesn't make the small\ncommitment tx any smaller.\n\nie, scriptPubKey looks like:\n - bare ctv: [push][32 bytes][op_nop4]\n - p2wsh: [op_0][push][32 bytes]\n - p2tr: [op_1][push][32 bytes]\n\nwhile witness data looks like:\n - bare ctv: empty scriptSig, no witness\n - pw2sh: empty scriptSig, witness = \"[push][32 bytes][op_nop4]\"\n - p2tr: empty scriptSig, witness = 33B control block,\n         \"[push][32 bytes][op_nop4]\"\n\nYou might get more a benefit from bare ctv if you don't pay all 1100\noutputs in a single tx when fees go lower; but if so, you're also wasting\nquite a bit more block space in that case due to the intermediate\ntransactions you're introducing, which makes it seem unlikely that\nyou care about the extra 9 or 17 vbytes bare CTV would save you per\nintermediate tx...\n\nI admit that I am inclined towards micro-optimising things to save\nthose bytes if it's easy, which does incline me towards bare CTV; but\nthe closest thing we have to real user data suggests that nobody's going\nto benefit from that possibility anyway.\n\n\u003e Even if we got rid of bare ctv, segwit v0 CTV would still exist, so we\n\u003e couldn't use OP_SUCCESSx there either. segwitv0 might be desired if someone\n\u003e has e.g. hardware modules or MPC Threshold Crypto that only support ECDSA\n\u003e signatures, but still want CTV.\n\nIf you desire new features, then you might have to upgrade old hardware\nthat can't support them.\n\nOtherwise that would be an argument to never use OP_SUCCESSx: someone\nmight want to use whatever new feature we might imagine on hardware that\nonly supports ECDSA signatures.\n\nCheers,\naj"}