From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: darosior <darosior@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Covenants and feebumping
Date: Wed, 16 Mar 2022 23:29:42 +0000 [thread overview]
Message-ID: <8Mc_c0hIjnY5JmWk7h9ttnnXF5NqBTKIDtFBIqZ7kg3J444fZrcG25UZvSkG4aeB0ZXGmSmZQHotwKonP1FL_lW3y2_bj7DJJPDM8M8r60s=@protonmail.com> (raw)
In-Reply-To: <QxjbW0yY5p2jfkNl4n9eMIu1tlsX_A9rmFaQa89Th4Dmca30q6q7GtM1Sm-ZRM61YeWwPSIfGs3EKix-rBIM7Ii80kj437HXBrPcg8Qdb9Q=@protonmail.com>
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
next prev parent reply other threads:[~2022-03-16 23:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-12 18:08 darosior
2022-03-13 2:33 ` Jeremy Rubin
2022-03-14 14:49 ` darosior
2022-03-16 23:29 ` ZmnSCPxj [this message]
2022-03-21 12:06 ` darosior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='8Mc_c0hIjnY5JmWk7h9ttnnXF5NqBTKIDtFBIqZ7kg3J444fZrcG25UZvSkG4aeB0ZXGmSmZQHotwKonP1FL_lW3y2_bj7DJJPDM8M8r60s=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=darosior@protonmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox