path: root/a7/3c2b4664f4152d6220216b5ed13c4484d4258e

Return-Path: <roconnor@blockstream.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C0902C000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  9 Apr 2021 11:39:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 97925404C3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  9 Apr 2021 11:39:59 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key)
 header.d=blockstream-com.20150623.gappssmtp.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id W1jmaaf8q9VS
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  9 Apr 2021 11:39:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com
 [IPv6:2607:f8b0:4864:20::736])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 2DDF8404C0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  9 Apr 2021 11:39:58 +0000 (UTC)
Received: by mail-qk1-x736.google.com with SMTP id b139so54019qkc.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 09 Apr 2021 04:39:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=bmEIGOBF18rOlzme22ZjsM06FOuC7IiciN0m6R2zbpw=;
 b=DUsdQyeRY82v8soJV/Amuy2iUic7JVUgmtltdWeTihINov0niXg0Lq01Wb8VTMCILd
 rxm9MdPxYEqV0WfQjC/XKb/Ew6eonOIGMCLIEg84vMK5rIBIPaIHUB35BGwRUwXvGYD2
 axaxfqUeI/tksZYDffGA5iBEotbXaUe8LdiqLYX+FCO04eWIXabsGpGLdVwSnXJcnY0x
 6CIVkGEkbC9L4zpgVRCVNKolUQdJnRtdQBA0vWZPpwx8IGs/X8KtmwNC9F3wXzKsS8AH
 MxtiWKFGnJTOB/IsjC/HSp4C9rJvsKBfWHJ4ZiGhp/GKRZ7oVbiD8R2u0F2S8Qk8O0qG
 b1CQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=bmEIGOBF18rOlzme22ZjsM06FOuC7IiciN0m6R2zbpw=;
 b=mE7e+bxCePp6DlF4n9V5ODggLpzfyccGol7s/89cZY2Ln42FEG+4xJdtTHXa4TBIaR
 hh2nLIT3B8FkkCq6lgnbaUJlbWfvtiR8bYYv3DMsMLhK/QWySb9IQO8iU6SJVkj7gVUH
 lAC7tpR+RE8pdwlPdEvjECqroY6wxIn4zKUfLlfk1XG0I9I0lBW1ymhFJ/V5wNTs++OS
 RLkBefkdiVEvqxPSfg+i6HOJowJbVneRJ3AsyOBPMe4Jw/O0gFv6ItnLrxK9FTuq49of
 kKaR1Xc9hq1lEhKLLhvNiRbyVxxWG5r2A74egGDER1vn4r6pnkfF9bBDawvEbDBlF7En
 1C4Q==
X-Gm-Message-State: AOAM531y+zZywPKXfeIR7epb90c8iVfpnyfDkItcWZR6IXU2f5B1UVNO
 GZ183+rVAqtCSK/NlRqQVAeBSvpdIRL57nLndAQDuQ==
X-Google-Smtp-Source: ABdhPJxWvkXXy0dPNwbzn5EB2ByzuzTYPKBX4is27/ubRH2Auq+1ghg1K2AcMiJI3lvB87+EsvCEssGtfNmE8ja+5Sg=
X-Received: by 2002:ae9:e50c:: with SMTP id w12mr13079063qkf.13.1617968396922; 
 Fri, 09 Apr 2021 04:39:56 -0700 (PDT)
MIME-Version: 1.0
References: <5B6756D0-6BEF-4A01-BDB8-52C646916E29@friedenbach.org>
 <C623794E-F061-4C7A-B05D-378798ED2BF7@friedenbach.org>
 <201709190309.08669.luke@dashjr.org>
 <CAA2B000-6C54-4AD7-B931-43C99D615A61@friedenbach.org>
 <CAKzdR-phAarTY16BOnC95BPN0qMNEE_XZ9H-XmFeeaBc2V1U5w@mail.gmail.com>
 <3385CE20-C1BA-40DD-8FC3-8F53F3350717@friedenbach.org>
 <CAKzdR-pnvystx5H+P+OCXm73aVmWdyesCymerSgx=pCuXx+YGA@mail.gmail.com>
 <9FD4AF03-28A5-4B8A-9C12-CBCB1BC2E22C@friedenbach.org>
 <CAKzdR-r6u4J+_T5X516A=-tLWZ8zFFFsRokReiJndDE_S64OqQ@mail.gmail.com>
 <CAPg+sBi+WnzpJkcG6XACdpqqz9ZA3rHX8+H9b5eExUdgXaeiWQ@mail.gmail.com>
 <CAJowKg+kbnExgKt7H8GD6Kc-iLJEOvZhtw0uVbophhLCszvOHg@mail.gmail.com>
