summaryrefslogtreecommitdiff
path: root/f5/250ce55d6d44cdce84d19608a552d12b654b7b
blob: e35539422d2dcd8eeefa52d50703ac47ad5f9cfd (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
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <luke@dashjr.org>) id 1QmJay-0004oG-1k
	for bitcoin-development@lists.sourceforge.net;
	Thu, 28 Jul 2011 05:57:20 +0000
X-ACL-Warn: 
Received: from zinan.dashjr.org ([173.242.112.54])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1QmJas-0002QP-TG for bitcoin-development@lists.sourceforge.net;
	Thu, 28 Jul 2011 05:57:19 +0000
Received: from ishibashi.localnet (fl-67-77-87-241.dhcp.embarqhsd.net
	[67.77.87.241]) (Authenticated sender: luke-jr)
	by zinan.dashjr.org (Postfix) with ESMTPSA id 4CC0E3AA039;
	Thu, 28 Jul 2011 05:57:07 +0000 (UTC)
From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Thu, 28 Jul 2011 01:56:50 -0400
User-Agent: KMail/1.13.7 (Linux/2.6.39-gentoo; KDE/4.6.4; x86_64; ; )
References: <4E30F2DA.6030403@speakeasy.net>
In-Reply-To: <4E30F2DA.6030403@speakeasy.net>
X-PGP-Key-Fingerprint: CE5A D56A 36CC 69FA E7D2 3558 665F C11D D53E 9583
X-PGP-Key-ID: 665FC11DD53E9583
X-PGP-Keyserver: x-hkp://subkeys.pgp.net
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201107280156.53487.luke@dashjr.org>
X-Spam-Score: -0.7 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain 0.5 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QmJas-0002QP-TG
Subject: Re: [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:57:20 -0000

On Thursday, July 28, 2011 1:25:46 AM Alan Grimes wrote:
> 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 put the page together a while ago with logical segregation of the current 
Bitcoin concept. wxBitcoin originally implemented the entire thing as one big 
blob. Miners got moved out first. Spesmilo took the next step of separating 
out a GUI. Wallet and node are currently tightly tied together in bitcoind, 
though it can function as only one of the two just as well. So in practice, it 
is fully possible to run it like that, but I'm not aware of any de facto use 
yet.

> 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?

Generally, nodes need to make outbound connections too, at least to get 
started.

> 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...)

The miner can really get by with just an address from the wallet--
it needs somewhere to put its generated coins ;)

> 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?

You can run a system-wide bitcoind (or equivalent) to handle p2p connectivity, 
and have each user run a dedicated wallet bitcoind (with the -connect option) 
with a unique JSON-RPC port (for Spesmilo) or wx GUI. I don't think there is 
any automated setup for this kind of arrangement. I personally foresee the p2p 
being implemented on a SOHO router as the end goal (or even better-- 
multicast).