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 <odinn.cyberguerrilla@riseup.net>) id 1WFfro-00045i-76
	for bitcoin-development@lists.sourceforge.net;
	Tue, 18 Feb 2014 08:17:24 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of riseup.net
	designates 198.252.153.129 as permitted sender)
	client-ip=198.252.153.129;
	envelope-from=odinn.cyberguerrilla@riseup.net;
	helo=mx1.riseup.net; 
Received: from mx1.riseup.net ([198.252.153.129])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1WFfrm-0001m7-39
	for bitcoin-development@lists.sourceforge.net;
	Tue, 18 Feb 2014 08:17:24 +0000
Received: from fruiteater.riseup.net (fruiteater-pn.riseup.net [10.0.1.74])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "*.riseup.net",
	Issuer "Gandi Standard SSL CA" (not verified))
	by mx1.riseup.net (Postfix) with ESMTPS id EECA051375;
	Tue, 18 Feb 2014 00:17:15 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	(Authenticated sender: odinn.cyberguerrilla@fruiteater.riseup.net)
	with ESMTPSA id 91111ED0
Received: from localhost (127.0.0.1)
	(SquirrelMail authenticated user odinn.cyberguerrilla)
	by fruiteater.riseup.net with HTTP; Tue, 18 Feb 2014 00:17:15 -0800
Message-ID: <85767ed60882da6fe3675cba9733777e.squirrel@fruiteater.riseup.net>
In-Reply-To: <CAPc1t_-GS7DjvdqwPMg6cC68buSqO_rN5spfmkacw7gPxMqUeg@mail.gmail.com>
References: <CAPc1t_-GS7DjvdqwPMg6cC68buSqO_rN5spfmkacw7gPxMqUeg@mail.gmail.com>
Date: Tue, 18 Feb 2014 00:17:15 -0800
From: "Odinn Cyberguerrilla" <odinn.cyberguerrilla@riseup.net>
To: "Denis Andrejew" <da.colonel@gmail.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.97.8 at mx1
X-Virus-Status: Clean
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.1 (--)
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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [198.252.153.129 listed in list.dnswl.org]
	-0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
	0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay
	lines
X-Headers-End: 1WFfrm-0001m7-39
Cc: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [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 08:17:24 -0000

> Hey everybody,
>
> here's another question that I have:
>
> I'd like a small bit of clarification about the gettx / getrawtransacti=
on
> (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 exactl=
y 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 some=
how
> make the data structure more extensible for potential future use? But t=
hen
> I can't think of any use cases where it appears to make any sense to pu=
t
> more than 1 address there...

This might be such a use case, just maybe --> https://coinb.in/multisig
Also I recommend checking out http://abis.io
These may be things you are thinking about in the context of this.

> 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 spendi=
ng
> those coins... ?
>
> Once again I'm coming to these questions from a project where I'm tryin=
g
> 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)
> -----------------------------------------------------------------------=
-------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=3D121054471&iu=3D/4140/os=
tg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>