From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; Fri, 25 Apr 2014 20:27:33 +0000 (UTC) From: "Luke-Jr" 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: <201404251917.49826.luke@dashjr.org> In-Reply-To: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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...