Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6CAB3C000A for ; Fri, 9 Apr 2021 15:54:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 4DC6983F11 for ; Fri, 9 Apr 2021 15:54:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2r5H2SEECqGb for ; Fri, 9 Apr 2021 15:54:54 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp1.osuosl.org (Postfix) with ESMTPS id 20A7583F0C for ; Fri, 9 Apr 2021 15:54:53 +0000 (UTC) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 139Fsq2R027092 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 9 Apr 2021 11:54:52 -0400 Received: by mail-io1-f44.google.com with SMTP id x16so6410511iob.1 for ; Fri, 09 Apr 2021 08:54:52 -0700 (PDT) X-Gm-Message-State: AOAM531prRnp/0TqMShJgwpuCT62i37pJ5qIxDvi83QmA7RsLD48Dff1 J/jbXVWOmiy0JQ+ARe9tK48YQu6geuXkO23bD9U= X-Google-Smtp-Source: ABdhPJxXaJE8fxCPJQdyc/gBXMRXD0y5JJnY0T6tr350XjNB9V/c9Cxg9qT8mfz7KxzvSDIiz4Tiqp0Vxh4wIwTVkic= X-Received: by 2002:a02:cba7:: with SMTP id v7mr12670790jap.123.1617983691937; Fri, 09 Apr 2021 08:54:51 -0700 (PDT) MIME-Version: 1.0 References: <5B6756D0-6BEF-4A01-BDB8-52C646916E29@friedenbach.org> <201709190309.08669.luke@dashjr.org> <3385CE20-C1BA-40DD-8FC3-8F53F3350717@friedenbach.org> <9FD4AF03-28A5-4B8A-9C12-CBCB1BC2E22C@friedenbach.org> In-Reply-To: From: Jeremy Date: Fri, 9 Apr 2021 08:54:39 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "Russell O'Connor" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000035e16c05bf8c2f8e" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 15:54:55 -0000 --00000000000035e16c05bf8c2f8e Content-Type: text/plain; charset="UTF-8" You could accomplish your rough goal by having: tx A: desired expiry at H tx B: nlocktime H, use same inputs as A, create outputs equivalent to inputs (have to be sure no relative timelocks) Thus after a timeout the participants in A can cancel the action using TX B. The difference is the coins have to move, without knowing your use case this may or may not help you. On Fri, Apr 9, 2021, 4:40 AM Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000035e16c05bf8c2f8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You could accomplish your rough goal by having:



tx A: desired expiry at H
tx B: n= locktime H, use same inputs as A, create outputs equivalent to inputs (have= to be sure no relative timelocks)

Thus after a timeout the participants in A can cancel the action= using TX B.

The differe= nce is the coins have to move, without knowing your use case this may or ma= y not help you.=C2=A0

On Fri, Apr 9, 2021, 4:40 AM Russell O'Conno= r via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

We can't safely do OP_BLOCKNUMBER.=C2=A0 In the event of a bloc= k chain reorg after a segmentation, transactions need to be able to get int= o the chain in a later block.=C2=A0 The OP_BLOCKNUMBER transaction and all = its dependants would become invalid.=C2=A0 This wouldn't be fair to lat= er owners of the coins who weren't involved in the time limited transac= tion.

nTimeLock does the reverse.=C2=A0 It's an open transaction= that can be replaced with new versions until the deadline.=C2=A0 It can= 9;t be recorded until it locks.=C2=A0 The highest version when the deadline= hits gets recorded.=C2=A0 It could be used, for example, to write an escro= w transaction that will automatically permanently lock and go through unles= s it is revoked before the deadline.=C2=A0 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 ci= ted above for OP_BLOCKNUMBER.

On Fri, Apr 9, 2021 at 7:21 AM Erik Arones= ty 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 l= ess

i feel like this would be useful
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--00000000000035e16c05bf8c2f8e--