RE: HF21 Recommendation: Raising Custom JSON Limit

You are viewing a single comment's thread from:

HF21 Recommendation: Raising Custom JSON Limit

in hf21 •  6 years ago 

Are there serious downsides to having it be a witness-configured limit instead of a hard-coded limit?

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

Letting witnesses configure it gives us flexibility so that if we want to adjust it later, we don't need a hardfork or replay.

A possible downside is that a witness decides to ignore the other witnesses and ends up bricking accounts. But I think that's a risk with almost any op, not just custom_json. A witness doing that has to modify steemd and explicitly attack the community, which is grounds for unapproving such a witness.

You can't unapprove a backup.

In this case, the account being bricked has to also participate in the attack upon itself by trying to get too many ops included in blocks.

Not really. It is perfectly okay to broadcast multiple transactions at one time, I believe? They'll just trickle in one per block unless some witness puts multiples in a block. But I'm not really sure how this ends up bricking the account though. It seems different than the overuse of RCs that we saw earlier, since that affected the RC balance. There is no balance here.

It is currently implemented entirely via soft consensus (plugins). The biggest downside currently would be developer time to reimplement the system to use witness voted limits.

  ·  6 years ago (edited)