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
|
Return-Path: <santino.napolitano@yandex.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DB332BB3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 22:01:02 +0000 (UTC)
X-Greylist: delayed 00:07:33 by SQLgrey-1.7.6
Received: from forward13.mail.yandex.net (forward13.mail.yandex.net
[95.108.130.120])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C4EB0155
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 22:01:01 +0000 (UTC)
Received: from web11j.yandex.ru (web11j.yandex.ru [IPv6:2a02:6b8:0:1619::311])
by forward13.mail.yandex.net (Yandex) with ESMTP id DC8771403E3;
Mon, 29 Jun 2015 00:53:24 +0300 (MSK)
Received: from 127.0.0.1 (localhost [127.0.0.1])
by web11j.yandex.ru (Yandex) with ESMTP id 5A7C714A1F3A;
Mon, 29 Jun 2015 00:53:24 +0300 (MSK)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail;
t=1435528404; bh=VE43UEK2gRc9G6qjopwmNEvlMbo7SBOyZmJcE0jDnWA=;
h=From:To:In-Reply-To:References:Subject:Date;
b=ZXF62ixlKZ4kPUbVuNpjaVefyOdHEZAVHNIv+DyP5xmrdnVajvoENsea3qTOAHdJV
je/9w6m6LlbHd2xo/hO0VEP3uIQulxG424UG+h53rnkG+CYH1DeXWTTwNBoiMdlPxm
7jnpFLUIO0upISrNyx6+lpdXiNCOGd27m+2n23sk=
Received: by web11j.yandex.ru with HTTP;
Mon, 29 Jun 2015 00:53:23 +0300
From: Santino Napolitano <santino.napolitano@yandex.com>
Envelope-From: santino-napolitano@yandex.com
To: Patrick Strateman <patrick.strateman@gmail.com>,
"bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <558F583C.1000500@gmail.com>
References: <1164261435450448@web14h.yandex.ru> <558F583C.1000500@gmail.com>
MIME-Version: 1.0
Message-Id: <1086391435528403@web11j.yandex.ru>
X-Mailer: Yamail [ http://yandex.ru ] 5.0
Date: Mon, 29 Jun 2015 00:53:23 +0300
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=koi8-r
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 22:01:02 -0000
Is the security concern that a newly announced block may not actually reflect a valid block (but valid enough to trick the client; i.e. it appears to link to the best-work chain) in an attempt to defraud the light client?
Like I pointed out, I'm not sure the goal was _perfect_ decentralization. The author seemed primarily keen to avoid having a single organization with direct control over the ledger. I think your specific fear could be mitigated by the light client peering with a node the light client somewhat trusts -- or at least one which has no incentive to cooperate in some attack against it which requires non-trivial mining expenditure. The IP would be logged and the fraud could be taken to a court if the light client chooses a node in the proper jurisdiction. I think for many use cases that might be sufficient. If it's a more serious transaction other nodes could be consulted.
If my reasoning is in error please correct. I'm sure many of you are much better at game theory than I.
28.06.2015, 05:13, "Patrick Strateman" <patrick.strateman@gmail.com>:
>> š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 very stressful but I'd like to point out that it is really amazing how passionately 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.
>>
>> š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 the 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 good to think about.
>>
>> šIt seems as though the incentive conceived of for running a full network node was that it would enable mining. The proceeds from mining (new coins and transaction fees) would be the reward and provide a reason to continue operating these nodes. If fees are ever to be a sufficient reward and still allow for a practical and useful system the size of the blocks must grow significantly as must the user base. I'm not sure that this is really 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 would be interested in hearing it.
>>
>> š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. This is completely consistent with current trends in Internet consumption, e.g. tablets and phones are becoming more preferred to even owning a traditional computer. Having the system be entirely decentralized and trustless for every client does not appear to me to be the original design goal. Yes, the whitepaper speaks of the design goal as not having a need for 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 implies some amount of localized trust is perhaps a necessary trade-off and maybe businesses should still run their own full network node if they want the stronger completely trustless guarantee. The global decentralized consensus appears meant to make the netwo
rk
>
> ššr
>> ššesilient to a single government or other adversary's ability to shut the 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 evidence 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 nor in their pocket.
>>
>> šIf my interpretation seems incorrect please do point it out. I hope this hasn't been too off-topic and distracting. The original author's engineering ingenuity is what gave me any interest in this project so re-visiting their design and scaling intentions might be helpful for us to move forward-- together.
>>
>> š_______________________________________________
>> šbitcoin-dev mailing list
>> šbitcoin-dev@lists.linuxfoundation.org
>> šhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
