[anomalroil]

Yes and no: it's not a blockchain. It's relying on the fact that the drand network is producing distributed, verifiable randomness using a threshold scheme with distributed key generation. So the secret key of the group is never in memory on any device and the only way to obtain a valid signature for a message is by having a threshold number of "partial signatures" being produced by the drand nodes in the network. Currently it relies on the League of Entropy network, run by Cloudflare, Protocol Labs, Ethereum Foundation, Kudelski Security and other organizations, including multiple universities. So the security is relying on the fact that the network's goal is to produce public randomness, and that parties have no reason to collude. For instance the League of Entropy is used for leader election and randomness by Filecoin, so it's already "securing" a lot of things, adding timelocked data on top seems like a nice way to use the network. And yeah, if there are ever a threshold of nodes colluding to produce a signature "too early", that's sadly not detectable.

[eis]

> Yes and no: it's not a blockchain. It's relying on the fact that the drand network is producing distributed, verifiable randomness using a threshold scheme with distributed key generatio

Hm ok, it's just that there is a lot of blockchain terminology used throughout drand like "testnet", "mainnet", "chain" and so on. Seems very similar to a blockchain with similar attack scenarious but I guess it's not exactly a blockchain but somewhat similar?

> Currently it relies on the League of Entropy network, run by Cloudflare, Protocol Labs, Ethereum Foundation, Kudelski Security and other organizations, including multiple universities. So the security is relying on the fact that the network's goal is to produce public randomness, and that parties have no reason to collude. For instance the League of Entropy is used for leader election and randomness by Filecoin, so it's already "securing" a lot of things, adding timelocked data on top seems like a nice way to use the network.

I see so there is a closed group of more or less well known entities which hopefully wont be dishonest to a major degree. Closed group being the key here because that prevents whole range of attacks, most importantly sybil attacks. So the trust in the system derives from the trust into the participants.

Without researching it more I would guess that during encryption it might use the public keys of the nodes plus the round number with the threshold scheme and when the round finally arrives, the nodes then publish their private keys for this round?

I think I have a better idea of the system now. Judging by me being not the only one here who didn't understand how things work on a high level maybe the README could be expanded a bit. That would be great.

[miketery]

Thanks for sharing these randomness sources, will have to explore them.

To me the beautiful thing about trying to get randomness is that as long as you have one random source then you have randomness. I.e. non-random XOR random => random.

So, you use X sources, as long as one of them is truly random then you are golden. Even if most are compromised it shouldn’t matter. Use on device security chip randomness, use user input, use external party providers etc. it all helps! (But be careful to errors when implementing, that’s hard to do!)

[heinrich5991]

> To me the beautiful thing about trying to get randomness is that as long as you have one random source then you have randomness. I.e. non-random XOR random => random.

Only if the sources choose their numbers independently of each other. If the non-random is a function of the random source (e.g. the identity), then the result isn't random, it's a constant 0.

[anomalroil]

Also, be careful of a "last player attack" when XORing randomness: if your last source could spy on the state of your buffer, or on all other randomness sources, it can trivially craft a string that would XOR to a specific value once XORed with the other sources.