Network Security Question

[puppies]

If all nodes return the same signing key for a witness and every key is on only one node then only one node will produce blocks regardless of any forks.

You could have ten nodes on ten different forks.  If all ten forks have the same signing key and that key is only loaded onto one witness node then you will not double sign blocks.  You will sign blocks on only one fork and miss blocks on the other 9. 

You don't even need to know if two nodes are on the same fork.  You just need to know what the witness signing key is currently set to.  And a way to change it from each signing node.

Am I missing some risk in this situation?  What beyond the Blockchain state of each producing node would you need?   

[emski]

I haven't completely figured out how to automate it but all we really have to do from a witness perspective is ensure that all producing nodes see the same value in get_witness["signing_key"].   If all witnesses see the same value then even if forked there will be no double signing. 

Checking the signing key and setting the signing key is relatively easy.  What I need to figure out is the logic of determining what the key should be set to.  If and when they return different on two different nodes.

Again... relying on the blockchain state to start the backup node is INCORRECT.
EDIT: Because you cannot be sure if you are on the correct fork.

[puppies]

I haven't completely figured out how to automate it but all we really have to do from a witness perspective is ensure that all producing nodes see the same value in get_witness["signing_key"].   If all witnesses see the same value then even if forked there will be no double signing. 

Checking the signing key and setting the signing key is relatively easy.  What I need to figure out is the logic of determining what the key should be set to.  If and when they return different on two different nodes.

[roadscape]

If witnesses are signing blocks on more than 1 chain, any number of bad things could happen, including your scenario.

This is why we need to see to it that going forward our auxiliary utilities grow decentralized.. monitoring/failover, price feeds, etc are all susceptible to horrific failure if everyone uses the same service/codebase. Diversification of strategies mitigates the risk by ensuring that there is never consensus on a specific failure mode.

If double-signing is 100 times worse than missing a single block, then it's better to miss 2.5 hours of block production than to double-sign. That's why I'm not in a rush to automate this.

Ideally, it would be easy to identify double-signers so they can be informed of the risks (and fired for repeat offenses).
This would be the community's job, so hopefully someone builds a "fork explorer" tool into the next bitsharesblocks

[emski]

No response ?

Imagine the following situation:

31 witnesses total.
Automated backup that works like this (from secondary node):
1 If the primary node is missing blocks publish change signing key transaction.
2 Checks the latest irreversible (by BM's definition 66% of witnesses signed (total of 21)) block and verifies that signing key is irreversibly changed.
3 Starts to sign blocks with the new key if it is irreversibly changed.

Lets we have witnesses with the above mentioned automated backup.
Lets we have a network split where witnesses are divided in two groups -> group A(21) / group B(10) .
In chain A (with 21 witnesses) we have 10 witnesses missing blocks.
In chain B (with 10 witnesses) we have 21 witnesses missing blocks.

In chain A we have 10 transactions for change of signing key (for all witnesses from group B). When these transactions are confirmed then backup nodes for group B start signing blocks.

Imagine now witnesses from A begin to lose connection to others nodes in A and connect to witnesses in B. Let this happen one witness at a time.
When first witness (X) "transfers" from A to B we will still have group A with more than 66% participation. Then X's backup node will activate (let it be connected to group A) changing signing key and starting to sign blocks => maintaining 100% participation in chain A. However the original X will continue signing blocks together with group B. If this is repeated 11 times (note that this can happen with up to 10 witnesses simultaneously) we'll have:
 Fork A with >66% active witnesses; Fork B with >66% active witnesses.

Again I'm not saying this is likely to happen but it might be doable if witnesses are able to sign in two chains simultaneously.

[emski]

The transaction with the new signing key is in ForkA.

That can't really happen .. the IRREVERSIBILITY requires 2/3 of the witnesses to sign the transaction .. hence it cannot be on the minority fork .. and if it was .. it would not have been signed by 2/3 of the witnesses ..

If what you say is true for one witness then it should be true for all of them.
If you have 17 witnesses and you have 8 that sign on two forks => you could have 2 forks with at least 12 witnesses participation ( which is 2/3 of 17).

I'm not saying it is likely but if everyone is using a solution like this it is possible.

[xeroc]

The transaction with the new signing key is in ForkA.

That can't really happen .. the IRREVERSIBILITY requires 2/3 of the witnesses to sign the transaction .. hence it cannot be on the minority fork .. and if it was .. it would not have been signed by 2/3 of the witnesses ..

[emski]

In order to change the signing key you need to do a transaction to announce the new signing key. .. once this transaction meets the irreversible block offset (30 blocks or so)
you can consider it a checkpoint and no forks are possible any more .. if only one of the machines knows the corresponding key and is THEN activated to produce blocks your are safe from signing independent forks ..

The transaction with the new signing key is in ForkA. Then ForkB could miss this transaction. Then you have NodeA signing the ForkA and NodeB signing in ForkB with the old signing key. There is NO IRREVERSIBLE block offset incase of witnesses double signing blocks as you might have 2 valid chains with >50% participation. This was discussed numerous times before...

[xeroc]

In order to change the signing key you need to do a transaction to announce the new signing key. .. once this transaction meets the irreversible block offset (30 blocks or so)
you can consider it a checkpoint and no forks are possible any more .. if only one of the machines knows the corresponding key and is THEN activated to produce blocks your are safe from signing independent forks ..

[emski]

We've recently discussed some witness automated backup solutions that could possibly end up signing 2 different forks for a single witness.
In such case (assuming more than one witness use the script) we could have multiple forks with >50% participation which  is obviously extremely undesired.
We had a relatively easy way to check if someone signs in two forks in BTS 1.0 (and we had a massive amount of double signers).

My question to @Bytemaster is how do we guarantee this doesn't happen.