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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1Qklmy-0000vW-53
for bitcoin-development@lists.sourceforge.net;
Sat, 23 Jul 2011 23:39:20 +0000
Received-SPF: pass (sog-mx-2.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-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Qklmx-0003U8-9L
for bitcoin-development@lists.sourceforge.net;
Sat, 23 Jul 2011 23:39:20 +0000
Received: by qwh5 with SMTP id 5so2218685qwh.34
for <bitcoin-development@lists.sourceforge.net>;
Sat, 23 Jul 2011 16:39:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.66.219 with SMTP id o27mr2391238qci.26.1311464353051; Sat,
23 Jul 2011 16:39:13 -0700 (PDT)
Received: by 10.229.83.196 with HTTP; Sat, 23 Jul 2011 16:39:13 -0700 (PDT)
Date: Sat, 23 Jul 2011 19:39:13 -0400
Message-ID: <CAAS2fgQ-L-1K2Oi40tqnhxpnnWQHqgbd4BmqedhA3WcevYiCzg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
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 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Qklmx-0003U8-9L
Subject: [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: Sat, 23 Jul 2011 23:39:20 -0000
Pull 349 (https://github.com/bitcoin/bitcoin/pull/349)
implements a pretty nice implementation of multiple signature escrowed
transactions. Especially with clearcoin gone I think that this is
something we ought to have sooner rather than later.
I've tested it on a private network and it appears to work pretty well.
It probably needs more testing and discussion before it is actually
added to the client, but one challenge is that because it requires a
new transaction type it won't be deployable until _after_ an updated
isStandard is widely used in the network.
So I think that makes a good argument for separating out the
IsStandard part of the patch and getting it out in 0.4.
Unfortunately, the patch exposes an issue with multisig validation: If
I understand it correctly, the problem is that due to redundancy in
the script length coding opcodes it's possible to code a script
multiple ways. The signature validation code creates new template
scripts in order to evaluate signatures for one output, and the code
in bitcoin is not careful to code the new script the same way the
original one was coded, causing the signature validation to fail when
something used OP_PUSHDATA when a direct length could have been used.
Pull 349 (https://github.com/bitcoin/bitcoin/pull/349) contains one
candidate fix for this: Excluding the length opcodes from the
comparison.
This fix carries a risk of creating differences in how nodes validate
transactions leading to lasting forks. (e.g. Old clients will reject a
block which new clients would have accepted). I do also wonder about
strange effects arising from multiple valid TXN which are identical in
meaning but have different hashes, but I guess thats already possible
in a number of different ways.
Another way of fixing this would be to just define that OP_PUSHDATA*
_cannot_ be used to push the smaller lengths which could be more
efficiently encoded with the direct length opcodes. I think this
would have the benefit of being consistent with the current behavior
and carry no severe split risk.
Yet way of fixing it would be to change out the templating code works
to make sure it codes the template the same way the original was
coded. This seems tricky to implement to me, tricky to validate, but
it would potentially be beneficial if this same class of problem
exists for things other than the length coding.
|
