public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Wendell <w@grabhive.com>
To: John Dillon <john.dillon892@googlemail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bloom io attack effectiveness
Date: Mon, 19 Aug 2013 23:57:06 +0200	[thread overview]
Message-ID: <D31E9305-773C-4760-BD15-AB5C2E63D723@grabhive.com> (raw)
In-Reply-To: <CAPaL=UWH=3qj7AW-azrO9rJqRj3BKBff8-eETfF03po9kPJO4g@mail.gmail.com>

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

John,

I for one support your rallying cry of decentralization.

If you are implying that even 10,000 full nodes seems far, far too few for a distributed system that may ultimately face a very well-connected and well-funded threat model, I agree with you completely. However, I took Gavin's statement to mean something like a factual statement about the load-bearing nature of that many nodes, rather than an actual target number for some future iteration of the network.

Partial UTXO sets sound like a great idea -- are they really being ignored? I am pretty new to the development process here, but I assumed (as with many open source projects) that ideation, debate and implementation take a while to churn. Has a prototype of that been developed already, are you implying that you funded something like that and it never got built? If there are some GitHub links that I missed, please send them over.

Maybe you should open that topic back up in its own thread, so we can bring it back into view?

-wendell

grabhive.com | twitter.com/grabhive | gpg: 6C0C9411

On Aug 19, 2013, at 4:53 AM, John Dillon wrote:

> So tell us how is your "vision" of 10,000 big beefy full nodes with SPV peers
> any different from the Electrum model? These days Electrum clients have block
> headers and verify that transactions have merkle paths to the block headers.
> The only difference I see is that SPV uses bloom filtering and Electrum can
> query by transaction. But Mike wants to add querying by transaction to full
> nodes anyway, and one of the purported advantages of this UTXO proof stuff is
> that you can query servers for UTXO's by address, so I see no difference at
> all. A patch to do bloom filtering on Electrum would be amusing to me.
> 
> Here you have Peter talking about clever ways to actually get decentralization
> by having SPV peers donate back to the network with spare bandwidth, like
> relaying blocks, not to mention his partial UTXO set ideas, and you completely
> ignore that. But I guess that would raise ugly questions when people realize
> they can't now contribute back to Bitcoin, because the blocksize is a gigabyte
> of microtransactions... It may also raise ugly questions with regulators that
> may find the idea of "full node == data chokepoint == regulatory chokepoint" an
> attractive notion. Why are there not any competent people other than Peter who
> really have the guts to bring up these proposals? I've little luck getting
> proof-of-concepts built for money anyway. Maybe we just have a darth of smart
> competent people in this space.
> 
> You do a good job of signaling your priorities Gavin. The payment protocol
> includes no notion that you may want to pay anyone but a SSL certified
> merchant. Yes I know the crypto can be upgraded, but it says volumes that you
> pushed for that first, without even the slightest token effort to allow
> individuals to participate in any way. Sad given you have made things *less*
> secure because there is no safe way to get money *into* my wallet with the
> payment protocol, but could have been.
> 
> Tell me, when my decentralization pull-req is voted on, which way are you
> planning on voting?


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

  reply	other threads:[~2013-08-19 22:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-19  0:13 [Bitcoin-development] Bloom io attack effectiveness Peter Todd
2013-08-19  0:59 ` Gavin Andresen
2013-08-19  1:34   ` Peter Todd
2013-08-19  2:53   ` John Dillon
2013-08-19 21:57     ` Wendell [this message]
2013-08-19  9:29 ` Mike Hearn

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=D31E9305-773C-4760-BD15-AB5C2E63D723@grabhive.com \
    --to=w@grabhive.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=john.dillon892@googlemail.com \
    /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