[Bitcoin-development] Determine input addresses of a transaction

[Bitcoin-development] Determine input addresses of a transaction

[Jan Vornberger]

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.

I understand that this is not generally possible, because of the different
possible structures enabled through the scripting language. But it would
be fine, if this only worked for 'regular' transactions.

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>. The patch for this is here:

https://github.com/javgh/bitcoin/compare/vps_wheezy...showinputaddresses

But then I started to wonder if this is safe. Can this be tricked somehow?
Would it be possible to create a valid transaction which has an input that
has only two opcodes but with an arbitrary pubKey at the second position?
Could someone who has a better grasp on the scripting capabilities comment
on this?

Or alternatively: should I determine the input addresses of a transaction
in a different way? if so, how?

Regards!
Jan

Re: [Bitcoin-development] Determine input addresses of a transaction

[Pieter Wuille]

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

Re: [Bitcoin-development] Determine input addresses of a transaction

[Gavin Andresen]

> 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

Re: [Bitcoin-development] Determine input addresses of a transaction

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

>
> You know, just thinking out loud...
>
> Green addresses could be implemented as a second signature in the
> scriptSig.


I think this would solve one of the other issues I raised about the green
address idea .... you can have some kind of trust aggregator sign the
transactions. Merchants like MtGox that send would create a transaction,
export it, upload it to the trusted authority which can just check IP
address or something to verify it's really coming from MtGox, then sign it
and broadcast it.

[-- Attachment #2: Type: text/html, Size: 718 bytes --]

Re: [Bitcoin-development] Determine input addresses of a transaction

[Michael Hendricks]

[-- Attachment #1: Type: text/plain, Size: 736 bytes --]

On Mon, Oct 24, 2011 at 8:55 AM, Gavin Andresen <gavinandresen@gmail.com>wrote:

> 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.
>

Are there current users of gettransaction for whom the performance penalty
would be problematic?  If so, perhaps gettransaction could take an optional
second argument includeinputaddresses which defaults to false.

-- 
Michael

[-- Attachment #2: Type: text/html, Size: 1197 bytes --]

Re: [Bitcoin-development] Determine input addresses of a transaction

[Simon Barber]

PKI would avoid the need for the trust aggregator to be consulted for 
each transaction. Obviously checking for revocation would be essential. 
The CA cert can state what kind of guarantee is available.

Simon


On 10/24/2011 09:25 AM, Mike Hearn wrote:
>     You know, just thinking out loud...
>
>     Green addresses could be implemented as a second signature in the
>     scriptSig.
>
>
> I think this would solve one of the other issues I raised about the
> green address idea .... you can have some kind of trust aggregator sign
> the transactions. Merchants like MtGox that send would create a
> transaction, export it, upload it to the trusted authority which can
> just check IP address or something to verify it's really coming from
> MtGox, then sign it and broadcast it.
>
>
>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Determine input addresses of a transaction

[Jan Vornberger]

Am Mo, 24.10.2011, 16:55, schrieb Gavin Andresen:
> 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...

I played around with this a little bit and managed to generate such
transactions. However, I ran into the problem that IsStandard() also
checks that the size of scriptSig is not above 200. Adding an extra
signature there triggers this limit. I guess there is no way around
that?

Regards,
Jan

Re: [Bitcoin-development] Determine input addresses of a transaction

[Jan Vornberger]

Am Mo, 24.10.2011, 13:09, schrieb Pieter Wuille:
> 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?

That would be fine as well. Although I would prefer if one could
query for a specific transaction id, whether it comes from a trusted
source and also from which trusted source, as you might want to
keep track of the amount of unconfirmed funds you are currently
accepting from a specific source (or the Bitcoin daemon could
keep track of that as well, either way is fine).

This sounds a little too involved though, for my level of familiarity
with the Bitcoin source code and C++, to implement myself.

Regards,
Jan

Re: [Bitcoin-development] Determine input addresses of a transaction

[Jan Vornberger]

Am Mo, 24.10.2011, 16:55, schrieb Gavin Andresen:
> 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.

I now created a patch based on this idea. To avoid slowing down
listtransactions or gettransaction, I put it in a separate RPC
call 'getorigins'. This is the patch:

https://github.com/javgh/bitcoin/compare/bfa4600a93...getorigins

Any obvious mistakes I made there?

Regards!
Jan

Re: [Bitcoin-development] Determine input addresses of a transaction

[Mike Hearn]

> Interesting suggestion! So if I understand correctly, <greensig> would be
> the signature generated from signing the transaction with the key of a
> green address?

Sure. Or just "a key". It wouldn't have to be an actual key used in
the block chain.

> Sounds good - I guess I never thought in this direction, as I always
> assumed doing anything 'non-standard' with the scripting language would
> create a number of knock-on problems.

It won't break the IsStandard checks, if that's what you mean. You can
put any data you like into a scriptSig. In practice only data is
useful, there's no purpose in having an actual script there (or at
least, I wasn't able to find one yet).

> 1) Get something working reasonable fast to detect current green address
> style transactions. It's fine if it is a little bit of a hack, as long as
> it's safe, since I don't expect it to be merged with mainline anyway at
> this point.

You could easily change the bitcoin code to detect such transactions -
just look for scriptSigs that have 3 items instead of two, where the
3rd item is the right size to be a signature.

> Criticism ranging from 'unnecessary, as
> 0-confirmation transactions are fairly safe today' to 'encourages too much
> centralization and therefore evil'

Heh, if that's a reference to my feedback, I definitely wouldn't
describe such a feature as "evil", that's rather strong :-)

Re: [Bitcoin-development] Determine input addresses of a transaction

[Joel Joonatan Kaartinen]

On Tue, 2011-10-25 at 11:45 +0200, Jan Vornberger wrote:
> 1) Get something working reasonable fast to detect current green address
> style transactions. It's fine if it is a little bit of a hack, as long as
> it's safe, since I don't expect it to be merged with mainline anyway at
> this point.
> 
> 2) Rethink how green transactions are created and verified and try to put
> something 'proper' together which has a chance of being merged at some
> point.
> 
> For the moment I was going more with 1) because I got the impression, that
> green transactions are too controversial at this point to get them
> included in mainline. Criticism ranging from 'unnecessary, as
> 0-confirmation transactions are fairly safe today' to 'encourages too much
> centralization and therefore evil'. So how to people on this list feel
> about green transactions? Would people be interested in helping me with
> 2)?

