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-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jordanmack1981@gmail.com>) id 1Rc5XI-0005tO-VS
for bitcoin-development@lists.sourceforge.net;
Sun, 18 Dec 2011 01:27:32 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.210.175 as permitted sender)
client-ip=209.85.210.175; envelope-from=jordanmack1981@gmail.com;
helo=mail-iy0-f175.google.com;
Received: from mail-iy0-f175.google.com ([209.85.210.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Rc5XI-0001n4-7N
for bitcoin-development@lists.sourceforge.net;
Sun, 18 Dec 2011 01:27:32 +0000
Received: by iakh37 with SMTP id h37so3846470iak.34
for <bitcoin-development@lists.sourceforge.net>;
Sat, 17 Dec 2011 17:27:27 -0800 (PST)
Received: by 10.50.156.133 with SMTP id we5mr17908751igb.74.1324171646941;
Sat, 17 Dec 2011 17:27:26 -0800 (PST)
Received: from [192.168.0.50] (c-67-188-239-72.hsd1.ca.comcast.net.
[67.188.239.72])
by mx.google.com with ESMTPS id j3sm50493152ibj.1.2011.12.17.17.27.25
(version=SSLv3 cipher=OTHER); Sat, 17 Dec 2011 17:27:26 -0800 (PST)
Sender: Jordan Mack <jordanmack1981@gmail.com>
Message-ID: <4EED416E.3010902@parhelic.com>
Date: Sat, 17 Dec 2011 17:27:10 -0800
From: Jordan Mack <jordanmack@parhelic.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CABr1YTebhitO4g-SarZ7H=aoG9a8zW1wd0rfR32o8i0vODbLJw@mail.gmail.com><82659F61-0449-47BB-88DC-497E0D02F8A1@ceptacle.com><CALxbBHUXEJLRDZ=RS1vuvkm7rDjFUPir0sU__f6TJXiTTQxWzA@mail.gmail.com><CABsx9T0puk3CWH1cfNHMSVEoCPaLJJWNJ+H5ObCERZrzMbrTyA@mail.gmail.com>
<CABsx9T06-GA5+KNdr_XzP_M4Av8nEsnMXL29tk078wooZg=RZw@mail.gmail.com>
<1324158558.26106.140661012932641@webmail.messagingengine.com>
In-Reply-To: <1324158558.26106.140661012932641@webmail.messagingengine.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.4 (-)
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
(jordanmack1981[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (jordanmack1981[at]gmail.com)
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
-0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Rc5XI-0001n4-7N
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: Sun, 18 Dec 2011 01:27:33 -0000
theymos' full node and lite node write up got me thinking.
There are two problems here that we are trying to solve:
- The scalability of broadcast messages.
- The resources required to sync and verify the block chain.
I see three distinct groups of clients:
- Miners (dedicated servers & desktops)
- Full (desktops)
- Lite (mobile devices)
To address scalability of broadcasting, there could be three separate
modes of operation (or client types). Mining nodes would retain the
complete block chain, and share all messages between other mining nodes.
Full nodes would retain the complete block chain, receive new block
information from mining nodes, and share block data between each other.
Lite clients would not contain the block chain, or any broadcast
messages, and would query against a full client for all actions.
Mining nodes would handle the brunt of the barrage of messages. All
block and transaction messages would have to be broadcast across all
mining nodes. This would be essentially the same as all clients
currently operate today.
A full client would be one step down from a mining client. They only
need new block data, and new transactions that pertain to them (for
instant notification). All other broadcast data is irrelevant to them.
They would get new block data from connections to mining nodes, or from
other peer nodes. The transaction submission could be sent directly to a
connected mining node, or bounced through other connected full nodes,
with a random number hops. This would disassociate the IP from the
transaction, similarly to Tor.
To address the need for instant transaction notification, without
broadcasting to to everyone, notification messages would be sent
directly from one full client to the other. This is where aliases come
in. When an alias is resolved, it includes both a Bitcoin address, and a
list of IPs to notify of the transaction. This reveals the IP of the
sender and receiver to each other. If the sender or receiver wishes to
remain anonymous, then they could opt out of notification, and wait for
the transaction to appear in the block chain.
A lite client would connect to a "trusted" full client over an encrypted
connection. This would essentially function as a remote control to a
full client, and allow a user to send, receive, and confirm normally,
but without the overhead. A full client could reside on the home
computer or server, which is owned by the user. A hosted wallet could
also be used just as easily.
I don't like the idea of a header only client, unless this is just an
interim action until the full block chain is downloaded in the
background. Development of these types of clients is probably
inevitable, but I believe that this breaks the most fundamental aspects
of Bitcoin's security model. If a client has only headers, it cannot do
full verification, and it is trusting the data from random anonymous peers.
|
