1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
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
|
