Date: Mon, 03 May 2021 02:30:07 +0000
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <y8kJCDDh8iJOVjnbBFCxPuMLz2yBxNF2kW_DuxIaC3OyMNSxNm_e3rZVKUR9aWpoq6xmRBSBuPU9lAF30eQXMsmFrP8ycSMxqi7LVJXeJ3A=@protonmail.com>
In-Reply-To: <3mg9xnvKEhrXuQ5QriYQcLKmrhdYpO0hlxyRpJwZJZInyHCtva208PTZlIxglcq4afO8ftTFRBjRfG0ZEVPvIqxMJhHnFYpnPYTo_mp3qA0=@protonmail.com>
References: <5B6756D0-6BEF-4A01-BDB8-52C646916E29@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>
 <CAGpPWDZHKJ8BvD3TqrvP=5pxbAc0ez-ikJmO6a51WDad1xuLSw@mail.gmail.com>
 <3mg9xnvKEhrXuQ5QriYQcLKmrhdYpO0hlxyRpJwZJZInyHCtva208PTZlIxglcq4afO8ftTFRBjRfG0ZEVPvIqxMJhHnFYpnPYTo_mp3qA0=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Billy Tetrud <billy.tetrud@gmail.com>
Subject: Re: [bitcoin-dev] maximum block height on transaction
Precedence: list

Good morning Billy, and list,

> -   Using an opcode would greatly increase CPU usage because the script c=
ache would need to be reworked (and probably cannot be made to work).
> -   Adding a field would greatly increase the code complexity to the leve=
l of SegWit, without all the important bugfixes+features (tx malleability, =
quadratic sighash, well-defined extensible outputs) that SegWit provides.

Sometimes, the only way out is through.

A general idea to get around this would be:

* Define a "hidden" field of a transaction, which is not existent in *any* =
serialization of the transaction.
* Set a default value for this field that would be compatible with pre-soft=
fork rules.
* Have an opcode that manipulates this field, carefully designed so it is i=
dempotent.

The above general idea is not original to me, I believe.
I think I have seen it elsewhere on the list, possibly in discussions aroun=
d sidechains, though my primary cache is unable to fetch and additional sea=
rches through unindexed storage is taking too long.

So, for this particular case, here is a (non-serious) proposal to implement=
 a maximum block height on transactions.

* Create a new field `u32 nMaxHeight` on `CTransaction` that is not seriali=
zed in any transaction format.
  * A block is not valid if any transaction in it has an `nMaxHeight` large=
r than the block height of the block.
  * Default value is `0xFFFFFFFF`.
* Add a new opcode `OP_SETMAXHEIGHT` that replaces an existing `OP_NOP`.
  * The opcode must be followed by an `OP_PUSH` of a 32-bit value, else scr=
ipt validation fails.
    * This prevents using a computed value, instead the value must be given=
 as a constant in the script text.
      This is a precaution to reduce the risk that execution of the script =
at a different time or different computer or etc will result in a different=
 value that the `OP_SETMAXHEIGHT` opcode uses, which can cause consensus di=
vergence.
      If we figure out later that this precaution is not necessary, we can =
just use another `OP_NOP` for `OP_SETMAXHEIGHTFROMSTACK`.
  * If the current `nMaxHeight` is larger than the given value, then the `n=
MaxHeight` is set to the given value.

The above avoids issues with opcodes --- the script interpreter can continu=
e to be executed in the only place it is in, i.e. at entry into the mempool=
.
It also avoids some of the code complexity with fields, since the field is =
non-existent in any serialization of the transaction, but is instead implie=
d by the scripts that the transaction causes to be executed, reducing the n=
eed to identify pre-softfork peers and baby-talk to them --- the baby-talk =
simply contains "parental bonuses" that are understood by upgraded nodes wh=
o are "in the know".

Additional complications, such as the need for an index of `nMaxHeight` for=
 transactions in the mempool (to remove transactions whose `nMaxHeight` is =
now in the past), and the additional checks needed when receiving an in-blo=
ck transaction that is not in the mempool, are left to the reader.
Similar field and opcode for `CTransactionInput` for a relative-time max he=
ight are also left as an exercise to the reader.

> -   You can do what you want with a second `nLockTime`d transaction that =
spends the output anyway.

The advantage of this functionality is that you can be safely offline at th=
e time the timeout occurs in any complicated timeout-based contract.

Typically, when using say an HTLC, the contractor who holds lien on the tim=
elock branch, has to be online at the time the timelock becomes valid, in o=
rder to impose a timeout on the hashlock branch.
However, if instead the hashlock branch includes an `OP_SETMAXHEIGHT`, then=
 the contractor holding lien on the timelock branch does not have this risk=
.

However, the contractor holding the lien on the hashlock branch now has inc=
reased risk.
If the timeout is approaching, and suddenly there is high mempool usage at =
the time, then a claim of the hashlock branch may fall off the mempool due =
to `nMaxHeight` violation.
But the transaction claiming the hashlock branch has been published and the=
 preimage has been published in mempools all over the world, thus the contr=
actor holding lien on the hashlock branch risks not being compensated for r=
evelation of the preimage.

Whereas with the current way things are, the timelock-holder is at risk, an=
d the hashlock-holder has reduced risk since even if the timeout arrives, t=
here is still the possibility that the hashlock branch is what gets confirm=
ed, whereas with `OP_SETMAXHEIGHT` the hashlock-holder has 0 chance of gett=
ing the hashlock branch confirmed in case of sudden spike in onchain usaage=
.

Thus it seems to me that this scheme does not really *improve* Bitcoin sign=
ificantly, it only moves risks from one participant to another in a two-par=
ticipant contract.
Thus, this proposal is not particularly serious.

Regards,
ZmnSCPxj