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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <elombrozo@gmail.com>) id 1SBMXT-0005ZG-Mb
for bitcoin-development@lists.sourceforge.net;
Sat, 24 Mar 2012 08:41:31 +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 1SBMXT-0002zM-4b
for bitcoin-development@lists.sourceforge.net;
Sat, 24 Mar 2012 08:41:31 +0000
Received: by obqv19 with SMTP id v19so4220673obq.34
for <bitcoin-development@lists.sourceforge.net>;
Sat, 24 Mar 2012 01:41:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.54.114 with SMTP id i18mr18086092obp.49.1332578485532;
Sat, 24 Mar 2012 01:41:25 -0700 (PDT)
Received: by 10.60.55.68 with HTTP; Sat, 24 Mar 2012 01:41:25 -0700 (PDT)
In-Reply-To: <CABr1YTd4+KES75cHqKSa0Gwz62nJnMVsTANVh_qzuSXqoYZAew@mail.gmail.com>
References: <CABr1YTc0TOvfyFNY4CTaOiTa3WWb-5JHjQOTarB=8zZ+DqiUFg@mail.gmail.com>
<201203221000.41636.luke@dashjr.org>
<CABr1YTd4+KES75cHqKSa0Gwz62nJnMVsTANVh_qzuSXqoYZAew@mail.gmail.com>
Date: Sat, 24 Mar 2012 01:41:25 -0700
Message-ID: <CABr1YTcpoRT3k1Bqjz_m48RrDuGciD4nJmsE1RiGJ4g_2z22Ww@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: 1SBMXT-0002zM-4b
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: Sat, 24 Mar 2012 08:41:31 -0000
I'd also like to be able to get detailed information of message format
errors for debugging other nodes that connect to bitcoind. For
instance, if a transaction is rejected because the signature is
invalid, I want to know this. If it's because the amount is out of
range or because the output couldn't be connected, I want to know
this, too. I especially want to know if it was because the transaction
is claiming an output that has already been claimed by another
transaction.
For now, I've had to resort to sticking tracers and stubs into
bitcoind. It would be really nice to not only be able to write an
error log but to also let the connecting node know what went wrong.
Obviously these types of messages should *not* be part of the bitcoin
protocol itself since it invites all kinds of attacks. But it would be
wonderful to have a side channel for this type of data, and it could
also be done using callbacks.
The callback mechanism could be configurable in a similar fashion to
the RPC in the bitcoin.conf file.
-Eric Lombrozo
|
