Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of mm.st
	designates 66.111.4.26 as permitted sender)
	client-ip=66.111.4.26; envelope-from=theymos@mm.st;
	helo=out2.smtp.messagingengine.com; 
Message-Id: <1320876816.29760.140660996851709@webmail.messagingengine.com>
From: "theymos" <theymos@mm.st>
To: bitcoin-development@lists.sourceforge.net
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
References: <BD206D96-C458-4DD7-92F6-32AE476C259A@ceptacle.com><CABsx9T3T7UZ-G9wsb_NDMBYpnnp9XBnjULmVVDgVXzEaUKn=5w@mail.gmail.com>
	<CABsx9T3ESoZ21h_V0a8PZAN4MS+KRZ8eVjKc47p9wgJmH0jt-g@mail.gmail.com>
In-Reply-To: <CABsx9T3ESoZ21h_V0a8PZAN4MS+KRZ8eVjKc47p9wgJmH0jt-g@mail.gmail.com>
Date: Wed, 09 Nov 2011 16:13:36 -0600
Subject: Re: [Bitcoin-development] multisig,
 op_eval and lock_time/sequence...
Precedence: list

For now I think requiring direct-connection negotiation is best for these kinds of things. A direct connection is OK in most cases, and more complicated schemes will be more likely to fail. Maybe the IP transactions protocol can be used.

In the future, I imagine that users of ultra-lightweight clients will connect to a new P2P network built on top of the core Bitcoin network in order to receive block headers and info about sent/received transactions without leeching off of the few full nodes. This network could also be used for indirect transaction negotiation, which is similar to the goal of finding your own received transactions.

On Wednesday, November 09, 2011 3:02 PM, "Gavin Andresen" <gavinandresen@gmail.com> wrote:
> a nValue=0 transaction can be considered 'immediately spent'

I believe it's possible to spend a 0-value output, so they can't be considered automatically spent.