[Nix-dev] Funding Hydra Development
ak at formalprivacy.com
Thu Jan 22 16:12:14 CET 2015
On Thu, Jan 22, 2015 at 1:52 PM, Vladimír Čunát <vcunat at gmail.com> wrote:
> This thing is about trust, and personally I'd prefer signing the
> derivation->output hash pairs and having some web-of-trust-like solution.
> (Although some build redundancy is certainly good, for multiple reasons.)
> The problem with seti at home -like solutions is that verifying correctness
> is generally no cheaper than full rebuild.
Yes, you need some rebuilds. In a large network that should not be a
problem IMO. Any distributed system with redundancy needs to do redundant
> Therefore, the untrusted computers bring very little added value. (They
> can distribute the content signed by trusted people, but distribution isn't
> much of a problem in our case, IMHO.)
I don't understand how this follow from the previous point. Yes the
untrusted computer needs to be associated with a crypto key so there is
some consequence of it lying. That's better. However, a completely
untrusted computer can still be used to generate contested outputs (look
for signed outputs that are lying). A contested output is valuable as
something that many people can try building so we can figure out how to
react to the person that signed the output (was it a flaky build,
Thus a normal NixOS (unknown, untrusted computer) can still recompile some
random package that is being installed in order to strengthen trust in the
> On 01/22/2015 01:29 PM, Wout Mertens wrote:
>> Then you could do something like, have 1000 builders, and if 501
>> builders get the same output hash for a derivation, it gets accepted on
>> the public ledger of input/output hashes.
> I'm not sure about such schemes either. It isn't very economical to build
> everything 1000-times. I do see the bitcoin-like inspiration (I guess), but
> I wouldn't apply it here, at least not in this way.
> (Do we want to give most decision power to those who make most claims on
> the build results? Even if we extend them with some additional
Comparing to bitcoin or consensus protocols is not correct. In bitcoin or
consensus protocols we try to agree on *an order of events*. Therefore we
need a majority to agree. The problem we have here is agreement on a
mapping a set of inputs to a set of outputs. This can be done fully in
parallel and only a single proof of cheating is enough to prove that
someone is dishonest and do whatever is needed to kick them out.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nix-dev