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
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
|
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 <mh.in.england@gmail.com>) id 1QrXwq-0003b5-5D
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Aug 2011 16:17:32 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.175 as permitted sender)
client-ip=209.85.220.175; envelope-from=mh.in.england@gmail.com;
helo=mail-vx0-f175.google.com;
Received: from mail-vx0-f175.google.com ([209.85.220.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QrXwp-0001Xl-1I
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Aug 2011 16:17:32 +0000
Received: by vxj14 with SMTP id 14so2607896vxj.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 11 Aug 2011 09:17:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.94.165 with SMTP id dd5mr7081274vdb.465.1313079443997; Thu,
11 Aug 2011 09:17:23 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.52.164.165 with HTTP; Thu, 11 Aug 2011 09:17:23 -0700 (PDT)
Date: Thu, 11 Aug 2011 18:17:23 +0200
X-Google-Sender-Auth: FkApfKrOpDiqpGwYv8kfl0-D9Mc
Message-ID: <CANEZrP2hvYst92u22c_41e9=izPCP7uv-RzVM4XSt7gxC99D0A@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Andy Parkins <andyparkins@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -0.8 (/)
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
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
0.7 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QrXwp-0001Xl-1I
Cc: bitcoin-development@lists.sourceforge.net
Subject: [Bitcoin-development] Protocol changes
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, 11 Aug 2011 16:17:32 -0000
This thread is getting off-topic so I changed the subject.
> The benefit I'm aiming at is to imagine a thin client that has done a fast
> startup and only downloaded the headers.
OK. A better way is tx filtering, as discussed here:
http://bitcointalk.org/?topic=7972.0
The reason is you want to only get the transactions+merkle branches
relevant to you, otherwise cost is still O(system activity) not O(your
activity) as blocks get bigger, even if you don't download every
block.
> The sequence number (and perhaps I've misunderstood) allows me to replace a
> transaction I've already submitted
Yes, but it's more complex than that.
Some contract protocols require one party in a set to be able to
re-issue transactions without interacting with the other parties. The
reason is that each input can come from a different person. If the
sequence number was a property of the transaction, updating it would
either require all participants to re-sign the transaction, or for the
signatures to not cover the sequence number at all.
With seqnums on the inputs, I can create a newer version of the
transaction by just resigning my input with a higher sequence number.
This is defined by IsNewerThan(). Note that my options here are
limited - I can't create an arbitrarily different version of the
transaction without invalidating all the other input signatures. If I
own all the inputs, no problem. If some are owned by others, what I
can change is defined by the SIGHASH flags. To replace this tx in the
memory pool requires others to re-sign their input with a higher
sequence number than mine - so we establish a kind of chain. Nobody
can rewind the transaction to an earlier point, but anyone can update
it within the parameters established by the SIGHASH flags on the
others signatures.
These features all combine together to allow for particular types of
contracts that take place on the negotiating table of the networks
memory pool. For instance, if you are taking part and then decide you
don't wish to continue, you can set the output that's in the same
position as your input to reassign all the money you put in back to
you, sign the input with SIGHASH_SINGLE and broadcast with nSequence
set to UINT_MAX. Now the transaction is still valid but is a no-op
from your perspective. Note that once you've done this, you've bowed
out of the negotiation completely because you can't replace the
transaction anymore.
You can't change anything about the inputs beyond scripts this way.
The transaction still has to connect to the same outputs as before,
and thus import the same amount of value.
|
