diff options
| author | Gregory Maxwell <gmaxwell@gmail.com> | 2012-12-04 21:54:52 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2012-12-05 02:54:58 +0000 |
| commit | 00402d190495ff6d040ac4349c4797d9e19c354a (patch) | |
| tree | 81cba101f12ad52e2679ec887e1935e3cd6a6231 | |
| parent | 20e39a344f80cef4446794781b247fb82f29c4da (diff) | |
| download | pi-bitcoindev-00402d190495ff6d040ac4349c4797d9e19c354a.tar.gz pi-bitcoindev-00402d190495ff6d040ac4349c4797d9e19c354a.zip | |
Re: [Bitcoin-development] Roadmap to getting users onto SPV clients
| -rw-r--r-- | 02/a22f53b24df15a18463252c6e20fcff7c7dd16 | 179 |
1 files changed, 179 insertions, 0 deletions
diff --git a/02/a22f53b24df15a18463252c6e20fcff7c7dd16 b/02/a22f53b24df15a18463252c6e20fcff7c7dd16 new file mode 100644 index 000000000..e26630dad --- /dev/null +++ b/02/a22f53b24df15a18463252c6e20fcff7c7dd16 @@ -0,0 +1,179 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <gmaxwell@gmail.com>) id 1Tg58U-0002V5-M1 + for bitcoin-development@lists.sourceforge.net; + Wed, 05 Dec 2012 02:54:58 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.223.175 as permitted sender) + client-ip=209.85.223.175; envelope-from=gmaxwell@gmail.com; + helo=mail-ie0-f175.google.com; +Received: from mail-ie0-f175.google.com ([209.85.223.175]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1Tg58T-0001xS-Qi + for bitcoin-development@lists.sourceforge.net; + Wed, 05 Dec 2012 02:54:58 +0000 +Received: by mail-ie0-f175.google.com with SMTP id qd14so7552711ieb.34 + for <bitcoin-development@lists.sourceforge.net>; + Tue, 04 Dec 2012 18:54:52 -0800 (PST) +MIME-Version: 1.0 +Received: by 10.43.49.199 with SMTP id vb7mr13167114icb.6.1354676092583; Tue, + 04 Dec 2012 18:54:52 -0800 (PST) +Received: by 10.64.171.73 with HTTP; Tue, 4 Dec 2012 18:54:52 -0800 (PST) +In-Reply-To: <50BEACAB.3070304@gmail.com> +References: <CANEZrP3=GdyTe+2=cp-ROOJ8_t=yCqO-7GQ4hA-3aksg46p+ww@mail.gmail.com> + <CAAS2fgQYV7aR86QOwvqMLpFZ+MAwSOSZvV6XuZdXvqjeYziRng@mail.gmail.com> + <CANEZrP3ZhNYrgQZT4qOohejs3yhgt0c_kT5zwAUVtPP1Q9f1Zg@mail.gmail.com> + <CAAS2fgSJhX4974BdWGdyJA13kHg7mTgHadC6UdhdUPu0bDDXFg@mail.gmail.com> + <CALf2ePw82wt08_G2RtUYEBxorjY1ryZ4r+W7atSzDLYMU+rGGQ@mail.gmail.com> + <CAAS2fgQewysOG7eOHQxmLup4oLJK=jY=q-_4qTL6yKQ855g3ew@mail.gmail.com> + <50BEACAB.3070304@gmail.com> +Date: Tue, 4 Dec 2012 21:54:52 -0500 +Message-ID: <CAAS2fgRfUMYwOE51+eY5QE8nDNV==G1OBRzM1AuHjYmYwTFiow@mail.gmail.com> +From: Gregory Maxwell <gmaxwell@gmail.com> +To: Alan Reiner <etotheipi@gmail.com> +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable +X-Spam-Score: -1.6 (-) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (gmaxwell[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1Tg58T-0001xS-Qi +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV clients +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: Wed, 05 Dec 2012 02:54:58 -0000 + +On Tue, Dec 4, 2012 at 9:08 PM, Alan Reiner <etotheipi@gmail.com> wrote: +> Our divergence is on two points (personal opinions): +> +> (1) I don't think there is any real risk to the centralization of the +> network by promoting a SPV (purely-consuming) node to brand-new users. +> In my opinion (but I'm not as familiar with the networking as you), as +> long as all full nodes are full-validation, the bottleneck will be +> computation and bandwidth, long before a constant 10k nodes would be +> insufficient to support propagating data through the network. + +Not so=E2=80=94 a moderately fast multicore desktop machine can keep up wit= +h +the maximum possible validation rate of the Bitcoin network and the +bandwidth has a long term maximum rate of about 14kbit/sec=E2=80=94 though +you'll want at least ten times that for convergence stability and the +ability feed multiple peers. + +Here are the worst blocks testnet3 (which has some intentionally +constructed maximum sized blocks),E31230 : +(with the new parallel validation code) +- Verify 2166 txins: 250.29ms (0.116ms/txin) +- Verify 3386 txins: 1454.25ms (0.429ms/txin) +- Verify 5801 txins: 575.46ms (0.099ms/txin) +- Verify 6314 txins: 625.05ms (0.099ms/txin) +Even the slowest one _validates_ at 400x realtime. (these measurements +are probably a bit noisy=E2=80=94 but the point is that its fast). +(the connecting is fast too, but thats obvious with such a small database) + +Although I haven't tested leveldb+ultraprune with a really enormous +txout set or generally with sustained maximum load=E2=80=94 so there may be +other gaffs in the software that get exposed with sustained load, but +they'd all be correctable. Sounds like some interesting stuff to test +with on testnet fork that has the POW test disabled. + +While syncing up a behind node can take a while=E2=80=94 keep in mind that +you're expecting to sync up weeks of network work in hours. Even +'slow' is quite fast. + +> In fact, +> I was under the impression that "connectedness" was the real metric of +> concern (and resilience of that connectedness to large percentage of +> users disappearing suddenly). If that's true, above a certain number of +> nodes, the connectedness isn't really going to get any better (I know +> it's not really that simple, but I feel like it is up to 10x the current +> network size). + +Thats not generally concern for me. There are a number of DOS attack +risks... But attacker linear DOS attacks aren't generally avoidable +and they don't persist. + +Of the class of connectedness concerns I have is that a sybil attacker +could spin up enormous numbers of nodes and then use them to partition +large miners. So, e.g. find BitTaco's node(s) and the nodes for +miners covering 25% hashpower and get them into a separate partition +from the rest of the network. Then they give double spends to that +partition and use them to purchase an unlimited supply of digitally +delivered tacos=E2=80=94 allowing their captured miners to build an ill fat= +ed +fork=E2=80=94 and drop the partition once the goods are delivered. + +But there is no amount of full nodes that removes this concern, +especially if you allow for attackers which have compromised ISPs. +It can be adequately addressed by a healthy darknet of private +authenticated peerings between miners and other likely targets. I've +also thrown out some ideas on using merged mined node IDs to make some +kinds of sybil attacks harder ... but it'll be interesting to see how +the deployment of ASICs influences the concentration of hashpower=E2=80=94 = +it +seems like there has already been a substantial move away from the +largest pools. Less hashpower consolidation makes attacks like this +less worrisome. + +> (2) I think the current experience *is* really poor. + +Yes, I said so specifically. But the fact that people are flapping +their lips here instead of testing the bitcoin-qt git master which is +an 1-2 order of magnitude improvement suggests that perhaps I'm wrong +about that. Certainly the dearth of people testing and making bug +reports suggests people don't actually care that much. + +> You seem to +> suggest that the question for these new users is whether they will use +> full-node-or-lite-node, but I believe it will be a decision between +> lite-node-or-nothing-at-all (losing interest altogether). + +No. The "question" that I'm concerned with is do we promote lite nodes +as equally good option=E2=80=94 even for high end systems=E2=80=94 remove t= +he +incentive for people to create, improve, and adopt more useful full +node software and forever degrade the security of the system. + +> Waiting a day +> for the full node to synchronize, and then run into issues like +> blkindex.dat corruption when their system crashes for some unrelated +> reason and they have to resync for another day... they'll be gone in a +> heartbeat. + +The current software patches plus parallelism can sync on a fast +system with luck network access (or a local copy of the data) in under +an hour. + +This is no replacement for start as SPV, but nor are handicapped +client programs a replacement for making fully capable ones acceptably +performing. + +> Users need to experience, as quickly and easily as possible, that they +> can move money across the world, without signing up for anything or +> paying any fees. + +Making the all the software painless for users is a great goal=E2=80=94 and +one I share. I still maintain that it has nothing to do with +promoting less capable and secure software to users. + + |