[Nix-dev] Funding Hydra Development

[Alexander Kjeldaas]

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.)
>
>
Absolutely.


> 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
work.


> 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,
non-determinism, attack).

Thus a normal NixOS (unknown, untrusted computer) can still recompile some
random package that is being installed in order to strengthen trust in the
official builds.


> 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
> proof-of-work?)
>
>
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.

Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150122/da7a62ae/attachment-0001.html