From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wdn3L-00081L-1p for bitcoin-development@lists.sourceforge.net; Fri, 25 Apr 2014 20:48:59 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.182 as permitted sender) client-ip=209.85.216.182; envelope-from=tier.nolan@gmail.com; helo=mail-qc0-f182.google.com; Received: from mail-qc0-f182.google.com ([209.85.216.182]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wdn3K-00069z-0b for bitcoin-development@lists.sourceforge.net; Fri, 25 Apr 2014 20:48:59 +0000 Received: by mail-qc0-f182.google.com with SMTP id e16so4637725qcx.27 for ; Fri, 25 Apr 2014 13:48:52 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.224.125.74 with SMTP id x10mr14813205qar.99.1398458932569; Fri, 25 Apr 2014 13:48:52 -0700 (PDT) Received: by 10.140.25.86 with HTTP; Fri, 25 Apr 2014 13:48:52 -0700 (PDT) In-Reply-To: <201404252026.56765.luke@dashjr.org> References: <201404251917.49826.luke@dashjr.org> <201404252026.56765.luke@dashjr.org> Date: Fri, 25 Apr 2014 21:48:52 +0100 Message-ID: From: Tier Nolan To: Luke-Jr Content-Type: multipart/alternative; boundary=001a11c30886e8dcc204f7e417fe X-Spam-Score: -0.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 (tier.nolan[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1Wdn3K-00069z-0b Cc: Bitcoin Dev 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:48:59 -0000 --001a11c30886e8dcc204f7e417fe Content-Type: text/plain; charset=UTF-8 On Fri, Apr 25, 2014 at 9:26 PM, Luke-Jr wrote: > 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. I agree with you in theory, each miner could decide their inclusion rules for themselves. In practice, if the reference client is updated, then most miners will accept those transactions. In addition, it would eventually propagate to alt-coins (or at least the supported ones). I could simply submit the changes as a pull request for the reference client, but I was hoping that by doing it this way, it would increase the odds of it being accepted. > Defining a BIP for cross-chain trading would be one way to do that. > I don't think it quite requires the same coordination in the short term. I could write up the sequence as an info BIP. The malleability "issue" has been known for years. > I wouldn't expect any special effort made to fix it... > It is possible to tweak the protocol so that it still works. However, it means that 3rd parties are required (that could go in the BIP too). > 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. > Implementing multi-P2SH gets a lot of the benefits of MAST, in terms of efficiency. > > 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... > Not yet, but that is just my personal repo. I did email gmaxwell, but he said that they can't be assigned until some discussion has happened. I take your point that the name appears in the link though, so could cause issues with searching. > > ------------------------------------------------------------------------------ > Start Your Social Network Today - Download eXo Platform > Build your Enterprise Intranet with eXo Platform Software > Java Based Open Source Intranet - Social, Extensible, Cloud Ready > Get Started Now And Turn Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --001a11c30886e8dcc204f7e417fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 25, 2014 at 9:26 PM, Luke-Jr <luke@dashjr.org> wrote:
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.

I agree with you in theory, each miner could decide = their inclusion rules for themselves.

In practice, if the reference = client is updated, then most miners will accept those transactions.=C2=A0 I= n addition, it would eventually propagate to alt-coins (or at least the sup= ported ones).

I could simply submit the changes as a pull request for the = reference client, but I was hoping that by doing it this way, it would incr= ease the odds of it being accepted.
=C2=A0
Defining a BIP for cross-chain trading would be one way to do that.

I don't think it quite requires the same = coordination in the short term.=C2=A0 I could write up the sequence as an i= nfo BIP.

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

It is possible to tweak the protocol so that it still w= orks.=C2=A0 However, it means that 3rd parties are required (that could go = in the BIP too).
=C2=A0
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 bef= ore
we'll see it in the wild.

Implement= ing multi-P2SH gets a lot of the benefits of MAST, in terms of efficiency.<= br>
=C2=A0

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 B= IP
44 and 45...

Not yet, but that is just = my personal repo.=C2=A0 I did email gmaxwell, but he said that they can'= ;t be assigned until some discussion has happened.
=C2=A0
=
I take your point that the name appears in the link though, so could c= ause issues with searching.


---------------------------------------------------------------------------= ---
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.n= et/sfu/ExoPlatform
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a11c30886e8dcc204f7e417fe--