In-Reply-To: <CAJowKg+kbnExgKt7H8GD6Kc-iLJEOvZhtw0uVbophhLCszvOHg@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Fri, 9 Apr 2021 07:39:45 -0400
Message-ID: <CAMZUoKmQyV67dhWS_+t1CmqNYT490_7g3WwKgxB-jiYfje+F+Q@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000008e839205bf889f5b"
Subject: Re: [bitcoin-dev] maximum block height on transaction
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Apr 2021 11:39:59 -0000

--0000000000008e839205bf889f5b
Content-Type: text/plain; charset="UTF-8"

From https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119:

We can't safely do OP_BLOCKNUMBER.  In the event of a block chain reorg
> after a segmentation, transactions need to be able to get into the chain in
> a later block.  The OP_BLOCKNUMBER transaction and all its dependants would
> become invalid.  This wouldn't be fair to later owners of the coins who
> weren't involved in the time limited transaction.
>
> nTimeLock does the reverse.  It's an open transaction that can be replaced
> with new versions until the deadline.  It can't be recorded until it
> locks.  The highest version when the deadline hits gets recorded.  It could
> be used, for example, to write an escrow transaction that will
> automatically permanently lock and go through unless it is revoked before
> the deadline.  The feature isn't enabled or used yet, but the support is
> there so it could be implemented later.
>

Unfortunately, limiting the maximum block height for a specific transaction
would have exactly the same problem as cited above for OP_BLOCKNUMBER.

On Fri, Apr 9, 2021 at 7:21 AM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> is there any way to specify a maximum block height on a transaction?
>
> ie: this tx is only valid if included in a block with a certain height or
> less
>
> i feel like this would be useful
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000008e839205bf889f5b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>From <a href=3D"https://bitcointalk.org/index.php?top=
ic=3D1786.msg22119#msg22119">https://bitcointalk.org/index.php?topic=3D1786=
.msg22119#msg22119</a>:</div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div>We can&#39;t safely do OP_BLOCKNUMBER.=C2=A0 In the=
 event of a block chain reorg after a segmentation, transactions need to be=
 able to get into the chain in a later block.=C2=A0 The OP_BLOCKNUMBER tran=
saction and all its dependants would become invalid.=C2=A0 This wouldn&#39;=
t be fair to later owners of the coins who weren&#39;t involved in the time=
 limited transaction.<br><br>nTimeLock does the reverse.=C2=A0 It&#39;s an =
open transaction that can be replaced with new versions until the deadline.=
=C2=A0 It can&#39;t be recorded until it locks.=C2=A0 The highest version w=
hen the deadline hits gets recorded.=C2=A0 It could be used, for example, t=
o write an escrow transaction that will automatically permanently lock and =
go through unless it is revoked before the deadline.=C2=A0 The feature isn&=
#39;t enabled or used yet, but the support is there so it could be implemen=
ted later.</div></blockquote><div><br></div><div>Unfortunately, limiting th=
e maximum block height for a specific transaction would have exactly the sa=
me problem as cited above for OP_BLOCKNUMBER.<br></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 9, 2021 at 7:2=
1 AM Erik Aronesty via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex">is there any way =
to specify a maximum block height on a transaction?<br>
<br>
ie: this tx is only valid if included in a block with a certain height or l=
ess<br>
<br>
i feel like this would be useful<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--0000000000008e839205bf889f5b--