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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jan@uos.de>) id 1RIdZw-00073M-AN
for bitcoin-development@lists.sourceforge.net;
Tue, 25 Oct 2011 09:45:52 +0000
X-ACL-Warn:
Received: from vm120.rz.uni-osnabrueck.de ([131.173.17.202]
helo=mail-in-4.serv.Uni-Osnabrueck.DE)
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1RIdZt-0002pR-Dr
for bitcoin-development@lists.sourceforge.net;
Tue, 25 Oct 2011 09:45:52 +0000
Received: from vm179.rz.Uni-Osnabrueck.DE (vm179.rz.uni-osnabrueck.de
[131.173.16.37])
by mail-in-4.serv.Uni-Osnabrueck.DE (8.13.8/8.13.8) with ESMTP id
p9P9jfeV024264 for <bitcoin-development@lists.sourceforge.net>;
Tue, 25 Oct 2011 11:45:41 +0200
Received: by vm179.rz.Uni-Osnabrueck.DE (Postfix, from userid 48)
id 88DBD5C1; Tue, 25 Oct 2011 11:45:41 +0200 (CEST)
Received: from 134.106.52.172 (SquirrelMail authenticated user jan)
by webmail.uni-osnabrueck.de with HTTP;
Tue, 25 Oct 2011 11:45:41 +0200 (CEST)
Message-ID: <44190.134.106.52.172.1319535941.squirrel@webmail.uni-osnabrueck.de>
Date: Tue, 25 Oct 2011 11:45:41 +0200 (CEST)
From: "Jan Vornberger" <jan@uos.de>
To: bitcoin-development@lists.sourceforge.net
User-Agent: SquirrelMail/1.4.8-5.el5_4.10
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2011.10.25.93314 (Univ. Osnabrueck)
X-PMX-Spam: Gauge=XI, Probability=11%, Report=
PRIORITY_NO_NAME 0.716, BODYTEXTP_SIZE_3000_LESS 0,
BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0,
BODY_SIZE_7000_LESS 0, WEBMAIL_SOURCE 0, WEBMAIL_USER_AGENT 0,
__ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0,
__BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0,
__HAS_MSGID 0, __HAS_X_PRIORITY 0, __MIME_TEXT_ONLY 0,
__MIME_VERSION 0, __PHISH_SPEAR_HTTP_RECEIVED 0,
__PHISH_SPEAR_STRUCTURE_1 0, __PHISH_SPEAR_STRUCTURE_2 0,
__SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0,
__URI_NO_MAILTO 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __USER_AGENT 0
X-PMX-Spam-Level: XI
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1RIdZt-0002pR-Dr
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: Tue, 25 Oct 2011 09:45:52 -0000
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
|
