public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Robert Backhaus <robbak@robbak.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Service bits for pruned nodes
Date: Mon, 29 Apr 2013 13:42:46 +1000	[thread overview]
Message-ID: <CA+i0-i-WxkKU3U9LKpVR57JsCZ4_-hX1XpAgNt_w_2Pb1kVDEg@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgRR3K_dVMhOSHpga91tFaK7G99ouKLFpXHbgxEsvY+_Wg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3283 bytes --]

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 <gmaxwell@gmail.com> wrote:

> On Sun, Apr 28, 2013 at 7:57 PM, John Dillon
> <john.dillon892@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 allow nodes
> to find
> > each other to actually get that data. BitTorrent already has that issue
> thought
> > through carefully with it's DHT support.
>
> I think this is not a great idea on a couple levels—
>
> Least importantly, our own experience with tracker-less torrents on
> the bootstrap files that they don't work very well in practice— and
> thats without someone trying to DOS attack it.
>
> More importantly, I think it's very important that the process of
> offering up more storage not take any more steps. The software could
> have user overridable defaults based on free disk space to make
> contributing painless. This isn't possible if it takes extra software,
> requires opening additional ports.. etc.  Also means that someone
> would have to be constantly creating new torrents, there would be
> issues with people only seeding the old ones, etc.
>
> It's also the case that bittorrent is blocked on many networks and is
> confused with illicit copying. We would have the same problems with
> that that we had with IRC being confused with botnets.
>
> We already have to worry about nodes finding each other just for basic
> operation. The only addition this requires is being able to advertise
> what parts of the chain they have.
>
> > What are the logistics of either integrating a DHT capable BitTorrent
> client,
> > or just calling out to some library? We could still use the Bitcoin
> network to
> > bootstrap the BitTorrent DHT.
>
> Using Bitcoin to bootstrap the Bittorrent DHT would probably make it
> more reliable, but then again it might cause commercial services that
> are in the business of poisoning the bittorrent DHT to target the
> Bitcoin network.
>
> Integration also brings up the question of network exposed attack surface.
>
> Seems like it would be more work than just adding the ability to add
> ranges to address messages. I think we already want to revise the
> address message format in order to have signed flags and to support
> I2P peers.
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 4108 bytes --]

  reply	other threads:[~2013-04-29  3:48 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-28 15:51 [Bitcoin-development] Service bits for pruned nodes 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 [this message]
2013-04-29  3:48         ` John Dillon
2013-04-29  3:55           ` Peter Todd
2013-04-29  6:10             ` Jay F
     [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=CA+i0-i-WxkKU3U9LKpVR57JsCZ4_-hX1XpAgNt_w_2Pb1kVDEg@mail.gmail.com \
    --to=robbak@robbak.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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