#0008 Increase OP_RETURN Size Limit

peercoin / rfcs

Request for Comment (RFC) papers and discussions on Peercoin core applications, libraries and API's

9 stars 16 forks source link

#0008 Increase OP_RETURN Size Limit #10

Closed backpacker69 closed 6 years ago

backpacker69 commented 6 years ago

Current limit is 80 bytes, it is proposed to increase it to 1024 bytes.

saeveritt commented 6 years ago

I am in support of this proposal and believe it will increase the overall utility of the chain. This will benefit future and current second-layer solutions. In terms of the listed drawbacks, the blockchain size increase from this change will not be without the user paying and exact fee for their data. For alternatives I believe removing the cap all together would be best saved for a later time. We also must consider the limitations from MAX_STANDARD_TX_SIZE.

youngpascal commented 6 years ago

RFC #0008

hrobeers commented 6 years ago

As this limit is just a relay rule, we can make it configurable and set it to a default of 1024 bytes for relaying. On the other hand, we can make the RPC interface refuse >80 byte transactions by default, so that users should explicitly turn it on so they are fully aware they are using a non-portable feature (with portable I mean bitcoin compatible).

d5000 commented 6 years ago

I'm a bit skeptic about this one. Would this help PeerAssets? In my opinion, the 80 bytes limit for OP_RETURN is a bit low but 1024 would already perhaps incentive "bloaty" data schemes (e.g. without compression). I would favour about 256 bytes, but again, I'm not a developer. Maybe the 0.01/kB fee is enough to dis-incentive bloat ...

peerchemist commented 6 years ago

Would this help PeerAssets?

No, PA is made to work with 80 bytes with a lot of space remaining.

nohea commented 6 years ago

What would happen in practice if only a minority of nodes "opt in" to relaying an OP_RETURN = 1024?

Tell me if this is right or wrong:

tx with large OP_RETURN is created (smart contract) and submitted to supporting local node
tx only relays to supporting nodes with OP_RETURN == 1024 enabled
eventually a supporting miner or a supporting minting node finds a block w/the tx and writes to blockchain
to spend/execute the tx, repeat similar process

hrobeers commented 6 years ago

@nohea This is what the PARS project did. It removed OP_RETURN relay limit and all other standardness rules in a modified client build. The bullet points are indeed exactly what happens.

nohea commented 6 years ago

@hrobeers thank you. I read about the your PARS project before, i wanted to confirm in this case, RFC 8, if the default client is modified.

peerchemist commented 6 years ago

I believe 256 byte max OP_RETURN is enough.

nohea commented 6 years ago

I just thought this is an interesting discussion of OP_RETURN size on the Bitcoin side: https://github.com/bitcoin/bitcoin/pull/5286

nohea commented 6 years ago

Is this RFC for increasing OP_RETURN size related to Pay-to-tag-hash / P2TH ? Like, having asset/deck names bigger than 80 bytes? https://peerassets.github.io/P2TH/

peerchemist commented 6 years ago

No, PeerAssets is crazy efficient. 10 - 20 bytes are usually spent on deck spawn. I did 45 cards batched transfer once too, it all fitted in 80 bytes.

backpacker69 commented 6 years ago

it's partially related to length of asset_specific_data for some use cases

peerchemist commented 6 years ago

In their recent upgrade, Bitcoin-cash has increased the OP_RETURN to 220 bytes.

peerchemist commented 6 years ago

Do we have agreement about op_return size limit now?

peerchemist commented 6 years ago

Settled on 256 bytes limit.