diff options
| author | Patrick Strateman <patrick.strateman@gmail.com> | 2015-06-27 19:13:16 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-28 02:13:19 +0000 |
| commit | 14c456d142f55dadae352e6e7cc901f71cadd21e (patch) | |
| tree | dd7e665693b5f1e95cda63b38ea4dd1c6ea01776 | |
| parent | 5688f420e97c36bfd9ddbce0cf58f57585fdf49a (diff) | |
| download | pi-bitcoindev-14c456d142f55dadae352e6e7cc901f71cadd21e.tar.gz pi-bitcoindev-14c456d142f55dadae352e6e7cc901f71cadd21e.zip | |
Re: [bitcoin-dev] Original Vision
| -rw-r--r-- | 45/8bf325e5a327adfa2d96a95a5d4d04df788dfb | 144 |
1 files changed, 144 insertions, 0 deletions
diff --git a/45/8bf325e5a327adfa2d96a95a5d4d04df788dfb b/45/8bf325e5a327adfa2d96a95a5d4d04df788dfb new file mode 100644 index 000000000..f93e8fd23 --- /dev/null +++ b/45/8bf325e5a327adfa2d96a95a5d4d04df788dfb @@ -0,0 +1,144 @@ +Return-Path: <patrick.strateman@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 69812AAE + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 28 Jun 2015 02:13:19 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com + [209.85.192.182]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3C3CD1A7 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 28 Jun 2015 02:13:18 +0000 (UTC) +Received: by pdbep18 with SMTP id ep18so74485354pdb.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 27 Jun 2015 19:13:18 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=message-id:disposition-notification-to:date:from:user-agent + :mime-version:to:subject:references:in-reply-to:content-type + :content-transfer-encoding; + bh=rzqgFKZ8D0LQKkiqTX5jkuby2dCVDsm6hplAZTgVXF0=; + b=iQ2clmaiXoTPgcRRdcgo3/+KsVm2n7gNPh9sKVlz0quIUY1gh+g+AUPTqvrTlMHu7q + QD5rkTF/RooNk+y7Sf6jpOseesgXJS+LrsL5GTmaFNY+pfCQN5d1wBKBJTcOlkzOKDaN + h6ioMjjFlX42PIfYBSZMn3ODPIj0eTSYY8H/Z9cojiINfI+t5zSkH37Q/BjxPfarE01I + StfgqgAQFN18EJdYykg5fCYZDiW6YhKSvYFae3VM/aiteJCz1rbK3WokGx0eZVIF8slL + +0F4UkjsvzNfxo5GelmJSlgw6FCASlRlD7MTuctReHg9qWRJnxwhr+2g/uKTiSNmn1cm + zPLg== +X-Received: by 10.68.87.5 with SMTP id t5mr17721101pbz.137.1435457597976; + Sat, 27 Jun 2015 19:13:17 -0700 (PDT) +Received: from [10.45.134.9] (c-24-5-81-164.hsd1.ca.comcast.net. [24.5.81.164]) + by mx.google.com with ESMTPSA id + qg5sm37772555pdb.13.2015.06.27.19.13.16 + for <bitcoin-dev@lists.linuxfoundation.org> + (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); + Sat, 27 Jun 2015 19:13:17 -0700 (PDT) +Message-ID: <558F583C.1000500@gmail.com> +Date: Sat, 27 Jun 2015 19:13:16 -0700 +From: Patrick Strateman <patrick.strateman@gmail.com> +User-Agent: Mozilla/5.0 (X11; Linux x86_64; + rv:31.0) Gecko/20100101 Icedove/31.7.0 +MIME-Version: 1.0 +To: bitcoin-dev@lists.linuxfoundation.org +References: <1164261435450448@web14h.yandex.ru> +In-Reply-To: <1164261435450448@web14h.yandex.ru> +Content-Type: text/plain; charset=windows-1252 +Content-Transfer-Encoding: quoted-printable +X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, + RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Subject: Re: [bitcoin-dev] Original Vision +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Sun, 28 Jun 2015 02:13:19 -0000 + +> Further, it appears clear that the original author intended +organizations operating full network nodes would provide connectivity to +light clients and these light clients would make up the majority of the +user base. + +Satoshi also believed that fraud proofs would be widely available and +practical. + +If fraud proofs were practical SPV client security would be much closer +to full node security than it is today. + +Unfortunately no design for fraud proofs which is both efficient and +secure has been proposed; much less implemented and deployed. + +In building a system as new and innovative as bitcoin certain things +will be wrong. + +The perception that SPV clients could be made nearly as secure as full +nodes is one example of something that was wrong. + +On 06/27/2015 05:14 PM, Santino Napolitano wrote: +> There is much heated debate going on right now and I know it can be ver= +y stressful but I'd like to point out that it is really amazing how passi= +onately so many feel about this once very small project. Let's not forget= + there is something really special going on here and we're all part of it= +=2E +> +> The current debate has little to do with block size or hard-forks, IMO.= + It's about the nature of Bitcoin and what it means to people and how it = +will grow. I would like to take a moment to share my interpretation of th= +e original author's intent based on everything I could find and read from= + this person. This is not to say their original vision is paramount-- or = +even that I got it completely correct but I think it might do us some goo= +d to think about. +> +> It seems as though the incentive conceived of for running a full networ= +k node was that it would enable mining. The proceeds from mining (new coi= +ns and transaction fees) would be the reward and provide a reason to cont= +inue operating these nodes. If fees are ever to be a sufficient reward an= +d still allow for a practical and useful system the size of the blocks mu= +st grow significantly as must the user base. I'm not sure that this is re= +ally contested but I haven't exhaustively reviewed everyone's opinion so = +please excuse me if I have marginalized you. If you do contest that I wou= +ld be interested in hearing it. +> +> Further, it appears clear that the original author intended organizatio= +ns operating full network nodes would provide connectivity to light clien= +ts and these light clients would make up the majority of the user base. T= +his is completely consistent with current trends in Internet consumption,= + e.g. tablets and phones are becoming more preferred to even owning a tra= +ditional computer. Having the system be entirely decentralized and trustl= +ess for every client does not appear to me to be the original design goal= +=2E Yes, the whitepaper speaks of the design goal as not having a need fo= +r a trusted third party but it does not say that some amount of trust won= +'t be preferred by a majority of users. In fact, in the SPV section it im= +plies some amount of localized trust is perhaps a necessary trade-off and= + maybe businesses should still run their own full network node if they wa= +nt the stronger completely trustless guarantee. The global decentralized = +consensus appears meant to make the network r +> esilient to a single government or other adversary's ability to shut t= +he network down. If you really want to trust no one it is your option at = +a cost and should be possible by design. The author further gives evidenc= +e that they believe Moore's observation would keep the idea of running a = +full network node a practical one at global scale for perpetuity. It does= + not appear as if they intended for every individual to run one at home n= +or in their pocket. +> +> If my interpretation seems incorrect please do point it out. I hope thi= +s hasn't been too off-topic and distracting. The original author's engine= +ering ingenuity is what gave me any interest in this project so re-visiti= +ng their design and scaling intentions might be helpful for us to move fo= +rward-- together. +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + + + |