From: Jeremy <jlrubin@mit.edu>
To: "Russell O'Connor" <roconnor@blockstream.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] maximum block height on transaction
Date: Fri, 9 Apr 2021 08:54:39 -0700 [thread overview]
Message-ID: <CAD5xwhhZpQ9AQEFHgGYvPh2ad9HyQqq9WwEZje1H1siioB6eLQ@mail.gmail.com> (raw)
In-Reply-To: <CAMZUoKmQyV67dhWS_+t1CmqNYT490_7g3WwKgxB-jiYfje+F+Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2261 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 3822 bytes --]
next prev parent reply other threads:[~2021-04-09 15:54 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-07 0:38 [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST Mark Friedenbach
2017-09-08 9:21 ` Johnson Lau
2017-09-12 2:03 ` Mark Friedenbach
2017-09-12 2:13 ` Bryan Bishop
2017-09-12 8:55 ` Johnson Lau
2017-09-12 19:57 ` Mark Friedenbach
2017-09-12 23:27 ` Karl Johan Alm
2017-09-13 9:41 ` Peter Todd
2017-09-11 20:37 ` Adán Sánchez de Pedro Crespo
2017-09-19 0:46 ` Mark Friedenbach
2017-09-19 3:09 ` [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST) Luke Dashjr
2017-09-19 7:33 ` Mark Friedenbach
2017-09-22 20:32 ` Sergio Demian Lerner
2017-09-22 21:11 ` Mark Friedenbach
2017-09-22 21:32 ` Sergio Demian Lerner
2017-09-22 21:39 ` Mark Friedenbach
2017-09-22 21:54 ` Sergio Demian Lerner
2017-09-22 22:07 ` Mark Friedenbach
2017-09-22 22:09 ` Pieter Wuille
2021-04-09 8:15 ` [bitcoin-dev] maximum block height on transaction Erik Aronesty
2021-04-09 11:39 ` Russell O'Connor
2021-04-09 15:54 ` Jeremy [this message]
2021-04-12 20:04 ` Billy Tetrud
2021-04-16 4:24 ` ZmnSCPxj
2021-05-03 2:30 ` ZmnSCPxj
2017-09-20 5:13 ` [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST) Johnson Lau
2017-09-20 19:29 ` Mark Friedenbach
2017-09-21 3:58 ` Johnson Lau
2017-09-21 4:11 ` Luke Dashjr
2017-09-21 8:02 ` Johnson Lau
2017-09-21 16:33 ` Luke Dashjr
2017-09-21 17:38 ` Johnson Lau
2017-09-30 23:23 ` [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST Luke Dashjr
2017-09-30 23:51 ` Mark Friedenbach
2017-10-02 17:15 ` Russell O'Connor
2017-10-28 4:40 ` Mark Friedenbach
2017-11-01 8:43 ` Luke Dashjr
2017-11-01 15:08 ` Mark Friedenbach
2017-11-04 7:59 ` Luke Dashjr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAD5xwhhZpQ9AQEFHgGYvPh2ad9HyQqq9WwEZje1H1siioB6eLQ@mail.gmail.com \
--to=jlrubin@mit.edu \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=roconnor@blockstream.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox