public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [Bitcoin-development] Bitcoin components.
@ 2011-07-28  5:25 Alan Grimes
  2011-07-28  5:56 ` Luke-Jr
  2011-07-28 11:21 ` Matt Corallo
  0 siblings, 2 replies; 3+ messages in thread
From: Alan Grimes @ 2011-07-28  5:25 UTC (permalink / raw)
  To: bitcoin-development

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.




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Bitcoin-development] Bitcoin components.
  2011-07-28  5:25 [Bitcoin-development] Bitcoin components Alan Grimes
@ 2011-07-28  5:56 ` Luke-Jr
  2011-07-28 11:21 ` Matt Corallo
  1 sibling, 0 replies; 3+ messages in thread
From: Luke-Jr @ 2011-07-28  5:56 UTC (permalink / raw)
  To: bitcoin-development

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



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Bitcoin-development] Bitcoin components.
  2011-07-28  5:25 [Bitcoin-development] Bitcoin components Alan Grimes
  2011-07-28  5:56 ` Luke-Jr
@ 2011-07-28 11:21 ` Matt Corallo
  1 sibling, 0 replies; 3+ messages in thread
From: Matt Corallo @ 2011-07-28 11:21 UTC (permalink / raw)
  To: bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

On Thu, 2011-07-28 at 01:25 -0400, Alan Grimes wrote:
> 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.
Yay, yet another person who wants to write their own client from scratch
who will get the net code done, work a bit on wallet code and move on to
something more exciting.  Seriously, at this point it seems everyone and
their mother are writing their own, or planning to write their own,
client.
Bitcoin's code actually can be fairly well segmented into the necessary
pieces (CWallet was the first big chunk, more are coming) and comments
are being added as a part of that effort.
The current code is much, much more trustworthy than anything someone
new will start to code, even if they have 20 lines of comments for each
line of code.  If you want to help the project, please dont write yet
another new client library, just look for an existing one you can help
with, or help with the original client.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2011-07-28 11:21 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-28  5:25 [Bitcoin-development] Bitcoin components Alan Grimes
2011-07-28  5:56 ` Luke-Jr
2011-07-28 11:21 ` Matt Corallo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox