You are viewing a single comment's thread from:
RE: HF21 Recommendation: Raising Custom JSON Limit
Are there serious downsides to having it be a witness-configured limit instead of a hard-coded limit?
Are there serious downsides to having it be a witness-configured limit instead of a hard-coded limit?
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.