On 4/28/2013 8:55 PM, Peter Todd wrote:
> On Mon, Apr 29, 2013 at 03:48:18AM +, John Dillon wrote:
>> We can build this stuff incrementally I'll agree. It won't be the case that
>> one
>> in a thousand nodes serve up the part of the chain you need overnight. So
>> many
>> I am over engineerin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I would like to download the entire blockchain by hand (kind of), but
I can't find software for it. The closest thing I found is
"Bitcoin-protocol-test-harness" code, but it is two years old and
seems not to work with current bitcoin network.
Python a
On Mon, Apr 29, 2013 at 03:48:18AM +, John Dillon wrote:
> We can build this stuff incrementally I'll agree. It won't be the case that
> one
> in a thousand nodes serve up the part of the chain you need overnight. So many
> I am over engineering the solution with BitTorrent.
I think that pret
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, Apr 29, 2013 at 3:36 AM, Gregory Maxwell wrote:
> On Sun, Apr 28, 2013 at 7:57 PM, John Dillon
> wrote:
>> Have we considered just leaving that problem to a different protocol such as
>> BitTorrent? Offering up a few GB of storage capacity
While I like the idea of a client using a DHT blockchain or UTXO list, I
don't think that the reference client is the place for it. But it would
make for a very interesting experimental project!
On 29 April 2013 13:36, Gregory Maxwell wrote:
> On Sun, Apr 28, 2013 at 7:57 PM, John Dillon
> wro
On Sun, Apr 28, 2013 at 7:57 PM, John Dillon
wrote:
> Have we considered just leaving that problem to a different protocol such as
> BitTorrent? Offering up a few GB of storage capacity is a nice idea but it
> means we would soon have to add structure to the network to allow nodes to
> find
> eac
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> But I also agree that its important that be splittable into
> ranges
> because otherwise when having to choose between serving historic data
> and— say— 40 GB storage, a great many are going to choose not to serve
> historic data... and so nodes
On Sun, Apr 28, 2013 at 9:29 AM, Mike Hearn wrote:
> I'd imagined that nodes would be able to pick their own ranges to keep
> rather than have fixed chosen intervals. "Everything or two weeks" is rather
X most recent is special for two reasons: It meshes well with actual demand,
and the data is
On Thu, Apr 25, 2013 at 09:07:07PM -0400, Gavin Andresen wrote:
> On Thu, Apr 25, 2013 at 3:12 PM, Jeremy Spilman
> wrote:
>
> > Right now I'm leaning towards writing a prototype using a single cert with
> > a fingerprint of PubKey in the Subject Alternate Name, and getting PubKey
> > and Invoice
That's true. It can be perhaps be represented as "I keep the last N blocks"
and then most likely for any given node the policy doesn't change all that
fast, so if you know the best chain height you can calculate which nodes
have what.
> Disconnecting in case something is requested that isn't serv
On Sun, Apr 28, 2013 at 6:29 PM, Mike Hearn wrote:
> I'd imagined that nodes would be able to pick their own ranges to keep
> rather than have fixed chosen intervals. "Everything or two weeks" is
> rather restrictive - presumably node operators are constrained by physical
> disk space, which mean
I'd imagined that nodes would be able to pick their own ranges to keep
rather than have fixed chosen intervals. "Everything or two weeks" is
rather restrictive - presumably node operators are constrained by physical
disk space, which means the quantity of blocks they would want to keep can
vary wit
Hello all,
I think it is time to move forward with pruning nodes, i.e. nodes that
fully validate and relay blocks and transactions, but which do not keep
(all) historic blocks around, and thus cannot be queried for these.
The biggest roadblock is making sure new and old nodes that start up are
ab
13 matches
Mail list logo
