We would only end up with few copies of the historic data if users
could choose what parts of the blockchain to store. Simply store
chunks randomly, according to users available space, and give priority
to the N most recent chunks to have more replicas in the network.
You don't need bittorrent
On Thu, May 16, 2013 at 7:26 AM, Ricardo Filipe
ricardojdfil...@gmail.com wrote:
We would only end up with few copies of the historic data if users
could choose what parts of the blockchain to store. Simply store
chunks randomly, according to users available space, and give priority
to the N
You are welcome to optimise P2P addr broadcasts or develop better bootstrap
mechanisms.
On Sun, May 5, 2013 at 3:12 PM, John Dillon
john.dillon...@googlemail.comwrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Sorry I should have used the word bootstrapping there rather than
On Mon, May 06, 2013 at 10:19:35AM +0200, Mike Hearn wrote:
You are welcome to optimise P2P addr broadcasts or develop better bootstrap
mechanisms.
I think John's actually has a point here. If we're judging the quality of a
protocol change by how compatible it is with DNS seeding, then we're
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I think you too should ask yourself why you are putting so much effort into
optimizing a centralized service, the DNS seeds, rather than putting effort
into optimizing the P2P peer discovery instead. DNS seeds are a necessary evil,
one that
On Sat, May 4, 2013 at 2:07 PM, John Dillon
john.dillon...@googlemail.com wrote:
After all Peter, just like you have implemented alternate block header
distribution over twitter, in the future we should have many different means
of
peer discovery. Right now we have DNS seeds, a fixed list,
(generic comment on the discussion that spawned off: ideas about how to
allow additional protocols for block exchange are certainly interesting,
and in the long term we should certainly consider that. For now I'd like to
keep this about the more immediate way forward with making the P2P protocol
Yes, I like that better than broadcasting the exact height starting at
which you serve (though I would put that information immediately in the
version announcement). I don't think we can rely on the addr broadcasting
mechanism for fast information exchange anyway. One more problem with this:
On Fri, May 03, 2013 at 04:06:29PM +0200, Mike Hearn wrote:
That's true, but we can extend the DNS seeding protocol a little bit - you
could query current-chain-height.dnsseed.whatever.com and the DNS server
then only returns nodes it knows matches your requirement.
If you're going to take a
If you're going to take a step like that, the current-chain-height
should be rounded off, perhaps to some number of bits, or you'll allow
DNS caching to be defeated.
Don't the seeds already set small times? I'm not sure we want these
responses to be cacheable, otherwise there's a risk of a
On Fri, May 03, 2013 at 05:02:26PM +0200, Mike Hearn wrote:
If you're going to take a step like that, the current-chain-height
should be rounded off, perhaps to some number of bits, or you'll allow
DNS caching to be defeated.
Don't the seeds already set small times? I'm not sure we want
On Sun, Apr 28, 2013 at 11:51 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
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
Sounds like this part of Bitcoin (block sharing) would definitely benefit from
having a REST (HTTP) API.
REST-based web APIs are a common feature of most online services these days.
Makes writing other client services so much easier. Plus you get the benefit
of the HTTP ecosystem for free
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 engineering the
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 with
On Sun, Apr 28, 2013 at 6:29 PM, Mike Hearn m...@plan99.net 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,
On Sun, Apr 28, 2013 at 9:29 AM, Mike Hearn m...@plan99.net 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
On Sun, Apr 28, 2013 at 7:57 PM, John Dillon
john.dillon...@googlemail.com 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
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 gmaxw...@gmail.com wrote:
On Sun, Apr 28, 2013 at 7:57 PM,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, Apr 29, 2013 at 3:36 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Sun, Apr 28, 2013 at 7:57 PM, John Dillon
john.dillon...@googlemail.com wrote:
Have we considered just leaving that problem to a different protocol such as
BitTorrent?
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 pretty
21 matches
Mail list logo
