📅 Original date posted:2014-07-16
📝 Original message:Hey all,
I had an idea for a new transaction type. The base idea is that it is
matching on script hashes much like pay to script hash, but checks for one
of N scripts.
A motivating case is for "permission groups". Let's say I want to have a
single "root user" script, a 2 of 3 group, and a 2 of 2 group able to spend
a utxo. This would allow for any one of these permission groups to spend.
Right now, this could be expressed multiple ways (ie, using an op_dup if
then else chain) , but all would incur additional costs in terms of
complicated control flows. Instead, I would propose:
OP_HASH160 [20-byte-hash-value 1]...[20-byte-hash-value N] OP_N
OP_MULTISCRIPTHASHVERIFY
could be spent with
...signatures... {serialized script}
And the alternative formulation: (more complex!)
OP_HASH160 OP_DUP [20-byte-hash-value 1]
OP_IF OP_EQUAL
OP_VERIFY OP_ELSE <OP_DUP [20-byte-hash-value 2] OP_IF......>
OP_ENDIF
Of course, the permission group example is just one use case, there could
be other interesting combinations as well
.
There is an implication in terms of increased utxo pool bloat, but also an
implication in terms of increased txn complexity (each 20 byte hash allows
for a 500 byte script, only one of the 500 byte scripts has to be
permanently stored on blockchain).
Looking forward to your feedback -- the idea is a bit preliminary, but I
think it could be exciting.
Best,
Jeremy
--
Jeremy Rubin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140716/a960cd3a/attachment.html>;
Jeremy [ARCHIVE] /
npub1q8…8qwta
2023-06-07 15:24:00
in reply to nevent1q…agnj
Author Public Key
npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwtaPublished at
2023-06-07 15:24:00Event JSON
{
"id": "2ad45080662174a53e0e48126779677ac1a747cb72fb84ecf6e67bf2ec831025",
"pubkey": "01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4",
"created_at": 1686151440,
"kind": 1,
"tags": [
[
"e",
"8b09740488398b2e34293173a8f2156c2ae3c49cf97ae925d064a7835cdb8d7d",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2014-07-16\n📝 Original message:Hey all,\n\nI had an idea for a new transaction type. The base idea is that it is\nmatching on script hashes much like pay to script hash, but checks for one\nof N scripts.\n\nA motivating case is for \"permission groups\". Let's say I want to have a\nsingle \"root user\" script, a 2 of 3 group, and a 2 of 2 group able to spend\na utxo. This would allow for any one of these permission groups to spend.\n\nRight now, this could be expressed multiple ways (ie, using an op_dup if\nthen else chain) , but all would incur additional costs in terms of\ncomplicated control flows. Instead, I would propose:\n\nOP_HASH160 [20-byte-hash-value 1]...[20-byte-hash-value N] OP_N\nOP_MULTISCRIPTHASHVERIFY\n\n\ncould be spent with\n\n...signatures... {serialized script}\n\n\nAnd the alternative formulation: (more complex!)\n\nOP_HASH160 OP_DUP [20-byte-hash-value 1]\n OP_IF OP_EQUAL\n OP_VERIFY OP_ELSE \u003cOP_DUP [20-byte-hash-value 2] OP_IF......\u003e\nOP_ENDIF\n\n\n\nOf course, the permission group example is just one use case, there could\nbe other interesting combinations as well\n.\n\n\nThere is an implication in terms of increased utxo pool bloat, but also an\nimplication in terms of increased txn complexity (each 20 byte hash allows\nfor a 500 byte script, only one of the 500 byte scripts has to be\npermanently stored on blockchain).\n\n\nLooking forward to your feedback -- the idea is a bit preliminary, but I\nthink it could be exciting.\n\nBest,\n\nJeremy\n\n\n\n\n-- \nJeremy Rubin\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140716/a960cd3a/attachment.html\u003e",
"sig": "b039cc41fb81488bca1c9516a22203c9ee269ac3763da7d175b00bed3d500ff0ac00abac328ce3953ba398de359dbfcad352b523eb1196ad7bea1d3b98f1ecac"
}