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
|
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 <theymos@mm.st>) 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 <bitcoin-development@lists.sourceforge.net>;
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" <theymos@mm.st>
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: <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
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: <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: 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" <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.
|
