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.
📝 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.