Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.175 as permitted sender)
	client-ip=74.125.82.175; envelope-from=grarpamp@gmail.com;
	helo=mail-we0-f175.google.com; 
MIME-Version: 1.0
In-Reply-To: <CA+s+GJCh4n2BAj=sFfUnUBgcJuJ9EPe=5qYftZ8SogDX_EQATg@mail.gmail.com>
References: <CAD2Ti2_vGc+SJX_+uTz4ZVk1r5DhCOm6n3yKW16o9QaPKTQkHQ@mail.gmail.com>
	<CA+s+GJCh4n2BAj=sFfUnUBgcJuJ9EPe=5qYftZ8SogDX_EQATg@mail.gmail.com>
Date: Wed, 8 Feb 2012 14:32:33 -0500
Message-ID: <CAD2Ti2-JtfF09e_4b3HKn4a+GYKj72tgR2aQ-WpiKXZAwA9uvg@mail.gmail.com>
From: grarpamp <grarpamp@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=UTF-8
Subject: Re: [Bitcoin-development] Scaling at the end user level
Precedence: list

>> Have any groups published proposals for distributing
>> a weekly precomputed bootstrap chain?
>> rsync? db_dump > git > db_load?
>> There is also 50% or more compression available in the index
>> and chain.

> I have proposed packaging part of the block chain (doesn't even have to be
> weekly, just until the last checkpoint), but people fear it runs contrary to
> the distributed approach of Bitcoin.

Git repos are backed by strong hashes. Each commit could be a single
block dump, perhaps into a file hierarchy. Trusted entities, pools, etc
could sign at a checkpoint/height. Blockchain tools
would need made that can take the blk* and export single blocks and
process/export up to a certain block and quit. Everyone would do a
comparison and sign a commit hash. Everyone else git pulls. Having
the block toolset is a key prequisite to any sort of distribution. They don't
exist now :( Maybe the two bitcoin compatible library projects out there
will implement them :) Torrents are also strongly hashed and could be
signed as well.

Making the blockchain tools would be the most important thing to start.

> BTW: On such an old computer you should probably use one of the thin
> clients.

If that means not validating the chain, then it's as above. I'm not sure if it's
right to not care about the history if only making new transactions with a new
key post install time and then only validating new transactions as they come
in. Will have a look.