Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2014-02-24 📝 Original message:On Mon, Feb 24, 2014 at ...
📅 Original date posted:2014-02-24
📝 Original message:On Mon, Feb 24, 2014 at 3:06 PM, Andreas Petersson <andreas at petersson.at> wrote:
> Regarding 80 bytes vs smaller: The objectives should be that if you are
> determined to put some extra data in the blockchain, OP_RETURN should be
> the superior alternative. if a user can include more data with less fees
> using a multisig TX, then this will happen.
>
> eventually dust-limit rules will not be the deciding factor here, since
> i suspect block propagation times will have a stronger effect on
> effective fees. therefore a slightly larger payload than the biggest
> multisig TX is the right answer. - that would be >= 64x3 bytes = 192 bytes.
> (this is my understanding of how large a 3-of-3 multisig tx can be, plus
> 1.5 bits encoded in the "n" parameter)
At least there is no ambiguity that such usage is abusive. Adoption of
the practices matters too. Right now I've seen a lot of people
promoting data storage as a virtuous use, and gearing up to directly
store data when a commitment would work.
If it turns out that encouraging people to use hashes is a lost cause
it can always be further relaxed in the future, going the other way is
much harder.
Published at
2023-06-07 15:13:58Event JSON
{
"id": "9afdd20685f68e91072cacccc96b7d7035d1176e29cc45413e090edafa500a06",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686150838,
"kind": 1,
"tags": [
[
"e",
"1ef870aa2080d76066b16301e94316a8cf8557aa7768e48cc4c5664289bfd14e",
"",
"root"
],
[
"e",
"a602993271e35f05c4e96d47f433a43526ab0b31050ab1707ac80b4722d8459b",
"",
"reply"
],
[
"p",
"7888690f3f40427a03058866b3e6a433e5036d5e84cbf81036bfc6b5c83b9596"
]
],
"content": "📅 Original date posted:2014-02-24\n📝 Original message:On Mon, Feb 24, 2014 at 3:06 PM, Andreas Petersson \u003candreas at petersson.at\u003e wrote:\n\u003e Regarding 80 bytes vs smaller: The objectives should be that if you are\n\u003e determined to put some extra data in the blockchain, OP_RETURN should be\n\u003e the superior alternative. if a user can include more data with less fees\n\u003e using a multisig TX, then this will happen.\n\u003e\n\u003e eventually dust-limit rules will not be the deciding factor here, since\n\u003e i suspect block propagation times will have a stronger effect on\n\u003e effective fees. therefore a slightly larger payload than the biggest\n\u003e multisig TX is the right answer. - that would be \u003e= 64x3 bytes = 192 bytes.\n\u003e (this is my understanding of how large a 3-of-3 multisig tx can be, plus\n\u003e 1.5 bits encoded in the \"n\" parameter)\n\nAt least there is no ambiguity that such usage is abusive. Adoption of\nthe practices matters too. Right now I've seen a lot of people\npromoting data storage as a virtuous use, and gearing up to directly\nstore data when a commitment would work.\n\nIf it turns out that encouraging people to use hashes is a lost cause\nit can always be further relaxed in the future, going the other way is\nmuch harder.",
"sig": "2690022e3b9ab6f6122a178581e0b2fce2d5dbee14443ba9e7123364d9672ebc2407e835df8da718cb0146621b5594a3f64cff4835a0a95cfc122b9ce5389437"
}