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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jan@uos.de>) id 1RJQ9Y-0005Cv-S8
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Oct 2011 13:37:52 +0000
X-ACL-Warn:
Received: from vm119.rz.uni-osnabrueck.de ([131.173.17.200]
helo=mail-in-7.serv.Uni-Osnabrueck.DE)
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1RJQ9X-00005d-4i
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Oct 2011 13:37:52 +0000
Received: from vm179.rz.Uni-Osnabrueck.DE (vm179.rz.uni-osnabrueck.de
[131.173.16.37])
by mail-in-7.serv.Uni-Osnabrueck.DE (8.13.8/8.13.8) with ESMTP id
p9RDbhij001122 for <bitcoin-development@lists.sourceforge.net>;
Thu, 27 Oct 2011 15:37:43 +0200
Received: by vm179.rz.Uni-Osnabrueck.DE (Postfix, from userid 48)
id 83688611; Thu, 27 Oct 2011 15:37:43 +0200 (CEST)
Received: from 134.106.52.172 (SquirrelMail authenticated user jan)
by webmail.uni-osnabrueck.de with HTTP;
Thu, 27 Oct 2011 15:37:43 +0200 (CEST)
Message-ID: <55928.134.106.52.172.1319722663.squirrel@webmail.uni-osnabrueck.de>
In-Reply-To: <CABsx9T2v4uhUdsWEg58Xs2OhOf3ED0Q2LGmkrRpdJDxvVMexdQ@mail.gmail.com>
References: <44861.134.106.52.172.1319444997.squirrel@webmail.uni-osnabrueck.de>
<CABsx9T2v4uhUdsWEg58Xs2OhOf3ED0Q2LGmkrRpdJDxvVMexdQ@mail.gmail.com>
Date: Thu, 27 Oct 2011 15:37:43 +0200 (CEST)
From: "Jan Vornberger" <jan@uos.de>
To: "Bitcoin Dev" <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.27.133017 (Univ. Osnabrueck)
X-PMX-Spam: Gauge=XI, Probability=11%, Report=
PRIORITY_NO_NAME 0.716, BODYTEXTP_SIZE_3000_LESS 0,
BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0,
BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0,
BODY_SIZE_700_799 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, __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: 1RJQ9X-00005d-4i
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: Thu, 27 Oct 2011 13:37:52 -0000
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
|
