1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id CD7E8C016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jun 2020 09:48:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id C0F432002F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jun 2020 09:48:38 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id VH4cTJn7m4zW
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jun 2020 09:48:36 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by silver.osuosl.org (Postfix) with ESMTPS id B53C71FEBF
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jun 2020 09:48:36 +0000 (UTC)
Date: Tue, 23 Jun 2020 09:48:27 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1592905714;
bh=Z8X4+7qZ/v2wOvwkkqTcXQj9T2886YTYwhuMXETdT6I=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=Y4y1OOe+0CHzJdlS9ZXio83cWNWRzn29WZ1UT+3HSRNpoSnuQOG5fRSnyjLYyais5
3HmizxB65pC5lXi7M0Rb07pvzIo+9peJ/ikgWQkM4MTalffRAh7DUrjYKtkI8hE5Rm
uhexDmGRPZY0bEiMAKl43WWHq4HTYDvR2++RbpiY=
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
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: Tue, 23 Jun 2020 09:48:38 -0000
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
|
