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
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <da.colonel@gmail.com>) id 1WFY8V-0003YC-Dj
for bitcoin-development@lists.sourceforge.net;
Tue, 18 Feb 2014 00:02:07 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.169 as permitted sender)
client-ip=209.85.212.169; envelope-from=da.colonel@gmail.com;
helo=mail-wi0-f169.google.com;
Received: from mail-wi0-f169.google.com ([209.85.212.169])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WFY8U-0000Lw-KG
for bitcoin-development@lists.sourceforge.net;
Tue, 18 Feb 2014 00:02:07 +0000
Received: by mail-wi0-f169.google.com with SMTP id e4so2891442wiv.2
for <bitcoin-development@lists.sourceforge.net>;
Mon, 17 Feb 2014 16:02:00 -0800 (PST)
X-Received: by 10.194.62.206 with SMTP id a14mr20286339wjs.26.1392681720560;
Mon, 17 Feb 2014 16:02:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.102.66 with HTTP; Mon, 17 Feb 2014 16:01:40 -0800 (PST)
From: Denis Andrejew <da.colonel@gmail.com>
Date: Tue, 18 Feb 2014 01:01:40 +0100
Message-ID: <CAPc1t_-GS7DjvdqwPMg6cC68buSqO_rN5spfmkacw7gPxMqUeg@mail.gmail.com>
To: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=047d7b66f8e13d43d504f2a2fb1b
X-Spam-Score: -0.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
(da.colonel[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1WFY8U-0000Lw-KG
Subject: [Bitcoin-development] bitcoind json API (gettx/raw) (newbie
questions #2)
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: Tue, 18 Feb 2014 00:02:08 -0000
--047d7b66f8e13d43d504f2a2fb1b
Content-Type: text/plain; charset=ISO-8859-1
Hey everybody,
here's another question that I have:
I'd like a small bit of clarification about the gettx / getrawtransaction
(decoded) api call. I understand that I can find the address that a
transaction output is directed at / available to for future use sits in the
vout array in the scriptPubKey.addresses array. I'm a little uncertain as
to why that piece of information would be typed as an array when all it
ever seems to contain is one (not more, not less) address(es).
Are there any cases of transactions right now that don't contain exactly 1
item in that array, i.e. more or less than a single address (per single
vout element, not per tx)? Or is the thinking behind this array to somehow
make the data structure more extensible for potential future use? But then
I can't think of any use cases where it appears to make any sense to put
more than 1 address there...
Or am I even asking the wrong questions? For spending those coins, i.e.
using them in a future transaction it's all about owning the public/private
key that is contained in the vout script, right? So the address doesn't
really matter and it could be 2 or more (or none at all?) addresses in
there, and what matters is just that the next guy has the key to spending
those coins... ?
Once again I'm coming to these questions from a project where I'm trying to
calculate unspent outputs and from that balances for all accounts and I'm
not sure yet what other special cases there might be in the blockchain that
I need to be aware of and handle properly in order to (re-)produce accurate
data!
Thanks for your help, much appreciated!
- Denis
"Be the change you want to see in the world." (Mahatma Gandhi)
--047d7b66f8e13d43d504f2a2fb1b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hey everybody,<div><br></div><div>here's another quest=
ion that I have:</div><div><br></div><div>I'd like a small bit of clari=
fication about the gettx / getrawtransaction (decoded) api call. I understa=
nd that I can find the address that a transaction output is directed at / a=
vailable to for future use sits in the vout array in the scriptPubKey.addre=
sses array. I'm a little uncertain as to why that piece of information =
would be typed as an array when all it ever seems to contain is one (not mo=
re, not less) address(es).</div>
<div><br></div><div>Are there any cases of transactions right now that don&=
#39;t contain exactly 1 item in that array, i.e. more or less than a single=
address (per single vout element, not per tx)? Or is the thinking behind t=
his array to somehow make the data structure more extensible for potential =
future use? But then I can't think of any use cases where it appears to=
make any sense to put more than 1 address there...</div>
<div><br></div><div>Or am I even asking the wrong questions? For spending t=
hose coins, i.e. using them in a future transaction it's all about owni=
ng the public/private key that is contained in the vout script, right? So t=
he address doesn't really matter and it could be 2 or more (or none at =
all?) addresses in there, and what matters is just that the next guy has th=
e key to spending those coins... ?</div>
<div><br></div><div>Once again I'm coming to these questions from a pro=
ject where I'm trying to calculate unspent outputs and from that balanc=
es for all accounts and I'm not sure yet what other special cases there=
might be in the blockchain that I need to be aware of and handle properly =
in order to (re-)produce accurate data!</div>
<div><br></div><div>Thanks for your help, much appreciated!</div><div>- Den=
is</div><div><br></div><div><div>"Be the change you want to see in the=
world." (Mahatma Gandhi)</div>
</div></div>
--047d7b66f8e13d43d504f2a2fb1b--
|
