Add settings for witnesses to disable certain operation types

[vikramrajkumar]

From @bytemaster on July 1, 2015 21:18

In the event of an bug in certain operations, witnesses need the ability to respond quickly and filter transactions that contain those operations.

Copied from original issue: cryptonomex/graphene#122

[vikramrajkumar]

From @VoR0220 on July 8, 2015 2:31

49fb41c440339121a066a33dc97069a5144bdf93

a152351766b8710554c531888aef2bf342bd9aef

I made these commits in my forked repo. I wasn't super positive in terms of where to start in terms of setting up an outline of where to attack, so I made two and hoped that one of them might be a useful place. Let me know if they're helpful and I'll create a PR.

[vikramrajkumar]

From @theoreticalbts on July 8, 2015 17:33

@VoR0220 I looked briefly at your commits. Resignation (see ticket #143 ) needs to be a blockchain op, so you're on the right track with that.

However, the op filtering functionality proposed in this ticket would be a local setting of an individual witness node.

[vikramrajkumar]

From @VoR0220 on July 8, 2015 19:16

Am I wrong in my understanding that the op filtering functionality would fall under the witness_object? Where is the local setting of an individual witness node handled?

[vikramrajkumar]

From @nathanhourt on July 8, 2015 19:41

This needs to be implemented carefully: if the operation being filtered is found while processing a block, it must be allowed. It can only be rejected in a new transaction.

[vikramrajkumar]

Related ancestor issue from BTS 0.x: bitshares/bitshares1-core#1147

[vikramrajkumar]

From @theoreticalbts on July 8, 2015 19:47

@nathanhourt : The alternatives are:

• Filter the op out of tx's, but build on blocks that contain the op.
• Don't build on blocks containing the op at all.

If the scenario envisioned for using this is discovering an awful bug in an operation which requires witnesses to disable that op very quickly, it's likely a chain security issue. Which would mean the thing the old version would need to support with only a witness config change is being able to hardfork the operation out. If you merely censor it, then a single witness could still include the buggy op and compromise the chain.

I.e., if you don't build on blocks that contain the op, then reconfiguring a majority of witnesses suffices to suppress the buggy op. If you do build on blocks that contain the op, the witness reconfiguration must be unanimous to suppress the buggy op.

[vikramrajkumar]

From @nathanhourt on July 8, 2015 21:51

Right, so in general the question is whether it's better to fork the chain, or to censor the op as soon as possible. The answer to that question is highly situation-dependent, so should we allow either option and then decide on a case-by-case basis which alternative to go with?

[vikramrajkumar]

Not happening