Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1RINLV-0001ol-3T
	for bitcoin-development@lists.sourceforge.net;
	Mon, 24 Oct 2011 16:25:53 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.53 as permitted sender)
	client-ip=74.125.82.53; envelope-from=mh.in.england@gmail.com;
	helo=mail-ww0-f53.google.com; 
Received: from mail-ww0-f53.google.com ([74.125.82.53])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1RINLP-0000vD-H9
	for bitcoin-development@lists.sourceforge.net;
	Mon, 24 Oct 2011 16:25:53 +0000
Received: by wwi36 with SMTP id 36so8376052wwi.10
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 24 Oct 2011 09:25:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.132.144 with SMTP id o16mr3267200wei.106.1319473541322;
	Mon, 24 Oct 2011 09:25:41 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.216.10.148 with HTTP; Mon, 24 Oct 2011 09:25:41 -0700 (PDT)
In-Reply-To: <CABsx9T2v4uhUdsWEg58Xs2OhOf3ED0Q2LGmkrRpdJDxvVMexdQ@mail.gmail.com>
References: <44861.134.106.52.172.1319444997.squirrel@webmail.uni-osnabrueck.de>
	<CABsx9T2v4uhUdsWEg58Xs2OhOf3ED0Q2LGmkrRpdJDxvVMexdQ@mail.gmail.com>
Date: Mon, 24 Oct 2011 18:25:41 +0200
X-Google-Sender-Auth: 2gVzq5fsuUpFkHLNghoI0hLlO4I
Message-ID: <CANEZrP1W3r65t7yW8SOR-MLm-VFw2bqy1HOSEVTPRMiaWpFKYg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=0016e6de0454b897e304b00ddf83
X-Spam-Score: -0.5 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1RINLP-0000vD-H9
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: Mon, 24 Oct 2011 16:25:53 -0000

--0016e6de0454b897e304b00ddf83
Content-Type: text/plain; charset=UTF-8

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

--0016e6de0454b897e304b00ddf83
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">You know, just t=
hinking out loud...<br>
<br>
Green addresses could be implemented as a second signature in the<br>
scriptSig.</blockquote><div><br></div><div>I think this would solve one of =
the other issues I raised about the green address idea .... you can have so=
me kind of trust aggregator sign the transactions. Merchants like MtGox tha=
t send would create a transaction, export it, upload it to the trusted auth=
ority which can just check IP address or something to verify it&#39;s reall=
y coming from MtGox, then sign it and broadcast it.</div>
<div><br></div><div><br></div></div>

--0016e6de0454b897e304b00ddf83--