You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All benchmarking and efficiency analysis so far involves assuming transactions are constant size. In some applications transactions submitted by users may need to vary in size. For example, Ethereum transactions can provide data, Bitcoin transactions spend varying numbers of inputs.
The efficiency proof depends on assuming transactions can be randomly selected uniformly random. Does it hold if some transactions are large?
The text was updated successfully, but these errors were encountered:
Also handles case where BA value is not equal to coin
fixesamiller#8
Except for the blocking operation of getting the coin, the code that is
extracted into a function corresponds to phase 3 described in [MMR14];
lines 7-11 in fig. 2 (A BV-broadcast-based algorithm implementing binary
consensus ...).
All benchmarking and efficiency analysis so far involves assuming transactions are constant size. In some applications transactions submitted by users may need to vary in size. For example, Ethereum transactions can provide data, Bitcoin transactions spend varying numbers of inputs.
The efficiency proof depends on assuming transactions can be randomly selected uniformly random. Does it hold if some transactions are large?
The text was updated successfully, but these errors were encountered: