Avoid sending decryption signatures multiple times

[jannikluhn]

At the moment, sending a new aggregated decryption signature is triggered by receiving a new unaggregated signature (and we have enough of them in the db). This means we send many unnecessary ones.

• store aggregated signatures in db table (one per hash)
• only broadcast signature when none is in db already

[cducrest]

Do we want to handle received aggregated signatures? We could store them in the db and not need to broadcast them (as we already broadcast them when we received them). As a result we would not need create a new aggregated signature.

It should rarely happen that we ever receive an aggregated signature without being able to create one ourselves (or having already created one)since our peers should have sent us every signature they have seen.

I decide not to handle this case for now.

[jannikluhn]

I think we should at some point, but not now. Ideally, every node waits a random amount of time before creating the aggregated signature so that it (a) includes signatures of mos nodes and (b) only one node generates it.

It should rarely happen that we ever receive an aggregated signature without being able to create one ourselves (or having already created one)since our peers should have sent us every signature they have seen.

I think it will happen often because of symmetry: every node is equal, so every node will receive enough signatures at roughly the same time, so every node will send the aggregated signature at roughly the same time. That is, unless latency or connectivity differences become too big. But we'll see.