Date: Tue, 23 Jun 2020 09:48:27 +0000
To: Stanga <stanga@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <ahTHfoyyTpBrMiKdJWMn9Qa8CMCEd1-y8OXPSjsDmttTOVC3zGuDoSHkm_oOe5mBYgIAY7jOPocQhLW29n544xFsqVyq51NFApvaFYYSvFY=@protonmail.com>
In-Reply-To: <CABT1wW=KWtoo6zHs8=yUQ7vAYcFSdAzdpDJ9yfw6sJrLd6dN5A@mail.gmail.com>
References: <CABT1wW=X35HRVGuP-BHUhDrkBEw27+-iDkNnHWjRU-1mRkn0JQ@mail.gmail.com>
 <CABT1wW=KWtoo6zHs8=yUQ7vAYcFSdAzdpDJ9yfw6sJrLd6dN5A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Matan Yehieli <matany@campus.technion.ac.il>,
 Itay Tsabary <sitay@campus.technion.ac.il>
Subject: Re: [bitcoin-dev] MAD-HTLC
Precedence: list

Good morning Itay, Ittay, and Matan,

I believe an unstated assumption in Bitcoin is that miners are short-sighte=
d.

The reasoning for this assumption is:

* Deployment of new mining hardware controlled by others may occur at any t=
ime you do not control.
  * Thus, any transactions you leave on the table are potentially taken by =
somebody else and not by you.
  * Sudden changes in hashpower distribution may reduce your expected futur=
e earnings, so any future theoretical earnings should be discounted (*in ad=
dition to* expected return-on-investment on getting money you can invest *n=
ow*).

It also strikes me that, in a world with RBF and CPFP, the same endpoint (i=
.e. miners earn the entire fund of the HTLC) is achieved by existing HTLCs,=
 without the additional branch and script opcodes needed by MAD-HTLC.
For example, if an HTLC is confirmed but the hashlock-claiming transaction =
is not being confirmed (because miners are holding it up because Bob is off=
ering a much higher fee in the future for the timelock-claiming transaction=
), then Alice can, regardless of the reason why it is not being confirmed, =
bump up the fee with RBF or CPFP.

If the fee bump offered by Alice is sufficiently large, then miners will st=
art re-preferring the Alice hashlock transaction.
To counter this, Bob has to bid up its version higher.

As the timeout approaches, Alice can bump up its fee until it is just 1 sat=
oshi short of the total fund.
It is rational for Alice to do so since at timeout, it can expect to lose t=
he entire fund.
In order for Bob to win, it has to beat that fee, at which point it equals =
or exceeds the total fund, and miners get the total fund (or more).

Knowing this end-point, rational Bob will not even begin this game.

I think this research considers these two endpoints to be distinct:

* Bob misbehaves and the entire fund is punished by miners, leaving miners =
with the fund and Alice and Bob without money (MAD-HTLC).
* Bob misbehaves, Alice counters, and the ensuing fee war leads to fees app=
roaching the fund value, leaving miners with the fund and Alice and Bob wit=
hout money (standard HTLC).

But in practice I think both endpoints are essentially equivalent.

--

What MAD-HTLC can do would be to make different claims:

* Inputs:
  * Bob 1 BTC - HTLC amount
  * Bob 1 BTC - Bob fidelity bond

* Cases:
  * Alice reveals hashlock at any time:
    * 1 BTC goes to Alice
    * 1 BTC goes to Bob (fidelity bond refund)
  * Bob reveals bob-hashlock after time L:
    * 2 BTC goes to Bob (HTLC refund + fidelity bond refund)
  * Bob cheated, anybody reveals both hashlock and bob-hashlock:
    * 2 BTC goes to miner

This is an actual improvement over HTLC: Bob misbehavior leads to loss of t=
he fidelity bond.
The above cases can be assured by requiring both Alice and Bob to sign in t=
he alice-hashlock branch, so that the splitting of the fund is enforced, an=
d SegWit signing so that the dependent transaction is signed before the HTL=
C-funding transaction is.
It can also be implemented with `OP_CHECKTEMPLATEVERIFY`.

Regards,
ZmnSCPxj