summaryrefslogtreecommitdiff
path: root/69/e1cdbeac0816651437639066a54ad628c56f4f
blob: 79f067a7690f9999d8b43ebe5440448a5424fce6 (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
86
87
88
89
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <luke@dashjr.org>) id 1WdmiA-0006nj-TA
	for bitcoin-development@lists.sourceforge.net;
	Fri, 25 Apr 2014 20:27:06 +0000
X-ACL-Warn: 
Received: from zinan.dashjr.org ([192.3.11.21])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1Wdmi7-0005Ii-Cz for bitcoin-development@lists.sourceforge.net;
	Fri, 25 Apr 2014 20:27:06 +0000
Received: from ishibashi.localnet (unknown
	[IPv6:2001:470:5:265:be5f:f4ff:febf:4f76])
	(Authenticated sender: luke-jr)
	by zinan.dashjr.org (Postfix) with ESMTPSA id D07C2108011E
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 25 Apr 2014 20:27:33 +0000 (UTC)
From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Fri, 25 Apr 2014 20:26:55 +0000
User-Agent: KMail/1.13.7 (Linux/3.12.6-gentoo; KDE/4.11.5; x86_64; ; )
References: <CAE-z3OXe4fG2S274qcgpGsXA=ZhhJQneEDqLYvNWZT8U9y_NLA@mail.gmail.com>
	<201404251917.49826.luke@dashjr.org>
	<CAE-z3OX5_POg9kFoz-LsGhuLRA6qFPcNXoECLhewe+o-+Pw2gA@mail.gmail.com>
In-Reply-To: <CAE-z3OX5_POg9kFoz-LsGhuLRA6qFPcNXoECLhewe+o-+Pw2gA@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201404252026.56765.luke@dashjr.org>
X-Spam-Score: -0.7 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
X-Headers-End: 1Wdmi7-0005Ii-Cz
Subject: Re: [Bitcoin-development] BIP - Selector Script
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: Fri, 25 Apr 2014 20:27:07 -0000

On Friday, April 25, 2014 8:02:41 PM Tier Nolan wrote:
> I don't think the cross chain system needs a BIP (except to justify this
> one).
> 
> If cross chain transfer become popular, then it would be useful to ensure
> that clients are interoperable, but first things first.  If the
> transactions aren't accepted in any chains, then everything stalls.

I think you may be misunderstanding what BIPs are. They do not force nodes to 
take on any given relay/mining policy (thus, BIPs should never talk about 
IsStandard at all). They define standard for interoperability between 
software. So, if you want nodes to relay these transactions, you need to 
convince them, not merely write a BIP for the transaction format. Defining a 
BIP for cross-chain trading would be one way to do that.

> Secure transfers require that the malleability issue is fixed, but that is
> a separate issue.  I am assuming that will be fixed at some point in the
> future, since micro-payment channels also requires that it is fixed.

The malleability "issue" has been known for years.
I wouldn't expect any special effort made to fix it...

> A soft fork that expands P2SH functionality would be even better, but I
> would rather not let the best be the enemy of the good.

There is some ongoing discussion of a softfork to basically redo the Script 
language entirely, but it will take quite a bit of time and development before 
we'll see it in the wild.

Luke

P.S. Did the BIP editor assign these numbers? If not, best to keep them 
numberless until assigned, to avoid confusion when people Google the real BIP 
44 and 45...