path: root/77/d25dbab0203cf8c44dbd1cb10c3519f2a04106

Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 89C67C000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 12 Apr 2021 20:05:09 +0000 (UTC)
Received: by mail-ed1-x535.google.com with SMTP id bx20so15405342edb.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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>
 <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>
 <CAMZUoKmQyV67dhWS_+t1CmqNYT490_7g3WwKgxB-jiYfje+F+Q@mail.gmail.com>
 <CAD5xwhhZpQ9AQEFHgGYvPh2ad9HyQqq9WwEZje1H1siioB6eLQ@mail.gmail.com>
In-Reply-To: <CAD5xwhhZpQ9AQEFHgGYvPh2ad9HyQqq9WwEZje1H1siioB6eLQ@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Mon, 12 Apr 2021 10:04:51 -1000
Message-ID: <CAGpPWDZHKJ8BvD3TqrvP=5pxbAc0ez-ikJmO6a51WDad1xuLSw@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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
<https://bitcoin.stackexchange.com/questions/96366/what-are-the-reasons-to-avoid-spend-paths-that-become-invalid-over-time-without>
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

<div dir=3D"ltr">@Russell I think there were sound arguments against Satosh=
i&#39;s statement made in that very thread. Especially that software can be=
 written to warn the user about edge cases.=C2=A0<div><br>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&#39;t agree that this is &quot;unfai=
r&quot;. In fact, I think that&#39;s pretty standard, is it not? Any chain =
of transactions that happen in the span of 5 blocks shouldn&#39;t be doing =
anything that expects those transactions to become finalized until the rele=
vant transactions get 6 confirmations.=C2=A0</div><div><br></div><div>I don=
&#39;t think the possibility of buggy software is a good reason to block an=
 opcode. Not that I&#39;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</div><div><br></div><div>I&#39;ve come ac=
ross this argument before, and it seems kind of like Satoshi&#39;s word her=
e is held as gospel. I haven&#39;t heard any deep discussion of this topic,=
 and I even asked <a href=3D"https://bitcoin.stackexchange.com/questions/96=
366/what-are-the-reasons-to-avoid-spend-paths-that-become-invalid-over-time=
-without">a question on the bitcoin SE</a> about it. Sorry to hijack this c=
onversation, but I&#39;m very curious if there&#39;s something more to this=
 or if the thinking was simply decided that OP_BLOCKNUMBER wasn&#39;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?</=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Fri, Apr 9, 2021 at 5:55 AM Jeremy via bitcoin-dev &lt;<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundati=
on.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"auto">You could accomplish your rough goal by having:<div=
 dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">tx A: desired expiry at H</div><div dir=3D"auto">tx =
B: nlocktime H, use same inputs as A, create outputs equivalent to inputs (=
have to be sure no relative timelocks)</div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">Thus after a timeout the participants in A can cancel the ac=
tion using TX B.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The dif=
ference is the coins have to move, without knowing your use case this may o=
r may not help you.=C2=A0</div></div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr" class=3D"gmail_attr">On Fri, Apr 9, 2021, 4:40 AM Russell O&#39;C=
onnor via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wro=
te:<br></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"><div dir=3D"=
ltr"><div>From <a href=3D"https://bitcointalk.org/index.php?topic=3D1786.ms=
g22119#msg22119" rel=3D"noreferrer" target=3D"_blank">https://bitcointalk.o=
rg/index.php?topic=3D1786.msg22119#msg22119</a>:</div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px 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 transaction and all its dependants would become inva=
lid.=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 v=
ersions until the deadline.=C2=A0 It can&#39;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&#39;t enabled or used yet, but the support is t=
here so it could be implemented later.</div></blockquote><div><br></div><di=
v>Unfortunately, limiting the maximum block height for a specific transacti=
on would have exactly the same problem as cited above for OP_BLOCKNUMBER.<b=
r></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr=
">On Fri, Apr 9, 2021 at 7:21 AM Erik Aronesty via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><=
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?<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" rel=3D"noreferrer"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<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>

--000000000000c1c1ec05bfcc079a--