summaryrefslogtreecommitdiff
path: root/c1/31c8dfb54cda0864c0e079f8ddd1e3d4a7d6cf
blob: 7bbb23b3ae75c2085cf69c0991c4449d70a609fc (plain)
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
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 <bitcoin-list@bluematt.me>) id 1XmVBr-0008BO-4V
	for bitcoin-development@lists.sourceforge.net;
	Thu, 06 Nov 2014 22:06:03 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bluematt.me
	designates 192.241.179.72 as permitted sender)
	client-ip=192.241.179.72; envelope-from=bitcoin-list@bluematt.me;
	helo=mail.bluematt.me; 
Received: from mail.bluematt.me ([192.241.179.72])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1XmVBp-0001vz-8h
	for bitcoin-development@lists.sourceforge.net;
	Thu, 06 Nov 2014 22:06:03 +0000
Received: from [172.17.0.2] (gw.vpn.bluematt.me [162.243.132.6])
	by mail.bluematt.me (Postfix) with ESMTPSA id 95CA34C145
	for <bitcoin-development@lists.sourceforge.net>;
	Thu,  6 Nov 2014 22:05:55 +0000 (UTC)
Message-ID: <545BF0C2.3030201@bluematt.me>
Date: Thu, 06 Nov 2014 22:05:54 +0000
From: Matt Corallo <bitcoin-list@bluematt.me>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <20141106213215.GA12918@savin.petertodd.org>
	<A53D2C60-1D6A-4796-9776-3AF396BEC9F1@bitsofproof.com>
In-Reply-To: <A53D2C60-1D6A-4796-9776-3AF396BEC9F1@bitsofproof.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.1 (--)
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 SPF_PASS               SPF: sender matches SPF record
	-0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
X-Headers-End: 1XmVBp-0001vz-8h
Subject: Re: [Bitcoin-development] The difficulty of writing consensus
 critical code: the SIGHASH_SINGLE bug
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, 06 Nov 2014 22:06:04 -0000

Depends, without BIP62 a /lot/ of the even basic contracts that people
want to use today (or wanted to use 18 months ago) are unusable, in
fact, without BIP62, the atomic swaps suggested as important for
sidechains are not secure. While redoing Bitcoin in a hardfork is nice,
its a very long-term thing, so I'm not sure about making people wait for
a large hardfork just to use payment channels.

Also, I echo the difficulty of writing consensus-compatible code and
highly suggest anyone with money behind an implementation that is doing
script verification in code that isnt Bitcoin Core rethink that decision.

Matt

On 11/06/14 21:58, Tamas Blummer wrote:
> Thanks Peter,
> 
> Having tried to write a bug-for-bug compatible code with Satoshi, I can only second that it is rather close to impossible. 
> 
> The aim of BIP62 is noble, still it does not feel right for me to increase the complexity of the code with e.g. soft-fork-ready versioning.
> Freezing the consensus code, studying its bugs appears more appropriate to me. What we learn could define a hard fork or a better
> chain we migrate to as discussed by blockstream.
> 
> Tamas Blummer