Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yzmtp-0003Vf-1X for bitcoin-development@lists.sourceforge.net; Tue, 02 Jun 2015 14:10:37 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.50 as permitted sender) client-ip=209.85.213.50; envelope-from=stephencalebmorse@gmail.com; helo=mail-yh0-f50.google.com; Received: from mail-yh0-f50.google.com ([209.85.213.50]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yzmto-0000N9-BM for bitcoin-development@lists.sourceforge.net; Tue, 02 Jun 2015 14:10:37 +0000 Received: by yhom41 with SMTP id m41so41555801yho.1 for ; Tue, 02 Jun 2015 07:10:30 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.170.128.139 with SMTP id u133mr32833271ykb.49.1433254230469; Tue, 02 Jun 2015 07:10:30 -0700 (PDT) Received: by 10.13.245.70 with HTTP; Tue, 2 Jun 2015 07:10:30 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Jun 2015 10:10:30 -0400 Message-ID: From: Stephen Morse To: Adam Back Content-Type: multipart/alternative; boundary=001a11395ece47b21005178981c0 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 (stephencalebmorse[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: 1Yzmto-0000N9-BM Cc: Bitcoin Development Subject: Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers 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: Tue, 02 Jun 2015 14:10:37 -0000 --001a11395ece47b21005178981c0 Content-Type: text/plain; charset=UTF-8 > > That would also introduce the anomaly of a script that was once valid > becoming later invalid, when nothing varies other than time. That is > not super compatible with the current model of reprocessing > transactions in later blocks if the block they were first in gets > reorged. > Very good point. > > (Not a huge flexibility loss as you can implement "not after" by > making it the previous holders responsibility to spend a "not before" > back to themselves.) > Do you mean something like the below? scriptPubKey: IF {A's pub} CHECKSIGVERIFY ELSE {curr_height + 100} CLTV {B's pub} CHECKSIGVERIFY This ensures that Alice has to spend the output in the next 100 blocks or risk it being taken from her (she just has to put an OP_TRUE on the end of her scriptSig). So, it seems we can forget about an inverted CLTV/CSV, great! Best, Stephen --001a11395ece47b21005178981c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That would also introduce the anomaly of a script that was onc= e valid
becoming later invalid, when nothing varies other than time.=C2=A0 That is<= br> not super compatible with the current model of reprocessing
transactions in later blocks if the block they were first in gets
reorged.

Very good point.=C2=A0
=C2=A0

(Not a huge flexibility loss as you can implement "not after" by<= br> making it the previous holders responsibility to spend a "not before&q= uot;
back to themselves.)

Do you mean someth= ing like the below?

scriptPubKey:= =C2=A0
=C2=A0 IF=C2=A0=
=C2=A0 = =C2=A0 {A's pub} CHECKSIGVERIFY
=C2=A0 ELSE
=C2=A0 =C2=A0 {curr_height + 100} CLTV {B's pub} CHECKSIGVERIFY

This ensures that Alice has to spend the outpu= t in the next 100 blocks or risk it being taken from her (she just has to p= ut an OP_TRUE on the end of her scriptSig). So, it seems we can forget abou= t an inverted CLTV/CSV, great!

Best,
Stephen


--001a11395ece47b21005178981c0--