diff options
| author | Jim Nguyen <jimmy.winn@gmail.com> | 2012-12-04 21:38:00 -0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2012-12-05 05:38:08 +0000 |
| commit | 8336409b9f7998cc83cd8764445f8a9e0c743de9 (patch) | |
| tree | c8c692d0a21387914b44f10e00c7276648bfd473 /a4/8d549d006b61895889e8d13ead6b9656781187 | |
| parent | 185227467439eb7cdc9b81293e414587b924255f (diff) | |
| download | pi-bitcoindev-8336409b9f7998cc83cd8764445f8a9e0c743de9.tar.gz pi-bitcoindev-8336409b9f7998cc83cd8764445f8a9e0c743de9.zip | |
Re: [Bitcoin-development] Roadmap to getting users onto SPV clients
Diffstat (limited to 'a4/8d549d006b61895889e8d13ead6b9656781187')
| -rw-r--r-- | a4/8d549d006b61895889e8d13ead6b9656781187 | 430 |
1 files changed, 430 insertions, 0 deletions
diff --git a/a4/8d549d006b61895889e8d13ead6b9656781187 b/a4/8d549d006b61895889e8d13ead6b9656781187 new file mode 100644 index 000000000..4f3dbcdb9 --- /dev/null +++ b/a4/8d549d006b61895889e8d13ead6b9656781187 @@ -0,0 +1,430 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <jimmy.winn@gmail.com>) id 1Tg7gO-0003EI-Ce + for bitcoin-development@lists.sourceforge.net; + Wed, 05 Dec 2012 05:38:08 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.219.47 as permitted sender) + client-ip=209.85.219.47; envelope-from=jimmy.winn@gmail.com; + helo=mail-oa0-f47.google.com; +Received: from mail-oa0-f47.google.com ([209.85.219.47]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1Tg7gM-0004y3-7R + for bitcoin-development@lists.sourceforge.net; + Wed, 05 Dec 2012 05:38:08 +0000 +Received: by mail-oa0-f47.google.com with SMTP id h1so5083657oag.34 + for <bitcoin-development@lists.sourceforge.net>; + Tue, 04 Dec 2012 21:38:00 -0800 (PST) +MIME-Version: 1.0 +Received: by 10.60.6.194 with SMTP id d2mr13222332oea.49.1354685880661; Tue, + 04 Dec 2012 21:38:00 -0800 (PST) +Received: by 10.182.89.229 with HTTP; Tue, 4 Dec 2012 21:38:00 -0800 (PST) +In-Reply-To: <CAAS2fgRfUMYwOE51+eY5QE8nDNV==G1OBRzM1AuHjYmYwTFiow@mail.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> + <CAAS2fgRfUMYwOE51+eY5QE8nDNV==G1OBRzM1AuHjYmYwTFiow@mail.gmail.com> +Date: Tue, 4 Dec 2012 21:38:00 -0800 +Message-ID: <CAGjxm7vFkunziwECv1Twq4M9eC0nbgcqdCK6t6i7R84R_kPUTA@mail.gmail.com> +From: Jim Nguyen <jimmy.winn@gmail.com> +To: Gregory Maxwell <gmaxwell@gmail.com> +Content-Type: multipart/alternative; boundary=e89a8fb204f4b2f6d504d01462aa +X-Spam-Score: -0.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 + (jimmy.winn[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + -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: 1Tg7gM-0004y3-7R +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 05:38:08 -0000 + +--e89a8fb204f4b2f6d504d01462aa +Content-Type: text/plain; charset=windows-1252 +Content-Transfer-Encoding: quoted-printable + +Gavin's grandma needs to be able to use bitcoin. Here is a real world +sampling of the types of people wanting to use bitcoin but are having some +difficulty which I have collected from Facebook. Should we listen to the +end user? :-P + +*"what is the intention of Bitcoin? Is it supposed to be - eventually - for +dummies like myself or is it just for those individuals who are code and +algorithm writers? I downloaded a wallet but how do I know if I need more +software or a massive computer system to solve "the problem" for the next +block? With all the talk of mathematical problem solving on a world wide +network of computers I can't see a small laptop figuring out anything thus +not gaining any bitcoins. Why should I be interested in this if it appears +it's just for computer scientists?"* + +*"hi, instaled bitcoin qt, but after it dowladed all the stuff, now i get +DEP protecction from windows, and it tells me bitcoinQT need to run with +DEP on, dont let me make an exception for it, nor work it i turn DEP only +for sys, so hwat i should do?"* + +*"hi, i'm new to bitcoin, i got a bunch of free bitcoins from a bunch of +the free sites. how come when i tried to send my bitcoins to myself, it +says the fee exceeds the balance? I thought there was no fees?"* + +*"Is there a way to speed up the process of synchronisation with the +network? It has been taken ages on my MAC.* +*Any help would be nice"* +* +* +*and more...* + +Sorry if this doesn't belong to the bitcoin-development email list. I just +see this as end-user/customer data gathering to refine the requirements, +since this is software engineering...isn't it? + +Jim + +On Tue, Dec 4, 2012 at 6:54 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote: + +> 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=97 a moderately fast multicore desktop machine can keep up with +> the maximum possible validation rate of the Bitcoin network and the +> bandwidth has a long term maximum rate of about 14kbit/sec=97 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=97 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=97 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=97 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 o= +f +> > 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 curren= +t +> > 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=97 allowing their captured miners to build an ill fated +> fork=97 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=97 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=97 even for high end systems=97 remove the +> 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=97 and +> one I share. I still maintain that it has nothing to do with +> promoting less capable and secure software to users. +> +> +> -------------------------------------------------------------------------= +----- +> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial +> Remotely access PCs and mobile devices and provide instant support +> Improve your efficiency, and focus on delivering more value-add services +> Discover what IT Professionals Know. Rescue delivers +> http://p.sf.net/sfu/logmein_12329d2d +> _______________________________________________ +> Bitcoin-development mailing list +> Bitcoin-development@lists.sourceforge.net +> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +> + +--e89a8fb204f4b2f6d504d01462aa +Content-Type: text/html; charset=windows-1252 +Content-Transfer-Encoding: quoted-printable + +Gavin's grandma needs to be able to use bitcoin. =A0Here is a real worl= +d sampling of the types of people wanting to use bitcoin but are having som= +e difficulty which I have collected from Facebook. =A0Should we listen to t= +he end user? :-P<div> +<div><br></div><div><i>"what is the intention of Bitcoin? Is it suppos= +ed to be - eventually - for dummies like myself or is it just for those ind= +ividuals who are code and algorithm writers? I downloaded a wallet but how = +do I know if I need more software or a massive computer system to solve &qu= +ot;the problem" for the next block? With all the talk of mathematical = +problem solving on a world wide network of computers I can't see a smal= +l laptop figuring out anything thus not gaining any bitcoins. Why should I = +be interested in this if it appears it's just for computer scientists?&= +quot;</i></div> +<div><br></div><div><i>"hi, instaled bitcoin qt, but after it dowladed= + all the stuff, now i get DEP protecction from windows, and it tells me bit= +coinQT need to run with DEP on, dont let me make an exception for it, nor w= +ork it i turn DEP only for sys, so hwat i should do?"</i><br> +</div><div><br></div><div><i>"hi, i'm new to bitcoin, i got a bunc= +h of free bitcoins from a bunch of the free sites. how come when i tried to= + send my bitcoins to myself, it says the fee exceeds the balance? I thought= + there was no fees?"</i></div> +<div><br></div><div><i>"Is there a way to speed up the process of sync= +hronisation with the network? It has been taken ages on my MAC.</i></div><d= +iv><i>Any help would be nice"</i></div><div><i><br></i></div><div> +<i>and more...</i></div><div><br></div><div>Sorry if this doesn't belon= +g to the bitcoin-development email list. =A0I just see this as end-user/cus= +tomer data gathering to refine the requirements, since this is software eng= +ineering...isn't it?</div> +</div><div><br></div><div>Jim</div><div><br><div class=3D"gmail_quote">On T= +ue, Dec 4, 2012 at 6:54 PM, Gregory Maxwell <span dir=3D"ltr"><<a href= +=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>>= +</span> wrote:<br> +<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= +x #ccc solid;padding-left:1ex"><div class=3D"im">On Tue, Dec 4, 2012 at 9:0= +8 PM, Alan Reiner <<a href=3D"mailto:etotheipi@gmail.com">etotheipi@gmai= +l.com</a>> wrote:<br> + +> Our divergence is on two points (personal opinions):<br> +><br> +> (1) I don't think there is any real risk to the centralization of = +the<br> +> network by promoting a SPV (purely-consuming) node to brand-new users.= +<br> +> In my opinion (but I'm not as familiar with the networking as you)= +, as<br> +> long as all full nodes are full-validation, the bottleneck will be<br> +> computation and bandwidth, long before a constant 10k nodes would be<b= +r> +> insufficient to support propagating data through the network.<br> +<br> +</div>Not so=97 a moderately fast multicore desktop machine can keep up wit= +h<br> +the maximum possible validation rate of the Bitcoin network and the<br> +bandwidth has a long term maximum rate of about 14kbit/sec=97 though<br> +you'll want at least ten times that for convergence stability and the<b= +r> +ability feed multiple peers.<br> +<br> +Here are the worst blocks testnet3 (which has some intentionally<br> +constructed maximum sized blocks),E31230 :<br> +(with the new parallel validation code)<br> +- Verify 2166 txins: 250.29ms (0.116ms/txin)<br> +- Verify 3386 txins: 1454.25ms (0.429ms/txin)<br> +- Verify 5801 txins: 575.46ms (0.099ms/txin)<br> +- Verify 6314 txins: 625.05ms (0.099ms/txin)<br> +Even the slowest one _validates_ at 400x realtime. (these measurements<br> +are probably a bit noisy=97 but the point is that its fast).<br> +(the connecting is fast too, but thats obvious with such a small database)<= +br> +<br> +Although I haven't tested leveldb+ultraprune with a really enormous<br> +txout set or generally with sustained maximum load=97 so there may be<br> +other gaffs in the software that get exposed with sustained load, but<br> +they'd all be correctable. Sounds like some interesting stuff to test<b= +r> +with on testnet fork that has the POW test disabled.<br> +<br> +While syncing up a behind node can take a while=97 keep in mind that<br> +you're expecting to sync up weeks of network work in hours. Even<br> +'slow' is quite fast.<br> +<div class=3D"im"><br> +> In fact,<br> +> I was under the impression that "connectedness" was the real= + metric of<br> +> concern (and resilience of that connectedness to large percentage of<b= +r> +> users disappearing suddenly). =A0If that's true, above a certain n= +umber of<br> +> nodes, the connectedness isn't really going to get any better (I k= +now<br> +> it's not really that simple, but I feel like it is up to 10x the c= +urrent<br> +> network size).<br> +<br> +</div>Thats not generally concern for me. There are a number of DOS attack<= +br> +risks... But attacker linear DOS attacks aren't generally avoidable<br> +and they don't persist.<br> +<br> +Of the class of connectedness concerns I have is that a sybil attacker<br> +could spin up enormous numbers of nodes and then use them to partition<br> +large miners. =A0So, e.g. find BitTaco's node(s) and the nodes for<br> +miners covering 25% hashpower and get them into a separate partition<br> +from the rest of the network. Then they give double spends to that<br> +partition and use them to purchase an unlimited supply of digitally<br> +delivered tacos=97 allowing their captured miners to build an ill fated<br> +fork=97 and drop the partition once the goods are delivered.<br> +<br> +But there is no amount of full nodes that removes this concern,<br> +especially if you allow for attackers which have compromised ISPs.<br> +It can be adequately addressed by a healthy darknet of private<br> +authenticated peerings between miners and other likely targets. I've<br= +> +also thrown out some ideas on using merged mined node IDs to make some<br> +kinds of sybil attacks harder ... but it'll be interesting to see how<b= +r> +the deployment of ASICs influences the concentration of hashpower=97 it<br> +seems like there has already been a substantial move away from the<br> +largest pools. Less hashpower consolidation makes attacks like this<br> +less worrisome.<br> +<div class=3D"im"><br> +> (2) I think the current experience *is* really poor.<br> +<br> +</div>Yes, I said so specifically. =A0But the fact that people are flapping= +<br> +their lips here instead of testing the bitcoin-qt git master which is<br> +an 1-2 order of magnitude improvement suggests that perhaps I'm wrong<b= +r> +about that. =A0Certainly the dearth of people testing and making bug<br> +reports suggests people don't actually care that much.<br> +<div class=3D"im"><br> +> You seem to<br> +> suggest that the question for these new users is whether they will use= +<br> +> full-node-or-lite-node, but I believe it will be a decision between<br= +> +> lite-node-or-nothing-at-all (losing interest altogether).<br> +<br> +</div>No. The "question" that I'm concerned with is do we pro= +mote lite nodes<br> +as equally good option=97 even for high end systems=97 remove the<br> +incentive for people to create, improve, and adopt more useful full<br> +node software and forever degrade the security of the system.<br> +<div class=3D"im"><br> +> Waiting a day<br> +> for the full node to synchronize, and then run into issues like<br> +> blkindex.dat corruption when their system crashes for some unrelated<b= +r> +> reason and they have to resync for another day... they'll be gone = +in a<br> +> heartbeat.<br> +<br> +</div>The current software patches plus parallelism can sync on a fast<br> +system with luck network access (or a local copy of the data) in under<br> +an hour.<br> +<br> +This is no replacement for start as SPV, but nor are handicapped<br> +client programs a replacement for making fully capable ones acceptably<br> +performing.<br> +<div class=3D"im"><br> +> Users need to experience, as quickly and easily as possible, that they= +<br> +> can move money across the world, without signing up for anything or<br= +> +> paying any fees.<br> +<br> +</div>Making the all the software painless for users is a great goal=97 and= +<br> +one I share. =A0I still maintain that it has nothing to do with<br> +promoting less capable and secure software to users.<br> +<div class=3D"HOEnZb"><div class=3D"h5"><br> +---------------------------------------------------------------------------= +---<br> +LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial<br> +Remotely access PCs and mobile devices and provide instant support<br> +Improve your efficiency, and focus on delivering more value-add services<br= +> +Discover what IT Professionals Know. Rescue delivers<br> +<a href=3D"http://p.sf.net/sfu/logmein_12329d2d" target=3D"_blank">http://p= +.sf.net/sfu/logmein_12329d2d</a><br> +_______________________________________________<br> +Bitcoin-development mailing list<br> +<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo= +pment@lists.sourceforge.net</a><br> +<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= +" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= +velopment</a><br> +</div></div></blockquote></div><br></div> + +--e89a8fb204f4b2f6d504d01462aa-- + + |