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
113
114
115
116
117
118
119
120
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andyparkins@gmail.com>) id 1QrZ02-00016L-AF
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Aug 2011 17:24:54 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.175 as permitted sender)
client-ip=74.125.82.175; envelope-from=andyparkins@gmail.com;
helo=mail-wy0-f175.google.com;
Received: from mail-wy0-f175.google.com ([74.125.82.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QrZ01-0003FQ-3B
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Aug 2011 17:24:54 +0000
Received: by wyf19 with SMTP id 19so2385041wyf.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 11 Aug 2011 10:24:47 -0700 (PDT)
Received: by 10.216.236.193 with SMTP id w43mr8419263weq.35.1313083486870;
Thu, 11 Aug 2011 10:24:46 -0700 (PDT)
Received: from grissom.localnet ([91.84.15.31])
by mx.google.com with ESMTPS id p49sm1367642weq.7.2011.08.11.10.24.44
(version=TLSv1/SSLv3 cipher=OTHER);
Thu, 11 Aug 2011 10:24:45 -0700 (PDT)
From: Andy Parkins <andyparkins@gmail.com>
To: Mike Hearn <mike@plan99.net>
Date: Thu, 11 Aug 2011 18:24:42 +0100
User-Agent: KMail/1.13.6 (Linux/2.6.39-2-686-pae; KDE/4.6.4; i686; ; )
References: <CANEZrP2hvYst92u22c_41e9=izPCP7uv-RzVM4XSt7gxC99D0A@mail.gmail.com>
In-Reply-To: <CANEZrP2hvYst92u22c_41e9=izPCP7uv-RzVM4XSt7gxC99D0A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201108111824.42807.andyparkins@gmail.com>
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
(andyparkins[at]gmail.com)
-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
0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QrZ01-0003FQ-3B
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [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 17:24:54 -0000
On Thursday 11 August 2011 17:17:23 Mike Hearn wrote:
> This thread is getting off-topic so I changed the subject.
Fair enough.
> > 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.
Well okay; it seems to me that that is considerably bigger task, and I'm not
sure how likely that is to appear. But that sounds workable, since my
feature request is simply this filtering system with the filter set to
"ALL"; so I can hardly complain about that.
> > 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.
... good stuff removed for brevity ...
> 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.
I can't say I see what the point of all that added complexity is, contracts
are usually more than just financial, and the ability to pick a slightly
different set of source inputs doesn't seem like a hugely useful feature;
but I'm willing to accept someone thinks it is a good idea and leave it at
that. I withdraw my "move sequence number" feature request.
> 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.
What then allows the contract out of the memory pool into a chain? The
locktime? No, no, forget it... I don't want to open a new can of worms.
Andy
--
Dr Andy Parkins
andyparkins@gmail.com
|
