Rusty Russell on Nostr: So, a lovely interaction with Jeremy Rubin where he shattered my XOR simplified CTV ...
So, a lovely interaction with Jeremy Rubin where he shattered my XOR simplified CTV scheme. Damn.
So I'm banging my head against the problem some more. I want "txid with this input txid zeroed" but that can involve too much hashing in the worst case. Even if you move the txids to the end: about 250 GB according to my rough calc.
Jeremy suggested a merkle tree, which can work, but we're getting uncomfortably far from "simple" now. Specifically, my bar is "how hard would it to be to produce this *in Script*, assuming that's fully re-enabled?". Not too bad with a known number of inputs, but I don't want to even think about dealing with arbitrary numbers.
Varops budget doesn't really help here, either. Everywhere else, you can't hit the varops limit unless *your input script* is doing wild things: this would mean you can hit the limit with a single opcode in a reasonable script :(
You're better off just saying "your tx which uses this opcode must have no more than 64 inputs" or "no larger than 10k", but that feels totally arbitrary.
For those following along at home: CTV solves this by committing to just the number of inputs, and if that's not 1 you're kind of on your own. It's not *banned*, just shrugged. I dislike this hole, but do I dislike complexity more?
This is what I ponder over morning coffee before Real Work.
Published at
2024-12-10 22:37:09Event JSON
{
"id": "f3fd01fc299a1902da24986899d5efcd8c4217b93e945a62548082c9c475752c",
"pubkey": "f1725586a402c06aec818d1478a45aaa0dc16c7a9c4869d97c350336d16f8e43",
"created_at": 1733870229,
"kind": 1,
"tags": [
[
"r",
"https://image.nostr.build/9c1585d6207c5cad4bfc25e2ffce67ac3dc7e27347c1744e57186be1d254b258.jpg"
],
[
"imeta",
"url https://image.nostr.build/9c1585d6207c5cad4bfc25e2ffce67ac3dc7e27347c1744e57186be1d254b258.jpg",
"m image/jpeg",
"alt Snapshot of Jeremy on Twitter",
"x e5ab279f9f3ef88cf01957d9e3bcece4fa9286736c62ecf26dcfd191d824a111",
"size 121591",
"dim 1080x1456",
"blurhash _8R{*}NH^k%M.7nOx]oLRks.WBj]jFW=yDIARQIoRPo}Vs0LV?xaRjsAbvi_smX9M{s;W;aKbb-oE1IARkNGaKXSD*ofxuofoLofoL4oROxvM{niXSnO~WM{E2RjM{ogaK",
"ox 9c1585d6207c5cad4bfc25e2ffce67ac3dc7e27347c1744e57186be1d254b258"
]
],
"content": "So, a lovely interaction with Jeremy Rubin where he shattered my XOR simplified CTV scheme. Damn.\n\nSo I'm banging my head against the problem some more. I want \"txid with this input txid zeroed\" but that can involve too much hashing in the worst case. Even if you move the txids to the end: about 250 GB according to my rough calc.\n\nJeremy suggested a merkle tree, which can work, but we're getting uncomfortably far from \"simple\" now. Specifically, my bar is \"how hard would it to be to produce this *in Script*, assuming that's fully re-enabled?\". Not too bad with a known number of inputs, but I don't want to even think about dealing with arbitrary numbers.\n\nVarops budget doesn't really help here, either. Everywhere else, you can't hit the varops limit unless *your input script* is doing wild things: this would mean you can hit the limit with a single opcode in a reasonable script :(\n\nYou're better off just saying \"your tx which uses this opcode must have no more than 64 inputs\" or \"no larger than 10k\", but that feels totally arbitrary.\n\nFor those following along at home: CTV solves this by committing to just the number of inputs, and if that's not 1 you're kind of on your own. It's not *banned*, just shrugged. I dislike this hole, but do I dislike complexity more?\n\nThis is what I ponder over morning coffee before Real Work.\n https://image.nostr.build/9c1585d6207c5cad4bfc25e2ffce67ac3dc7e27347c1744e57186be1d254b258.jpg\n",
"sig": "b335b5e17a6e9434a44d6853725fb8d82ccc15caf94ade875c4b64b4f801166ed776ac1c549f0eeedd3ff0b646e8d1c41fe4a469cae839095551797ad3907fcb"
}
