Date: Wed, 16 Mar 2022 23:29:42 +0000
To: darosior <darosior@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <8Mc_c0hIjnY5JmWk7h9ttnnXF5NqBTKIDtFBIqZ7kg3J444fZrcG25UZvSkG4aeB0ZXGmSmZQHotwKonP1FL_lW3y2_bj7DJJPDM8M8r60s=@protonmail.com>
In-Reply-To: <QxjbW0yY5p2jfkNl4n9eMIu1tlsX_A9rmFaQa89Th4Dmca30q6q7GtM1Sm-ZRM61YeWwPSIfGs3EKix-rBIM7Ii80kj437HXBrPcg8Qdb9Q=@protonmail.com>
References: <Udzkz8ZPM4na6yNcGnINLCskodTve66hhpoXevwYuVVgfWfbJnLH70Btmp_dmvk8X8sNXqywBVviG3OzFzeoXQanPb8KkWNGjKG2mxxDsAo=@protonmail.com>
 <CAD5xwhgoxMnGpwn=4Ww_ZWP+ViZabvcxUV_n5=sXFdCwSe6-Mw@mail.gmail.com>
 <QxjbW0yY5p2jfkNl4n9eMIu1tlsX_A9rmFaQa89Th4Dmca30q6q7GtM1Sm-ZRM61YeWwPSIfGs3EKix-rBIM7Ii80kj437HXBrPcg8Qdb9Q=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Covenants and feebumping
Precedence: list

Good morning Antoine,

> For "hot contracts" a signature challenge is used to achieve the same. I =
know the latter is imperfect, since
> the lower the uptime risk (increase the number of network monitors) the h=
igher the DOS risk (as you duplicate
> the key).. That's why i asked if anybody had some thoughts about this and=
 if there was a cleverer way of doing
> it.

Okay, let me see if I understand your concern correctly.

When using a signature challenge, the concern is that you need to presign m=
ultiple versions of a transaction with varying feerates.

And you have a set of network monitors / watchtowers that are supposed to w=
atch the chain on your behalf in case your ISP suddenly hates you for no re=
ason.

The more monitors there are, the more likely that one of them will be corru=
pted by a miner and jump to the highest-feerate version, overpaying fees an=
d making miners very happy.
Such is third-party trust.

Is my understanding correct?


A cleverer way, which requires consolidating (but is unable to eliminate) t=
hird-party trust, would be to use a DLC oracle.
The DLC oracle provides a set of points corresponding to a set of feerate r=
anges, and commits to publishing the scalar of one of those points at some =
particular future block height.
Ostensibly, the scalar it publishes is the one of the point that correspond=
s to the feerate range found at that future block height.

You then create adaptor signatures for each feerate version, corresponding =
to the feerate ranges the DLC oracle could eventually publish.
The adaptor signatures can only be completed if the DLC oracle publishes th=
e corresponding scalar for that feerate range.

You can then send the adaptor signatures to multiple watchtowers, who can o=
nly publish one of the feerate versions, unless the DLC oracle is hacked an=
d publishes multiple scalars (at which point the DLC oracle protocol reveal=
s a privkey of the DLC oracle, which should be usable for slashing some bon=
d of the DLC oracle).
This prevents any of them from publishing the highest-feerate version, as t=
he adaptor signature cannot be completed unless that is what the oracle pub=
lished.

There are still drawbacks:

* Third-party trust risk: the oracle can still lie.
  * DLC oracles are prevented from publishing multiple scalars; they cannot=
 be prevented from publishing a single wrong scalar.
* DLCs must be time bound.
  * DLC oracles commit to publishing a particular point at a particular fix=
ed time.
  * For "hot" dynamic protocols, you need the ability to invoke the oracle =
at any time, not a particular fixed time.

The latter probably makes this unusable for hot protocols anyway, so maybe =
not so clever.

Regards,
ZmnSCPxj