summaryrefslogtreecommitdiff
path: root/3c/b0a7479c771d4e59c423821593bcd31a5ae75e
blob: e802316c05b1b50b147eb804ff6aaae333efb88a (plain)
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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <agrimes@speakeasy.net>) id 1QmJ6y-0001Bz-Io
	for bitcoin-development@lists.sourceforge.net;
	Thu, 28 Jul 2011 05:26:20 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of speakeasy.net
	designates 69.17.117.50 as permitted sender)
	client-ip=69.17.117.50; envelope-from=agrimes@speakeasy.net;
	helo=mail6.sea5.speakeasy.net; 
Received: from mail6.sea5.speakeasy.net ([69.17.117.50])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1QmJ6v-0001hk-0P
	for bitcoin-development@lists.sourceforge.net;
	Thu, 28 Jul 2011 05:26:20 +0000
Received: (qmail 28542 invoked from network); 28 Jul 2011 05:26:10 -0000
Received: from dsl092-168-049.wdc2.dsl.speakeasy.net (HELO [10.0.0.4])
	([66.92.168.49]) (envelope-sender <agrimes@speakeasy.net>)
	by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted
	SMTP for <bitcoin-development@lists.sourceforge.net>;
	28 Jul 2011 05:26:10 -0000
Message-ID: <4E30F2DA.6030403@speakeasy.net>
Date: Thu, 28 Jul 2011 01:25:46 -0400
From: Alan Grimes <agrimes@speakeasy.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:5.0) Gecko/20110711 Firefox/5.0 SeaMonkey/2.2
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.1 (--)
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 SPF_PASS               SPF: sender matches SPF record
	-1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain 0.6 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QmJ6v-0001hk-0P
Subject: [Bitcoin-development] Bitcoin components.
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: Thu, 28 Jul 2011 05:26:20 -0000

Lets look at:

https://en.bitcoin.it/wiki/Infrastructure

This is OK as a super high-level overview, but it leaves a great deal to 
be explained.

First what is the status of this? Is it fully implemented? A working 
proposal? An approved proposal? etc...

I am working on the peer and the wallet boxes in this diagram. I want to 
implement my own version because the existing code is completely 
untrustworthy, it is totally slap-dash and almost completely uncommented.

My questions related to the peer are these:

It is taken for granted that the peer will have a listening component 
that accepts connections from other peers.

Does it also have an active component? If so, what operations does it 
perform autonomously?

/me looks at wallet.h and GAH!! Someone reversed the concept of debit 
and credit! =( (GetDebit(), GetCredit())

Interesting... What is the exact relationship between the wallet and the 
miner? (The miner is irrelevant to me until I have a wallet I can trust 
enough to experiment with...)

After reading the dox on libdb, I'm leaning towards an inetd 
implementation. That is, inetd handles all the dirty work with regards 
to connections, and spawns off a server for each client. This minimizes 
the quantity of code at the cost of a wee bit of overhead (maybe 10k per 
process). Basically, the penguin acts like the KoAC in Katamari Damacy, 
if you don't do it in the regal old-fashioned way, he rains down 
thunderbolts on you and you get to write 3 or 4 times as much code.

The upside is that each peer is served by a single completely isolated 
process with extremely simple and highly auditable code.

A general problem that I haven't seen any documentation on yet is that 
most of today's operating systems are properly multi-user systems. 
Naturally, each user would keep his wallet in an encrypted store in his 
home directory. Are there any standards yet for users to set up their 
personal wallet daemon that connects to a system-wide peer node and 
provides an interface for only their own GUI?

-- 
E T F
N H E
D E D

Powers are not rights.