Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 89C67C000A for ; Mon, 12 Apr 2021 20:05:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 788DF40549 for ; Mon, 12 Apr 2021 20:05:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 jzjMXLqRqeUu for ; Mon, 12 Apr 2021 20:05:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by smtp4.osuosl.org (Postfix) with ESMTPS id C8D09404ED for ; Mon, 12 Apr 2021 20:05:09 +0000 (UTC) Received: by mail-ed1-x535.google.com with SMTP id bx20so15405342edb.12 for ; Mon, 12 Apr 2021 13:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qvmgIRVqiX4exhTgsRvOAbe5mMga/mGVrO+Z5TwuV/w=; b=TlvGsRHAf7NBD89c7MdGkwkpVSkk9dQ30oqypcFrGpfIqPGXxTtHblqo3GoJIH8HCY XLInvmHEcAOxe4eEnp2XVyHi+Zunk7b3uSXmdYE6RZPoZfK7NAJJsVKt1D9lFpgWrYJa Q8hllyzZJj+FMqoS+dQeqDop2eOSgm0/kDMFLa7MxDZIngAktRPB/s6Jqa18uMFJMi+u w/l7+7KUztzuRktyvDKjifK5FEPPvGrKhAT2pB7pVgBIZ6EvGAhe6ARyxyztdh1oJlnR UZbmEIbJqDV1q5Xcdsdl8b4Gtjcrmb7tFxq5LbcQjhwcmbOSFrkRTNOnSKVTjpAvWH4P AUqQ== 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:cc; bh=qvmgIRVqiX4exhTgsRvOAbe5mMga/mGVrO+Z5TwuV/w=; b=tGocuH0HhDH/7YyFOyUrlmyfxg3TJ1bKibSb2AstLe5ZswNTbKaR4LVe/5ZyB+Znoe DHkMdTY1wxgOhCdjh+kLz8QeI4dnG9XzhIfW49hSXJ31+NidpCHDBTiDjnxxvxlHjPtc nVztMFMkuhV4Pcq3HMwtXiv+tGgGfAuDL7/FWzeipDAJqgEXbZbrqTfQwfgWF1yhftPs Z0rAouHbsq6WAmTgZWVwJwyNt4Rx1NmVVw9taPJDiGhoZZgQUayNA+gCTHSDPdGLT2je w5lQj0iilcxVGZRJ0ccX+BRj4/7TBkREFpIdvegQbsMEyax39q3r+gGyelaV/6aPIKZl CAhg== X-Gm-Message-State: AOAM532fJ3ujxziFJcwYtbqdXv2c8ZZlUgp5kKa5zcw0MuZEE4aMORg0 GGvMKZN5bOaVxi4ITqJHuL9FYmwwzlQ0p2KeaRU= X-Google-Smtp-Source: ABdhPJwT2dBX1iPQ5TX/dzxsuYovnqKGN5SIJMuYAGWQCtA2mJKMb5grp2lR75mLBlGWz2uNrFqq1XvXxh9vafHMWbk= X-Received: by 2002:a05:6402:68a:: with SMTP id f10mr30834411edy.26.1618257907924; Mon, 12 Apr 2021 13:05:07 -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: Billy Tetrud Date: Mon, 12 Apr 2021 10:04:51 -1000 Message-ID: To: Jeremy , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000c1c1ec05bfcc079a" X-Mailman-Approved-At: Mon, 12 Apr 2021 20:33:40 +0000 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: Mon, 12 Apr 2021 20:05:11 -0000 --000000000000c1c1ec05bfcc079a Content-Type: text/plain; charset="UTF-8" @Russell I think there were sound arguments against Satoshi's statement made in that very thread. Especially that software can be written to warn the user about edge cases. If a person waited for the standard 6 blocks before accepting a transaction as confirmed, there should be no significantly likely scenario where any finalized transaction needs to be reverted. If 6 blocks is indeed a safe threshold for finalization, then any transaction that has 5 or fewer confirmations should be considered fair game for reversal. I don't agree that this is "unfair". In fact, I think that's pretty standard, is it not? Any chain of transactions that happen in the span of 5 blocks shouldn't be doing anything that expects those transactions to become finalized until the relevant transactions get 6 confirmations. I don't think the possibility of buggy software is a good reason to block an opcode. Not that I'm hankering for OP_BLOCKNUMBER specifically. However, I think there are good use cases for spend paths that expire (eg for more effective wallet vaults). I've come across this argument before, and it seems kind of like Satoshi's word here is held as gospel. I haven't heard any deep discussion of this topic, and I even asked a question on the bitcoin SE about it. Sorry to hijack this conversation, but I'm very curious if there's something more to this or if the thinking was simply decided that OP_BLOCKNUMBER wasn't useful enough to warrant the (dubious) potential footgun of people accepting sub-6-block transactions from a transaction that uses an expired spend-path? On Fri, Apr 9, 2021 at 5:55 AM Jeremy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000c1c1ec05bfcc079a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
@Russell I think there were sound arguments against Satosh= i's statement made in that very thread. Especially that software can be= written to warn the user about edge cases.=C2=A0

If a person waite= d for the standard 6 blocks before accepting a transaction as confirmed, th= ere should be no significantly likely scenario where any finalized transact= ion needs to be reverted. If 6 blocks is indeed a safe threshold for finali= zation, then any transaction that has 5 or fewer confirmations should be co= nsidered fair game for reversal. I don't agree that this is "unfai= r". In fact, I think that's pretty standard, is it not? Any chain = of transactions that happen in the span of 5 blocks shouldn't be doing = anything that expects those transactions to become finalized until the rele= vant transactions get 6 confirmations.=C2=A0

I don= 't think the possibility of buggy software is a good reason to block an= opcode. Not that I'm hankering for OP_BLOCKNUMBER specifically. Howeve= r, I think there are good use cases for spend paths that expire (eg for mor= e effective wallet vaults).=C2=A0

I've come ac= ross this argument before, and it seems kind of like Satoshi's word her= e is held as gospel. I haven't heard any deep discussion of this topic,= and I even asked a question on the bitcoin SE about it. Sorry to hijack this c= onversation, but I'm very curious if there's something more to this= or if the thinking was simply decided that OP_BLOCKNUMBER wasn't usefu= l enough to warrant the (dubious) potential footgun of people accepting sub= -6-block transactions from a transaction that uses an expired spend-path?

On Fri, Apr 9, 2021 at 5:55 AM Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundati= on.org> wrote:
You could accomplish your rough goal by having:


<= /div>
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 ac= tion using TX B.

The dif= ference is the coins have to move, without knowing your use case this may o= r may not help you.=C2=A0

On Fri, Apr 9, 2021, 4:40 AM Russell O'C= onnor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wro= te:

We can'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 transaction and all its dependants would become inva= lid.=C2=A0 This wouldn't be fair to later owners of the coins who weren= 't involved in the time limited transaction.

nTimeLock does the = reverse.=C2=A0 It's an open transaction that can be replaced with new v= ersions until the deadline.=C2=A0 It can't be recorded until it locks.= =C2=A0 The highest version when the deadline hits gets recorded.=C2=A0 It c= ould be used, for example, to write an escrow transaction that will automat= ically permanently lock and go through unless it is revoked before the dead= line.=C2=A0 The feature isn't enabled or used yet, but the support is t= here so it could be implemented later.

Unfortunately, limiting the maximum block height for a specific transacti= on 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:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">is there any way to specif= y 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
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000c1c1ec05bfcc079a--