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 --]
next prev parent 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 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$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=john.dillon892@googlemail$(echo .)com \
/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