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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gronager@ceptacle.com>) id 1RdLUl-0001Cy-NN
for bitcoin-development@lists.sourceforge.net;
Wed, 21 Dec 2011 12:42:07 +0000
X-ACL-Warn:
Received: from backup-server.nordu.net ([193.10.252.66])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1RdLUh-0001kd-2V
for bitcoin-development@lists.sourceforge.net;
Wed, 21 Dec 2011 12:42:07 +0000
Received: from [109.105.106.215] ([109.105.106.215]) (authenticated bits=0)
by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pBLCfq47013690
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
Wed, 21 Dec 2011 13:41:53 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com>
In-Reply-To: <CABr1YTdUQeAuw2vwZS=VvDU1dTrN+eqjHRXMsZp2axcxbTsO8A@mail.gmail.com>
Date: Wed, 21 Dec 2011 13:41:51 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <028C9CB5-A7C9-4042-BC00-269046E2DD19@ceptacle.com>
References: <CABr1YTebhitO4g-SarZ7H=aoG9a8zW1wd0rfR32o8i0vODbLJw@mail.gmail.com>
<82659F61-0449-47BB-88DC-497E0D02F8A1@ceptacle.com>
<CALxbBHUXEJLRDZ=RS1vuvkm7rDjFUPir0sU__f6TJXiTTQxWzA@mail.gmail.com>
<4EEE58CA.5090902@justmoon.de>
<67FAA76C-1734-471D-A3D8-31E5216DD512@ceptacle.com>
<CABr1YTdUQeAuw2vwZS=VvDU1dTrN+eqjHRXMsZp2axcxbTsO8A@mail.gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>
X-Mailer: Apple Mail (2.1251.1)
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1RdLUh-0001kd-2V
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Protocol extensions
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, 21 Dec 2011 12:42:07 -0000
I find it likely that we will at some point have supernodes. If we have =
browser based wallets then the server for these automatically becomes =
supernodes. Further, if we move along that direction, it becomes much =
simpler to use both the scheme I proposed or to use a a lot of other =
schemes for sharing the validation work on a farm constituting the =
supernode.
However, if we want to keep bitcoin in a real p2p setup and enable =
scalability in terms of ensuring both thin and fat client to connect =
then we need to go along the path I propose.
Actually, after thinking a bit more about the possible new attack vector =
I don't find it that alarming - if you still require 7 confirmations of =
any bigger transaction before you, as receiver accepts the transaction =
as payed you will not risk anything. The question is then if it is =
sufficiently easy to fake small transaction to e.g. gain access to =
micropayment based web services. I would again say no - the requirement =
that you have ok from e.g. 8 different A.B nodes will make it extremely =
difficult to cheat, and that would even require you to gain some level =
of control over the network that the service you want to cheat is =
connected through.
This means that you should not divide the hash space more finely than =
you would at all times be able to find 8 different A.B nodes. As the =
number of clients grows you can then divide the hash space further. =
(with 100000 nodes today and a division into 512 parts you would have =
approx 200 nodes to choose from).
Cheers,
M
On 21/12/2011, at 12:42, Eric Lombrozo wrote:
> Is it just me or does it seem inevitable that at some point supernodes
> will emerge that other nodes trust to validate transactions for them?
> Supernodes needn't even store the entire block chain and transaction
> pool...it would be sufficient that they keep lists of IP addresses of
> other trustworthy nodes and partition them into a hashspace.
>=20
> Anonymous peers have no reputation to defend...but a trusted supernode
> would, which could provide just enough incentive for the supernode to
> do its best to ensure the nodes it vouches for are indeed legit. Of
> course, unless the supernode is validating the entire block chain and
> transaction pool itself, it could only assess the trustworthiness of
> other nodes by performing random sampling.
>=20
> Michael, I really like your ideas and the clarity you bring to the
> issue. Regarding the potential attack vector you mention, would it be
> possible to partition the hashspace to minimize the risk that an
> attacker can manage to disproportionately gain control over a part of
> the hashspace?
>=20
> =
--------------------------------------------------------------------------=
----
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. =
Create=20
> new or port existing apps to sell to consumers worldwide. Explore the=20=
> Intel AppUpSM program developer opportunity. =
appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
