AIP38

[faustbrian]

Discussion for https://github.com/ArkEcosystem/AIPs/blob/master/AIPS/aip-38.md

[Moustikitos]

Hi,

Maybe best for block signature is to use SCHNORR ones and check if signature size equals 128.
https://github.com/sipa/bips/blob/bip-taproot/bip-0340.mediawiki

[faustbrian]

AIP38 will only introduce a new consensus model, switching to a new cryptography algorithm isn't necessary to achieve this. The proposal signatures are made up of the signatory public key and signature so the signature can be retrieved by slicing off the public key and use the remainder as signature.

[Moustikitos]

Just worying about ECDSA signature maleability, but you're right, concensus model first.

[Moustikitos]

Is there a way to include an equivalent of lisk-bft concensus ?
https://medium.com/lisk-blog/lisk-improvement-proposals-introduce-byzantine-fault-tolerance-consensus-algorithm-for-lisk-ab6c8b728744

[rainydio]

I think it should require 66% of vote balance, not validator count.

[faustbrian]

What would the reason for this be? 66% of validators guarantees that the "people" that were elected will act in a way they are supposed to and if not people can just remove their funds from malicious validators. With 66% of vote balances a few whale validators can control take over the network.

[rainydio]

There is a problem in reference implementation. There is no timestamp check when new proposal replaces previous because generatorPublicKey doesn't match. Network will likely stuck in endless loop sending proposals that override each-other and never reach 66%.

1. Simultaneously due to lag validator1 and validator2 create conflicting proposals (validator1 has proposal1, validator2 has proposal2).
2. Both receive each other's proposals which replaces previously stored (validator1 has proposal2, validator2 has proposal1).
3. They broadcast, and receive each other's proposals again repeating the cycle (validator1 has proposal1, validator2 has proposal2).

Eventually due to missed blocks every validator will be dragged into this cycle.

---

1. New proposal timestamp must be higher then previous.
2. New proposal timestamp cannot be higher than current time.

[rainydio]

This definitely can be done in separate AIP, but collected signatures should be included into block itself so others can verify that new block successfully collected 66% when it was forged. Otherwise this consensus is voluntary, forger can ignore it by commenting out single line.

[faustbrian]

Not sure that I understand the issue with the signatures not being included in the block. The signatures are included in the final block that is forged. You propose a block with transactions and if the majority agrees that it should be the next block then the validator of the proposal will forge a new block that contains the signatures array with signatures of other validators and the signature property which is his own signature that signed the whole block.

[Moustikitos]

The idea to use only 66% of delegate is relevant to me. A delegate node will always be online because of the individual(s) being engaged on it. Adding the constraint on timestamp is relevant too because of time sync between nodes.

Interesting thing about lisk bft is the inheritance of network vote. A delegate should only vote for a block that is immediate child of a block previously voted by the same delegate. So in signature criteria check it could be :

• 5b. If delegate signature matches and delegate signature misses in lastBlockHeight reject block

This criteria implies that 100% of delegate have to sign lastBlockHeight block, even if there is a new delegate on a round.