One possibility would be to create a peer sourced green address
implementation. That is, each user could, individually decide to trust
certain addresses as "green" and optionally, publish this trust. Basing
things on the published trust, you could dynamically, as opposed to
static hierarchies, evaluate the trustworthiness of each green address
you haven't personally decided to trust.

This would be somewhat involved implementation, though, as it would
require heavy statistical calculations.

- Joel

Re: [Bitcoin-development] Determine input addresses of a transaction

[Jan Vornberger]

Am Mo, 24.10.2011, 16:55, schrieb Gavin Andresen:
>> 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).

Aw, I see. So back to the drawing board for me.

How about this: I make sure that <sig> is a proper signature from a green
address key, by bringing my own scriptPubKey of just OP_CHECKSIG, complete
the script to be <sig> <pubKey> OP_CHECKSIG, and run it and afterwards
check the address by looking at <pubKey>? Would that be safe? (Even if it
is a hackish solution that only works for certain type of transactions):

> 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>.

Interesting suggestion! So if I understand correctly, <greensig> would be
the signature generated from signing the transaction with the key of a
green address? Which would allow the rest of the transaction to be
completely 'normal' and not require it to use specific inputs as such?
Sounds good - I guess I never thought in this direction, as I always
assumed doing anything 'non-standard' with the scripting language would
create a number of knock-on problems. But you are saying, that this would
still be considered standard? I guess I have to study this part of the
source code more.

Well, I guess I'm torn a little bit between two options:

1) Get something working reasonable fast to detect current green address
style transactions. It's fine if it is a little bit of a hack, as long as
it's safe, since I don't expect it to be merged with mainline anyway at
this point.

2) Rethink how green transactions are created and verified and try to put
something 'proper' together which has a chance of being merged at some
point.

For the moment I was going more with 1) because I got the impression, that
green transactions are too controversial at this point to get them
included in mainline. Criticism ranging from 'unnecessary, as
0-confirmation transactions are fairly safe today' to 'encourages too much
centralization and therefore evil'. So how to people on this list feel
about green transactions? Would people be interested in helping me with
2)?

Regards,
Jan