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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1Qp4e7-00053I-Of
for bitcoin-development@lists.sourceforge.net;
Thu, 04 Aug 2011 20:35:59 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.47 as permitted sender)
client-ip=209.85.216.47; envelope-from=gmaxwell@gmail.com;
helo=mail-qw0-f47.google.com;
Received: from mail-qw0-f47.google.com ([209.85.216.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Qp4e7-0007S1-0S
for bitcoin-development@lists.sourceforge.net;
Thu, 04 Aug 2011 20:35:59 +0000
Received: by qwh5 with SMTP id 5so1710551qwh.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 04 Aug 2011 13:35:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.2.155 with SMTP id 27mr1018186qcj.216.1312490153536; Thu,
04 Aug 2011 13:35:53 -0700 (PDT)
Received: by 10.229.3.141 with HTTP; Thu, 4 Aug 2011 13:35:53 -0700 (PDT)
In-Reply-To: <43351.137.56.163.46.1312351847.squirrel@lavabit.com>
References: <CAAS2fgQ-L-1K2Oi40tqnhxpnnWQHqgbd4BmqedhA3WcevYiCzg@mail.gmail.com>
<43351.137.56.163.46.1312351847.squirrel@lavabit.com>
Date: Thu, 4 Aug 2011 16:35:53 -0400
Message-ID: <CAAS2fgQ6GXfebUV8_PLVpLJ9jvPF8FXiBqwquhGFNZ+Vt3uCtg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: bgroff@lavabit.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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
(gmaxwell[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 T_TO_NO_BRKTS_FREEMAIL To: misformatted and free email service
-0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Qp4e7-0007S1-0S
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Discussion related to pull 349 and pull
319 (escrow transactions)
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, 04 Aug 2011 20:35:59 -0000
On Wed, Aug 3, 2011 at 2:10 AM, <bgroff@lavabit.com> wrote:
> Thank you! =C2=A0(I think you mean 319 here)
Correct.
> With Eligius mining !IsStandard transactions and probably other pools ope=
n
> to the idea, I am hopeful that we can quickly get 30%+ of mining power to
> upgrade, which means that we could still mine these in a reasonable time
> frame (under 1 hour).
It's not just a matter of mining power, it's also a question of
propagation. Matt and I tried to perform a non-standard transaction
weeks ago and weren't able to get in mined after many hours. (we
eventually double spent the input with a normal transaction in order
to make it go away, interestingly one point about non-propagating txn
is that they're extra vulnerable to double spending by a standard txn,
as the non-standard one won't preclude the propagation of the standard
one)
From discussion on IRC it seemed clear enough that the current focus
on maturity/bugfixes is probably going to delay your full patch, but
the IsStandard part is uncontroversial and could go in quickly.
Based on that I think it would be very useful to split 319 into two
pull requests: one which does the IsStandard change, and one which
adds the full escrow feature set. This way when the escrow patch does
enter the mainline client it will be meet up with a network which is
happy to handle its transactions.
(and people who are eager to use escrow can use modified clients on
the main network before that point in time)
> I'm not sure I see the problem here. CScript.operator<< currently insert=
s
> values into scripts using the shortest possible sequence.
Ah for some reason I thought your current code did not always produce
the shortest sequence.
If so, I see no reason to block on the other pull.
|