📅 Original date posted:2022-03-16
📝 Original message:On Wed, Mar 9, 2022 at 10:47 PM Anthony Towns <aj at erisian.com.au> wrote:
>
> To redo the singleton pattern in bitcoin's context, I think you'd have
> to pass in both the full tx you're spending (to be able to get the
> txid of its parent) and the full tx of its parent (to be able to get
> the scriptPubKey that your utxo spent) which seems klunky but at least
> possible (you'd be able to drop the witness data at least; without that
> every tx would be including the entire history of the singleton).
>
Yes that's the idea. Since the parent transaction is in the blockchain it
could be pulled in automatically without having to charge vbytes for it.
> If softfork is just doing a best effort for whatever opcodes it knows
> about, and otherwise succeeding, then it has to succeed, and your
> script/output has become anyone-can-spend.
>
That can be alleviated by when things call untrusted code they can wrap it
in a guard which can be the soft fork opcode itself.
>
> On the other hand, if you could tell the softfork op that you only wanted
> ops up-to-and-including the 118 softfork, then it could reject fakeopcode
> and fail the script, which I think gives the desirable behaviour.
>
A simple approach to versioning like that may be more expedient. Soft
forking in CLVM isn't implemented yet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220315/ccdf755f/attachment.html>;
Bram Cohen [ARCHIVE] /
npub1ld…t8ur6
2023-06-08 01:05:23
in reply to nevent1q…tpux
Author Public Key
npub1ldcq03p2qe58u0xnlwa35wchjuhz49y6ueu5ghmtjetez9xstnvsmt8ur6Published at
2023-06-08 01:05:23Event JSON
{
"id": "fcbc0d22ccf771ccfb23323621a35a51da535b814cb86e38757f89589c616db8",
"pubkey": "fb7007c42a06687e3cd3fbbb1a3b17972e2a949ae679445f6b96579114d05cd9",
"created_at": 1686179123,
"kind": 1,
"tags": [
[
"e",
"17a237ce59197bc5ffad96769beec5209b19830977cb935d9412190ad411e7e9",
"",
"root"
],
[
"e",
"ec697bfaf31b350705eda91e675267ee427c7700eeca578bd2c2191834767762",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2022-03-16\n📝 Original message:On Wed, Mar 9, 2022 at 10:47 PM Anthony Towns \u003caj at erisian.com.au\u003e wrote:\n\n\u003e\n\u003e To redo the singleton pattern in bitcoin's context, I think you'd have\n\u003e to pass in both the full tx you're spending (to be able to get the\n\u003e txid of its parent) and the full tx of its parent (to be able to get\n\u003e the scriptPubKey that your utxo spent) which seems klunky but at least\n\u003e possible (you'd be able to drop the witness data at least; without that\n\u003e every tx would be including the entire history of the singleton).\n\u003e\n\nYes that's the idea. Since the parent transaction is in the blockchain it\ncould be pulled in automatically without having to charge vbytes for it.\n\n\n\u003e If softfork is just doing a best effort for whatever opcodes it knows\n\u003e about, and otherwise succeeding, then it has to succeed, and your\n\u003e script/output has become anyone-can-spend.\n\u003e\n\nThat can be alleviated by when things call untrusted code they can wrap it\nin a guard which can be the soft fork opcode itself.\n\n\n\u003e\n\u003e On the other hand, if you could tell the softfork op that you only wanted\n\u003e ops up-to-and-including the 118 softfork, then it could reject fakeopcode\n\u003e and fail the script, which I think gives the desirable behaviour.\n\u003e\n\nA simple approach to versioning like that may be more expedient. Soft\nforking in CLVM isn't implemented yet.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220315/ccdf755f/attachment.html\u003e",
"sig": "bc87cf9783495aa22872e510bf4cc180c9ee2a1be55eb16d58ab2e3d9d18870bce1cbbf867a56a34b3f126370b6dcbfb3b573bb3d02f6c1c66a37d6eb856e62a"
}