Rents should be due at specific bitcoin block #s so that any temporary forks on the bitcoin chain won't result in permanent forks on the BitDNS chain.  Once all miners see the same rent payment / non-payment at the said bitcoin block #, the fork will heal by global acceptance or rejection of the take-over block.  Might even want to have a "look-back" of a few hours in the bitcoin chain to eliminate this source of instability.

I have an initial implementation of the VM based build process.

The code is here: https://github.com/devrandom/gitian-builder

You will also need a build descriptor file, which is here: https://gist.github.com/803438 .  The file wxWidgets-2.9.1.tar.bz2 goes in the ./inputs directory.

This builds a 64 bit executable with an sha256sum of 53c586ca76d6548a722c11ab3e51936d2bc185d60cd7234314896aa0c1ae5d1e.  Let me know if you get anything different.  My host is Ubuntu Maverick, but this should not matter to the result.  The environment report is captured in the result directory.

Still to do:

* Generate a tar.gz file instead of just an executable.  This will require fixing the timestamps and compiling for 32 and 64 bits.
* Pin the deb package versions so that future upgrades to the target OS don't cause changes to the result.

The threat model that I think we could target here is a compromise of the build process, either by the builder or by a third party attacking their build environment.  An assertion from multiple builders that [source checksum, build script, build environment checksum] produces [executable checksum] gives high assurance that no such compromise occurred.

I'm going to spend some time on this for the linux environment in the next few days.

Just to list potential sources of non-determinism that I know of when building on linux:

• zip/gzip (timestamps)
• tar (timestamps)
• dependencies (libraries, headers)
• compilers
• things I am forgetting right now

For other platforms there might be additional sources.  For things like zip/gzip/tar, it would be best to have a fixup tool that sets the timestamps to an agreed value.  For dependencies and compilers, we need a reference build platoform, such as a VM build script.


My initiative (mentioned above) is for software distribution as a whole.  For that, it would be good to based all software distribution on multiple code signers.  For bitcoin itself, I agree that it's not yet appropriate, since there are easier attack vectors at this point.

The build environment can be specified as a VM build script.  Such as script will be relatively simple and easy to audit.

On Ubuntu/Debian, this could be done with a vmbuilder setup.  This would include vmbuilder config files and execscripts.  It would still be good to capture the set of packages installed, maybe with aptproxy or possibly just the version list and sha sums, so that the build is fully reproducible.

This of course assumes that the distributions are reliable, as we would depend on the distribution signature to certify that the distribution wasn't tampered with and is free of trojans.  In the future, it would be good to build an entire distribution from scratch and then use that as a trusted base.

I started an initiative ( https://gitian.org/  ) for exactly this purpose.  My motivational article is here: http://hyper.to/blog/link/attack-scenarios-software-distribution/

What is needed is a deterministic build process.  I would love to collaborate on tools to achieve this.