From: Alan Grimes <agrimes@speakeasy.net>
To: bitcoin-development@lists.sourceforge.net
Subject: [Bitcoin-development] Bitcoin components.
Date: Thu, 28 Jul 2011 01:25:46 -0400 [thread overview]
Message-ID: <4E30F2DA.6030403@speakeasy.net> (raw)
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.
next reply other threads:[~2011-07-28 5:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-28 5:25 Alan Grimes [this message]
2011-07-28 5:56 ` [Bitcoin-development] Bitcoin components Luke-Jr
2011-07-28 11:21 ` Matt Corallo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E30F2DA.6030403@speakeasy.net \
--to=agrimes@speakeasy.net \
--cc=bitcoin-development@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox