summaryrefslogtreecommitdiff
path: root/cc/71e5ad7285f89443fdf555c6d4d2016491fb2f
blob: 02839aac600e34276f0a46b4b449d545fc55f44e (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
81
82
83
84
85
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gmaxwell@gmail.com>) id 1YVmaQ-00056a-CE
	for bitcoin-development@lists.sourceforge.net;
	Wed, 11 Mar 2015 19:46:34 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.169 as permitted sender)
	client-ip=209.85.223.169; envelope-from=gmaxwell@gmail.com;
	helo=mail-ie0-f169.google.com; 
Received: from mail-ie0-f169.google.com ([209.85.223.169])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YVmaL-0003mq-2R
	for bitcoin-development@lists.sourceforge.net;
	Wed, 11 Mar 2015 19:46:34 +0000
Received: by iecsl2 with SMTP id sl2so5661999iec.1
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 11 Mar 2015 12:46:23 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.107.7 with SMTP id gy7mr67603599igb.49.1426103182142;
	Wed, 11 Mar 2015 12:46:22 -0700 (PDT)
Received: by 10.107.6.133 with HTTP; Wed, 11 Mar 2015 12:46:22 -0700 (PDT)
In-Reply-To: <CALC81CPonBX5pGucU9Pu7P7S042c+h8=vNvocX=7f9Yi_kqv5w@mail.gmail.com>
References: <54F32EED.6040103@electrum.org>
	<CANEZrP23buJF0ENfrKGRuzpQ3Uod09s-kRcb3CBw1-OmUxEyZg@mail.gmail.com>
	<550057FD.6030402@electrum.org>
	<CANEZrP2UrRYG2wh3DHHj9B3Sp1X=n+gPCRcoj1Fouu4Lg157UA@mail.gmail.com>
	<1426100677.1908596.239033309.7C4F8D47@webmail.messagingengine.com>
	<CALC81CPonBX5pGucU9Pu7P7S042c+h8=vNvocX=7f9Yi_kqv5w@mail.gmail.com>
Date: Wed, 11 Mar 2015 19:46:22 +0000
Message-ID: <CAAS2fgRuBwn6HXeZeth+x-R8DAdsVZmYy4nMA3kN+oJaURftgw@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Ricardo Filipe <ricardojdfilipe@gmail.com>
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
X-Headers-End: 1YVmaL-0003mq-2R
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Electrum 2.0 has been tagged
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: Wed, 11 Mar 2015 19:46:34 -0000

On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
<ricardojdfilipe@gmail.com> wrote:
> i guess you look at the glass half full :)
> even though what you say is true, we should aim for wallets not to
> require those instructions, by standardizing these things in BIPs.
> let's hope bitcoin doesn't fail in standards as our industries have in
> the past...

There are genuine principled disagreements on how some things should
be done. There are genuine differences in functionality.

We cannot expect and should not expect complete compatibility. If you
must have complete compatibility: use the same software (or maybe not
even then, considering how poor the forward compatibility of some
things has been..).

What we can hope to do, and I think the best we can hope to do, is to
minimize the amount of gratuitous incompatibility and reduce the
amount of outright flawed constructions (so if there are choices which
must be made, they're at least choices among relatively good options).