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

Hi ZmnSCPxj,

Thanks for the feedback. The DLC idea is interesting but you are centralizi=
ng the liveness requirements,
effectively creating a SPOF: in order to bypass the revocation clause no ne=
ed to make sure to down each and
every watchtower anymore, just down the oracle and you are sure no revocati=
on transaction can be pushed.


> Okay, let me see if I understand your concern correctly.
> When using a signature challenge, the concern is that you need to presign=
 multiple versions of a transaction with varying feerates.

I was thinking of having a hot key (in this case probably shared amongst th=
e monitors) where they would sign
the right fee level at broadcast time. Pre-signing makes it quickly too man=
y signatures (and kills the purpose
of having covenants in the first place).

> And you have a set of network monitors / watchtowers that are supposed to=
 watch the chain on your behalf in case your ISP suddenly hates you for no =
reason.
> The more monitors there are, the more likely that one of them will be cor=
rupted by a miner and jump to the highest-feerate version, overpaying fees =
and making miners very happy.
> Such is third-party trust.
> Is my understanding correct?

Your understanding of the tradeoff is correct.

------- Original Message -------

Le jeudi 17 mars 2022 =C3=A0 12:29 AM, ZmnSCPxj <ZmnSCPxj@protonmail.com> a=
 =C3=A9crit :

> 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=
 higher the DOS risk (as you duplicate
> >
> > the key).. That's why i asked if anybody had some thoughts about this a=
nd 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=
 multiple versions of a transaction with varying feerates.
>
> And you have a set of network monitors / watchtowers that are supposed to=
 watch the chain on your behalf in case your ISP suddenly hates you for no =
reason.
>
> The more monitors there are, the more likely that one of them will be cor=
rupted by a miner and jump to the highest-feerate version, overpaying fees =
and making miners very happy.
>
> Such is third-party trust.
>
> Is my understanding correct?
>
> A cleverer way, which requires consolidating (but is unable to eliminate)=
 third-party trust, would be to use a DLC oracle.
>
> The DLC oracle provides a set of points corresponding to a set of feerate=
 ranges, and commits to publishing the scalar of one of those points at som=
e particular future block height.
>
> Ostensibly, the scalar it publishes is the one of the point that correspo=
nds to the feerate range found at that future block height.
>
> You then create adaptor signatures for each feerate version, correspondin=
g to the feerate ranges the DLC oracle could eventually publish.
>
> The adaptor signatures can only be completed if the DLC oracle publishes =
the corresponding scalar for that feerate range.
>
> You can then send the adaptor signatures to multiple watchtowers, who can=
 only publish one of the feerate versions, unless the DLC oracle is hacked =
and publishes multiple scalars (at which point the DLC oracle protocol reve=
als a privkey of the DLC oracle, which should be usable for slashing some b=
ond of the DLC oracle).
>
> This prevents any of them from publishing the highest-feerate version, as=
 the adaptor signature cannot be completed unless that is what the oracle p=
ublished.
>
> 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 mayb=
e not so clever.
>
> Regards,
>
> ZmnSCPxj