From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from <wendel@314t.com>) id 1VBXwC-0005oh-Iy for bitcoin-development@lists.sourceforge.net; Mon, 19 Aug 2013 22:28:36 +0000 X-ACL-Warn: Received: from mail-gh0-f170.google.com ([209.85.160.170]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VBXwA-0006a0-Sg for bitcoin-development@lists.sourceforge.net; Mon, 19 Aug 2013 22:28:36 +0000 Received: by mail-gh0-f170.google.com with SMTP id z10so1055675ghb.15 for <bitcoin-development@lists.sourceforge.net>; Mon, 19 Aug 2013 15:28:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=TeDFy1/UJ1MsEq6xlJpHbtBT8YrQFblfmPMDULfWATA=; b=XETp5RIk4IoFx3/sKACskamQSfGEC98+kdM6CSvknu9nd/aZyPQ+AN7qFlc6rd/gCm NuRx1v1QQASfMqh7XJOKochtHohMHA1NcLR0xWBR9/e+SP/s+AB1k34Py6p94E8OnzO6 6qK+9EOkq2/5TQ9cbQv2XRVCMFP1SdPw9NXXwphrpWH6m8S/qWNBJYlsnw8n8LfIaQQM rvgGKMPCZzn89iqg6NCu/ek/+wMdFdnHbvjOcfg/jLsd+4u8mXWR3Gq4cDm8rWGAdiNo uAf/9bWV5+e9W6Xco5c1AfYxW98lQyZPBleT1O0B7gLhlcikAtzhckafoclAVAmBPa86 7zNw== X-Gm-Message-State: ALoCoQl42uMIIuoGu8dFGOYPFevD4hn3NioiGR2+NJXYpvbkH9+90N0Y1D+YSCvJOAeRwyeXnFUP X-Received: by 10.236.153.169 with SMTP id f29mr46923yhk.82.1376949464509; Mon, 19 Aug 2013 14:57:44 -0700 (PDT) Received: from [127.0.0.1] ([96.47.226.19]) by mx.google.com with ESMTPSA id g25sm16399504yhg.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Aug 2013 14:57:43 -0700 (PDT) Sender: Wendell <wendel@314t.com> Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_CFC2C841-B982-44C7-9763-5494AB9A72ED"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Wendell <w@grabhive.com> In-Reply-To: <CAPaL=UWH=3qj7AW-azrO9rJqRj3BKBff8-eETfF03po9kPJO4g@mail.gmail.com> Date: Mon, 19 Aug 2013 23:57:06 +0200 Message-Id: <D31E9305-773C-4760-BD15-AB5C2E63D723@grabhive.com> References: <20130819001357.GA4281@savin> <CABsx9T3MFqmLchc1Uu20BhiVKsYWFtt0eneVSey846y2hdQ7Rg@mail.gmail.com> <CAPaL=UWH=3qj7AW-azrO9rJqRj3BKBff8-eETfF03po9kPJO4g@mail.gmail.com> To: John Dillon <john.dillon892@googlemail.com> X-Mailer: Apple Mail (2.1283) X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1VBXwA-0006a0-Sg Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> Subject: Re: [Bitcoin-development] Bloom io attack effectiveness X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: <bitcoin-development.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> List-Post: <mailto:bitcoin-development@lists.sourceforge.net> List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> X-List-Received-Date: Mon, 19 Aug 2013 22:28:36 -0000 --Apple-Mail=_CFC2C841-B982-44C7-9763-5494AB9A72ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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. >=20 > 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 =3D=3D data chokepoint =3D=3D = 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. >=20 > 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. >=20 > Tell me, when my decentralization pull-req is voted on, which way are = you > planning on voting? --Apple-Mail=_CFC2C841-B982-44C7-9763-5494AB9A72ED Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQIcBAEBAgAGBQJSEpSzAAoJECAN2ykHU5Y6xqQQALKcFiY5Z43emRNaHDaWjTku vGOLAsffM5lLP7ybXqneVRHyQRLtoGmsVq4gfi0+lQqibdI4ZjE9f/3Tsnijcvru aPCeJ9oIeGbdRRXrov3NOixbjbbMaScGafWycfvXUp9QD0m2nBDH+O+krLF6OMrm vz2kW4Y9RkbprvA4TL3F2vfBB9c+V3Rs5/Y0mjC/muHsF6N1RKhco+Cwjq3aXfHb ec1ELyygkdBoVKOdkL+XGlQWDfh1zrWEpL+DYsFO17O5cNZX6CVfz/F7HRw8W0Qe K3lKtq5LMRfs97VecsD1ULtOYk0H/mH6bGxzKsQ/QWI3x+n/G5EIYVJjktBBY3IG HEd5yosWrhkZMFIwtPL25VbmgG+IPM7XJCkQKbUUJ7OjI9YW5TTJmng2NuT0y8kd fnMGJZ3DPf9s1twZqTNwwc7lXOR4v1/zv3U4Tx6ehXQGSw/F8gAPfh8TbnAsvvF3 2KWBiaVOubbDrR6xpHE/2+tiyMHRLkfLNH6FQ2ukXk5/2MxjSSyf0L4srrBW/MvH NzOoi5Qeeie83sWffVB8ZXduD3MoRRw6K7f6ViHvLyq9pIN1djJ/mUhxlhv+ls1L VE2ZVzR9VE6b6jeBVQKok4BYmkPzy9H1kg/zmmEZXggvZFfTCo4KQQIHAojhh5pq sgiFRMmmN8rM0D2sR0/e =RN3Q -----END PGP SIGNATURE----- --Apple-Mail=_CFC2C841-B982-44C7-9763-5494AB9A72ED--