Re: [bitcoin-dev] maximum block height on transaction

[Billy Tetrud <billy.tetrud@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4328 bytes --]

@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
>

[-- Attachment #2: Type: text/html, Size: 6485 bytes --]