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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <theymos@mm.st>) id 1Rc28D-0008Lb-9O
for bitcoin-development@lists.sourceforge.net;
Sat, 17 Dec 2011 21:49:25 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of mm.st
designates 66.111.4.28 as permitted sender)
client-ip=66.111.4.28; envelope-from=theymos@mm.st;
helo=out4.smtp.messagingengine.com;
Received: from out4.smtp.messagingengine.com ([66.111.4.28])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Rc28C-0007sO-BP
for bitcoin-development@lists.sourceforge.net;
Sat, 17 Dec 2011 21:49:25 +0000
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45])
by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id CB04921473
for <bitcoin-development@lists.sourceforge.net>;
Sat, 17 Dec 2011 16:49:18 -0500 (EST)
Received: from web3.nyi.mail.srv.osa ([10.202.2.213])
by compute5.internal (MEProxy); Sat, 17 Dec 2011 16:49:18 -0500
Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99)
id A4BAD40077; Sat, 17 Dec 2011 16:49:18 -0500 (EST)
Message-Id: <1324158558.26106.140661012932641@webmail.messagingengine.com>
X-Sasl-Enc: vfGNmMJC7G0LBNkDYuUPfhtxszxrjsHp1L4m3+SUDBDR 1324158558
From: "theymos" <theymos@mm.st>
To: bitcoin-development@lists.sourceforge.net
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
X-Mailer: MessagingEngine.com Webmail Interface
In-Reply-To: <CABsx9T06-GA5+KNdr_XzP_M4Av8nEsnMXL29tk078wooZg=RZw@mail.gmail.com>
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>
Date: Sat, 17 Dec 2011 15:49:18 -0600
X-Spam-Score: -1.6 (-)
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
(theymos[at]mm.st)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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
X-Headers-End: 1Rc28C-0007sO-BP
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: Sat, 17 Dec 2011 21:49:25 -0000
On Sat, Dec 17, 2011, at 02:06 PM, Gavin Andresen wrote:
> Although I do also wonder if we'll ever run into a problem with full
> nodes refusing to answer requests from lightweight nodes (there might
> be a tragedy-of-the-commons problem lurking there).
This seems likely. Also, even if many full nodes are willing to donate
resources, there may simply be too few full nodes to handle the load.
My preferred solution for handling scalability in the future is to
have lightweight clients download only headers and Merkle trees (which
are both small and easy to distribute), and then require senders to
contact recipients directly in order to transmit their transactions.
Then lightweight clients never need full blocks to build their
balances, and full nodes don't have to handle expensive queries from
lightweight clients.
Under this scheme, the current broadcast system could be used among full
nodes for a long time. Since clients wouldn't ever need to talk to full
nodes, they could form a separate network with less reliable
broadcasting and perhaps a fancier network architecture. Members of the
full network would connect to the most reliable members of the client
network in order to broadcast headers and Merkle trees and receive
transactions. Full nodes would *not* answer any client queries, so
dealing with the client network would not require many resources, and
miners would probably have an incentive to do it. (Creating a "separate"
network like this can be done by using the services field.)
I don't think requiring senders to email some data to the recipient
would be too burdensome, though it's probably also possible to design a
system where even offline recipients can receive transactions through
the Bitcoin network.
|
