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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <sipa@ulyssis.org>) id 1RIIPt-0003Th-Kt
for bitcoin-development@lists.sourceforge.net;
Mon, 24 Oct 2011 11:10:05 +0000
X-ACL-Warn:
Received: from rhcavuit02.kulnet.kuleuven.be ([134.58.240.130]
helo=cavuit02.kulnet.kuleuven.be)
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1RIIPr-0003gQ-C7 for bitcoin-development@lists.sourceforge.net;
Mon, 24 Oct 2011 11:10:05 +0000
X-KULeuven-Envelope-From: sipa@ulyssis.org
X-Spam-Status: not spam, SpamAssassin (not cached, score=-48.798, required 5,
autolearn=disabled, DKIM_ADSP_CUSTOM_MED 0.00,
FREEMAIL_FROM 0.00, KUL_SMTPS -50.00, NML_ADSP_CUSTOM_MED 1.20)
X-KULeuven-Scanned: Found to be clean
X-KULeuven-ID: C3F64128029.A75B2
X-KULeuven-Information: Katholieke Universiteit Leuven
Received: from smtps02.kuleuven.be (smtpshost02.kulnet.kuleuven.be
[134.58.240.75])
by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id C3F64128029;
Mon, 24 Oct 2011 13:09:56 +0200 (CEST)
Received: from smtp.ulyssis.org (mail.ulyssis.student.kuleuven.be
[193.190.253.235])
by smtps02.kuleuven.be (Postfix) with ESMTP id 9722FF3863;
Mon, 24 Oct 2011 13:09:56 +0200 (CEST)
Received: from wop.ulyssis.org (wop.intern.ulyssis.org [192.168.0.182])
by smtp.ulyssis.org (Postfix) with ESMTP id B10E81001C;
Mon, 24 Oct 2011 13:09:56 +0200 (CEST)
Received: by wop.ulyssis.org (Postfix, from userid 615)
id A776E87C1AB; Mon, 24 Oct 2011 13:09:56 +0200 (CEST)
Date: Mon, 24 Oct 2011 13:09:56 +0200
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Jan Vornberger <jan@uos.de>
Message-ID: <20111024110955.GC8115@ulyssis.org>
References: <44861.134.106.52.172.1319444997.squirrel@webmail.uni-osnabrueck.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <44861.134.106.52.172.1319444997.squirrel@webmail.uni-osnabrueck.de>
X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is
CUSTOM_MED 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit,
and not from a mailing list
X-Headers-End: 1RIIPr-0003gQ-C7
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Determine input addresses of a transaction
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: Mon, 24 Oct 2011 11:10:05 -0000
On Mon, Oct 24, 2011 at 10:29:57AM +0200, Jan Vornberger wrote:
> Hi there!
>
> As part of my green address endeavor, I'm currently trying to extend the
> 'gettransaction' call to include an extra field "inputaddresses" which
> should return a list of the Bitcoin addresses associated with the inputs
> of the transaction.
Bitcoin transactions do not have input addresses - they optionally have addresses
the input coins were last sent to. I understand that being able to have a
'from' address on a transaction is useful in certain cases, but it encourages
using such 'from' addresses to identify transactions - which is imho the wrong
way to go.
As far as your green transactions idea is concerned, maybe we could provide an interface
to mark certain addresses as 'trusted', and have an RPC call to request all incoming
transaction that originate from trusted sources?
--
Pieter
|
