Improve MPC scaling with a cofactor

[dr-orlovsky]

Partially closes #128

Explanation:
Assume we have a set of N protocols (contracts/assets) we need to put into the same witness transaction. The task is to find a size of a Merkle tree in which all N protocol ids (256-bit numbers) will NOT have a common denominator.

In the existing algorithm, we try different Merkle tree depths D (which give tree widths of 2^D), and check that the tree widths is NOT a common denominator for all N protocols. This ends up having too large trees even for small protocols (since we try just {2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536 } as denominators).

This PR introduces a cofactor which is a variable subtracted from the denominator, which allows to try up to 256 variants around each of these powers of two. Thus, with this PR we have a set of all denominators ranging from 1 to 256 plus 256 variants on each of powers of 2 after 8.

The result is that before this PR we can fit only up to 48 contract/asset in a 16-deep tree, while with cofactor this number is increased x10 to 500.

[cryptoquick]

This is a decent solution! From what I understand, if the id collides with another id, this will add another number to it, a cofactor, until it either finds an id that doesn't collide, or it exceeds a limited number of attempts, and then this cofactor is provided when referencing this contract id.

Question, what happens when the cofactor attempts are exceeded?

[dr-orlovsky]

No, we do not add cofactor to the protocol id, since this will break anti-double-spending. Instead, we use cofactor value to slightly decrease the width of the tree getting different denominator for ALL ids.

Let's say we have ids 2097152, 4194304, 8388608 - and the tree width is 32 (depth = 5, width = 2^5=32).
For all of them, 32 is a common denominator, thus all of them divided by 32 by modulo equals to 0 - i.e. all of them pretend to be in the same slot #0. This doesn't work. So instead of going to next depth (6, resulting in width 64), we try width=32 - cofactor=1, ie. 31. Now, this number is not their common denominator, and we get normal slot allocation:

2097152 mod 31 = 2
4194304 mod 31 = 4
8388608 mod 31 = 8

Basically, position_in_the_tree = id % (2 ^ tree_depth - cofactor).

If we can't find a value which puts all ids into different slots, we are fucked (some of the contracts will be lost). However, it is impossible to search through all 2^32 values (it will take weeks), and from my estimations ~100k of contracts can be always made into different positions in an 32-deep tree within 32*256 attempts at most.

Overall, empirically I came to the conclusion that the width of the tree must be N of contracts power 4 (width = no^4) - and then we are safe and can find a non-common-denominator which puts them into different slots in just < 8192 attempts

[zoedberg]

ACK