darosior [ARCHIVE] on Nostr: 📅 Original date posted:2022-03-21 📝 Original message:Hi ZmnSCPxj, Thanks for ...
📅 Original date posted:2022-03-21
📝 Original message:Hi ZmnSCPxj,
Thanks for the feedback. The DLC idea is interesting but you are centralizing the liveness requirements,
effectively creating a SPOF: in order to bypass the revocation clause no need to make sure to down each and
every watchtower anymore, just down the oracle and you are sure no revocation 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 the monitors) where they would sign
the right fee level at broadcast time. Pre-signing makes it quickly too many 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 corrupted 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 à 12:29 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> 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 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 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 corrupted 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 some particular future block height.
>
> Ostensibly, the scalar it publishes is the one of the point that corresponds 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 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 reveals a privkey of the DLC oracle, which should be usable for slashing some bond 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 published.
>
> 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 fixed 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
📝 Original message:Hi ZmnSCPxj,
Thanks for the feedback. The DLC idea is interesting but you are centralizing the liveness requirements,
effectively creating a SPOF: in order to bypass the revocation clause no need to make sure to down each and
every watchtower anymore, just down the oracle and you are sure no revocation 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 the monitors) where they would sign
the right fee level at broadcast time. Pre-signing makes it quickly too many 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 corrupted 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 à 12:29 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> 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 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 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 corrupted 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 some particular future block height.
>
> Ostensibly, the scalar it publishes is the one of the point that corresponds 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 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 reveals a privkey of the DLC oracle, which should be usable for slashing some bond 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 published.
>
> 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 fixed 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