Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1ROGOt-000173-IG for bitcoin-development@lists.sourceforge.net; Wed, 09 Nov 2011 22:13:43 +0000 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; Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1ROGOs-0008TH-Hz for bitcoin-development@lists.sourceforge.net; Wed, 09 Nov 2011 22:13:43 +0000 Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 046BB210BF for ; Wed, 9 Nov 2011 17:13:37 -0500 (EST) Received: from web3.nyi.mail.srv.osa ([10.202.2.213]) by compute6.internal (MEProxy); Wed, 09 Nov 2011 17:13:37 -0500 Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id D373D4008C; Wed, 9 Nov 2011 17:13:36 -0500 (EST) Message-Id: <1320876816.29760.140660996851709@webmail.messagingengine.com> X-Sasl-Enc: V2Ak85F9P3gdVVboijMXttNZ9WCIUYDSHb23aAcAUY+J 1320876816 From: "theymos" To: bitcoin-development@lists.sourceforge.net MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface References: In-Reply-To: Date: Wed, 09 Nov 2011 16:13:36 -0600 X-Spam-Score: -1.6 (-) 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 (theymos[at]mm.st) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1ROGOs-0008TH-Hz Subject: Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence... X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 22:13:43 -0000 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" 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.