public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gavin Andresen <gavinandresen@gmail.com>
To: Jan Vornberger <jan@uos.de>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Determine input addresses of a transaction
Date: Mon, 24 Oct 2011 10:55:14 -0400	[thread overview]
Message-ID: <CABsx9T2v4uhUdsWEg58Xs2OhOf3ED0Q2LGmkrRpdJDxvVMexdQ@mail.gmail.com> (raw)
In-Reply-To: <44861.134.106.52.172.1319444997.squirrel@webmail.uni-osnabrueck.de>

> So my first shot at this is to go through the inputs of a transaction and
> see if the scriptSig field has only two opcodes. If that is the case, I
> assume that it is of the structure <sig> <pubKey> and calculate the
> Bitcoin address from <pubKey>.
> But then I started to wonder if this is safe. Can this be tricked somehow?

Sure. There are lots of non-standard scriptPubKey scripts that will
validate if given <sig> <pubKey> as input:  a simple OP_NOP would work
(do nothing, then check the top value on the stack and validate if it
is not zero-- and <pubKey> is not zero).

If you assume the client has all previous transactions, then you could
get the transaction input's prevout (from the memory pool or disk) and
then ExtractAddress() from it. That is probably a bad idea for
listtransactions, since fetching all the previous inputs from disk
just so you can check to see if they're 'green' violates the "a
feature shouldn't cost anything if it is not being used" design
principle.

You know, just thinking out loud...

Green addresses could be implemented as a second signature in the
scriptSig.  You'd have to hack your bitcoin client, but you could
generate a transaction that had <greensig> <sig> <pubKey>  ... as the
input instead of <sig> <pubKey>.

The <greensig> will be ignored by old clients.  The transactions is
still considered 'standard'.  But you could teach bitcoin to look for
<greensig> signatures in wallet transactions...

-- 
--
Gavin Andresen



  parent reply	other threads:[~2011-10-24 14:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-24  8:29 [Bitcoin-development] Determine input addresses of a transaction Jan Vornberger
2011-10-24 11:09 ` Pieter Wuille
2011-10-27 14:12   ` Jan Vornberger
2011-10-24 14:55 ` Gavin Andresen [this message]
2011-10-24 16:25   ` Mike Hearn
2011-10-24 18:52     ` Simon Barber
2011-10-24 17:14   ` Michael Hendricks
2011-10-27 13:37   ` Jan Vornberger
2011-10-27 14:50   ` Jan Vornberger
2011-10-25  9:45 Jan Vornberger
2011-10-25 10:03 ` Joel Joonatan Kaartinen
2011-10-25 10:42 ` Mike Hearn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABsx9T2v4uhUdsWEg58Xs2OhOf3ED0Q2LGmkrRpdJDxvVMexdQ@mail.gmail.com \
    --to=gavinandresen@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=jan@uos.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox