From: Jay F <jayf@outlook•com>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Service bits for pruned nodes
Date: Sun, 28 Apr 2013 23:10:54 -0700 [thread overview]
Message-ID: <BLU0-SMTP4789CDF0A9814E7D8D2D662C8B20@phx.gbl> (raw)
In-Reply-To: <20130429035523.GA11611@savin>
On 4/28/2013 8:55 PM, Peter Todd wrote:
> On Mon, Apr 29, 2013 at 03:48:18AM +0000, 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 much sums it up.
>
> With the block-range served in the anounce message you just need to find
> an annoucement with the right range, and at worst connect to a few more
> node to get what you need.
One of the technologies that can be borrowed from Bittorrent (besides
downloading from multiple peers at once) is analysis by clients of the
part distribution, which allows a client to download and share the
least-propagated parts first to maintain high availability of the whole
file, even when not one individual currently has downloaded the complete
file (the seed has left the swarm).
Unlike Bittorrent, a partial-blockchain swarm client needs to make
informed decisions about how much to download, such as rules like "until
it sees at least 20 complete blockchain-equivalents in the swarm",
"until it has 10% of the blockchain itself", "work backwards, all blocks
from the hash tree required to verify my payments" or other minimums
that might all be criteria.
Bittorrent only considers directly connected peers' piecemaps when
making decisions of what to download. Bitcoin, however, already has a
protocol to allow peer discovery beyond the connected nodes; this could
be extended to communicate what parts the peer is hosting. Careful
thought into attack vectors would need to be paid in design, so that
only a majority of outbound-connected peers's advertisement are able to
inform consensus about part or peer availability, messages able to
remove a peer or part availability from other's lists are confirmed
independently without such removal verification generating DDOS traffic
amplification, lying clients can be marked as discovered by the
majority, etc.
Such thought doesn't have to be paid if directly implementing
Bittorrent, but it has the burden of centralized trackers or expensive
DHT, and it also doesn't have any logic informing it besides "don't quit
until I get the whole file".
next prev parent reply other threads:[~2013-04-29 6:11 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-28 15:51 Pieter Wuille
2013-04-28 16:29 ` Mike Hearn
2013-04-28 16:44 ` Pieter Wuille
2013-04-28 16:57 ` Mike Hearn
2013-05-03 12:30 ` Pieter Wuille
2013-05-03 14:06 ` Mike Hearn
2013-05-03 14:18 ` Peter Todd
2013-05-03 15:02 ` Mike Hearn
2013-05-03 15:11 ` Peter Todd
2013-05-04 18:07 ` John Dillon
2013-05-04 18:55 ` Jeff Garzik
2013-05-05 13:12 ` John Dillon
2013-05-06 8:19 ` Mike Hearn
2013-05-06 13:13 ` Pieter Wuille
2013-04-28 19:50 ` Gregory Maxwell
2013-04-29 2:57 ` John Dillon
2013-04-29 3:36 ` Gregory Maxwell
2013-04-29 3:42 ` Robert Backhaus
2013-04-29 3:48 ` John Dillon
2013-04-29 3:55 ` Peter Todd
2013-04-29 6:10 ` Jay F [this message]
[not found] ` <CAFBxzACw=G7UgG853zQrM-Z1-B4VqSQR5YUJQ5n1=wnv7EyWsw@mail.gmail.com>
2013-04-30 16:14 ` [Bitcoin-development] Fwd: " Rebroad (sourceforge)
2013-04-30 18:04 ` Jeff Garzik
2013-04-30 19:27 ` Andy Parkins
2013-04-30 19:31 ` Simon Barber
2013-04-30 20:11 ` Jeff Garzik
2013-05-01 14:05 ` Andy Parkins
2013-05-01 14:26 ` Jeff Garzik
2013-05-01 14:34 ` Andy Parkins
2013-04-30 20:06 ` [Bitcoin-development] " Brenton Camac
2013-05-01 13:46 ` Jeff Garzik
2013-05-16 11:26 Ricardo Filipe
2013-05-16 15:47 ` Jeff Garzik
2013-05-16 16:23 ` Ricardo Filipe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BLU0-SMTP4789CDF0A9814E7D8D2D662C8B20@phx.gbl \
--to=jayf@outlook$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox