Assume malicious signers

[rantan]

The current spec doesn't assume the participation of malicious signers. So that if the malicious signers participate in the Tapyrus Signer Network, there are possibilities for attacks.

I would propose that we can consider this thing with the following steps.

1. Make clear what kind of motivations to attack are exist.
2. Make clear what kind of attach vectors exist for each motivation.
3. Make clear how to avoid each attack vector.

First of all, I'm going to try 1st and 2nd steps. Regarding the 3rd step, I think it is better to create other issues for each attack vector.

The motivations of the malicious signers

• The malicious signers want to get more coinbase outputs.
• The malicious signers want to obstruct the block generation.

The malicious signers want to get more coinbase outputs.

A Master of a Round can propose a candidate block. And its coinbase tx script pubkey is under control of the Master. In short, signers can get more coin, if the signer more works as a Master.

Attack Vectors

• Acts as a Master in all each Round.

Acts as a Master in all each Round

In the current implementation, signer nodes start to act as a Member in the Round whose Master is the sender of the candidateblock message when the node receives candidateblock message anytime.

The malicious signers want to obstruct the block generation.

In this case, the block generation has to work if the number of malicious signers is less than one three of all signers.

Attack Vectors

• Acts as a Master in all each Round, then never submit a new block.
• Never sent blocksig message after the attacker node is chosen as one of the block participants.

Acts as a Master in all each Round, then never submit a new block.

In the current implementation, signer nodes start to act as a Member in the Round whose Master is the sender of the candidateblock message when the node receives candidateblock message anytime.

1. The attacker participates in a Round as a Member.
2. The Master of the Round starts with broadcasting a candidateblock message.
3. The attacker receives a candidateblock message.
4. The attacker broadcasts a candidateblock message.
5. The attacker does nothing.
6. The Round that is created by the attacher's candidateblock message is timeout. The Round is a failure.

Never sent blocksig message after the attacker node is chosen as one of the block participants.

In the current spec, a Master node of a Round sends blockparticipants message if the number of collecting Block VSS met the threshold. If the attacker node is chosen as one of the block participants, the attacker can obstruct the signature aggregation with never sending blocksig message.

---

I am welcome any additions to each step.

[Yamaguchi]

The motivations of the malicious signers

• The master of the round may select transaction which is included in the block. So the malicious signer may create multiple transactions which spent the same UTXO and pay something with these tx, and then generate block which contains only one transaction out of these transactions.

To avoid such kind of attacks, applications should not allow payment with 0-confirmation.

[Yamaguchi]

The malicious signers want to obstruct the block generation.

In this case, the block generation has to work if the number of malicious signers is less than one three of all signers.

I think the Tapyrus Signer Network needs at least as many honest signers as threshold value.
Actually, all signer must not be "malicious" if threshold value is the number of signers