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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <elombrozo@gmail.com>) id 1SAjrM-0000oB-5g
for bitcoin-development@lists.sourceforge.net;
Thu, 22 Mar 2012 15:23:28 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.175 as permitted sender)
client-ip=209.85.214.175; envelope-from=elombrozo@gmail.com;
helo=mail-ob0-f175.google.com;
Received: from mail-ob0-f175.google.com ([209.85.214.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SAjrG-0007r2-OZ
for bitcoin-development@lists.sourceforge.net;
Thu, 22 Mar 2012 15:23:28 +0000
Received: by obqv19 with SMTP id v19so2114070obq.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 22 Mar 2012 08:23:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.41.5 with SMTP id b5mr10176848obl.79.1332429797251; Thu,
22 Mar 2012 08:23:17 -0700 (PDT)
Received: by 10.60.55.68 with HTTP; Thu, 22 Mar 2012 08:23:17 -0700 (PDT)
In-Reply-To: <201203221000.41636.luke@dashjr.org>
References: <CABr1YTc0TOvfyFNY4CTaOiTa3WWb-5JHjQOTarB=8zZ+DqiUFg@mail.gmail.com>
<201203221000.41636.luke@dashjr.org>
Date: Thu, 22 Mar 2012 08:23:17 -0700
Message-ID: <CABr1YTd4+KES75cHqKSa0Gwz62nJnMVsTANVh_qzuSXqoYZAew@mail.gmail.com>
From: Eric Lombrozo <elombrozo@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=ISO-8859-1
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
(elombrozo[at]gmail.com)
-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: 1SAjrG-0007r2-OZ
Subject: Re: [Bitcoin-development] Adding callback hooks to the satoshi
client
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, 22 Mar 2012 15:23:28 -0000
The callback architecture could be such that other code would never
need to enter into the wallet-handling process/memory space. For
instance, client applications could subscribe a particular URL to get
sent an HTTP POST.
For the apps I've been working on, there really isn't any need to
access the wallet space. I was talking more about events like "A new
transaction was just seen" or "A new block was just seen", like what
libcoin seems to support (sorry, Michael, I haven't really had a
chance to look at it in depth but I will). Then there are other types
of events for other bitcoin messages could also be useful: new addr,
new node connected, node disconnected, bitcoin alert, etc...
Then there are events for dealing with potential attacks: DoS attempt,
double-spend attempts (two transactions seen with valid signatures
claiming the same output), node sending malformed messages, etc...
And then there are alerts pertaining to the status of the bitcoind
process itself: bitcoind started, bitcoind ready to accept
connections, bitcoind stopping, etc...
None of these events require the callback subscriber to have any
access to the bitcoind process/memory space and all the I/O could be
done via IPC or over network sockets.
|
