[Bitcoin Advent Calendar] Oracles, Bonds, and Attestation Chains

[Bitcoin Advent Calendar] Oracles, Bonds, and Attestation Chains
2021-12-18  1:00 ` ZmnSCPxj
  
From: Jeremy @ 2021-12-17 18:24 UTC (permalink / raw)
  To: Bitcoin development mailing list

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

Today's post is pretty cool: it details how covenants like CTV can be used
to improve on-chain bitcoin signing oracles by solving the timeout/rollover
issue and solving the miner/oracle collusion issue on punishment. This
issue is similar to the Blockstream Liquid Custody Federation rollover bug
from a while back (which this type of design also helps to fix).

https://rubin.io/bitcoin/2021/12/17/advent-20/

It also describes:
- how a protocol on top can make 'branch free' attestation chains where if
you equivocate your funds get burned.
- lightly, various uses for these chained attestations

In addition, Robin Linus has a great whitepaper he put out getting much
more in the weeds on the concepts described in the post, it's linked in the
first bit of the post.

cheers,

Jeremy

--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

[-- Attachment #2: Type: text/html, Size: 2596 bytes --]

 permalink raw reply	[|nested]
2021-12-17 18:24 [bitcoin-dev] [Bitcoin Advent Calendar] Oracles, Bonds, and Attestation Chains Jeremy

  2021-12-18  2:00   ` Jeremy
  
From: ZmnSCPxj @ 2021-12-18  1:00 UTC (permalink / raw)
  To: Jeremy, Bitcoin Protocol Discussion

Good morning Jeremy,

> Today's post is pretty cool: it details how covenants like CTV can be used to improve on-chain bitcoin signing oracles by solving the timeout/rollover issue and solving the miner/oracle collusion issue on punishment. This issue is similar to the Blockstream Liquid Custody Federation rollover bug from a while back (which this type of design also helps to fix).
>
> https://rubin.io/bitcoin/2021/12/17/advent-20/
>
> It also describes:
> - how a protocol on top can make 'branch free' attestation chains where if you equivocate your funds get burned.
> - lightly, various uses for these chained attestations
>
> In addition, Robin Linus has a great whitepaper he put out getting much more in the weeds on the concepts described in the post, it's linked in the first bit of the post.

Nice, bonds are significantly better if you can ensure that the bonder cannot recover their funds.
Without a covenant the best you could do would be to have the bonder risk loss of funds on equivocation, not have the bonder actually definitely lose funds.

We should note that "equivocate" is not "lie".
An oracle can still lie, it just needs to consistently lie (i.e. not equivocate).

As an example, if the oracle is a signer for a federated sidechain, it could still sign an invalid sidechain block that inflates the sidecoin supply.
It is simply prevented from later denying this by signing an alternative valid sidechain block and acting as if it never signed the invalid sidechain block.
But if it sticks to its guns, then the sidechain simply stops operation with everyone owning sidecoins losing their funds (and if the oracle already exited the sidechain, its bond remains safe, as it did not equivocate, it only lied).

Regards,
ZmnSCPxj


 permalink raw reply	[|nested]
2021-12-18  1:00 ` ZmnSCPxj

  2021-12-18  3:49     ` ZmnSCPxj
  
From: Jeremy @ 2021-12-18  2:00 UTC (permalink / raw)
  To: ZmnSCPxj;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

Yep, these are great points. There is no way to punish signing the wrong
thing directly, just not changing your answers without risk to funds.

One of the interesting things is that upon a single equivocation you get
unbounded equivocation by 3rd parties, e.g., you can completely rewrite the
entire signature chain!

Another interesting point: if you use a musig key for your staking key that
is musig(a,b,c) you can sign with a until you equivocate once, then switch
to b, then c. Three strikes and you're out! IDK what that could be used for.

Lastly, while you can't punish lying, you could say "only the stakers who
sign with the majority get allocated reward tokens for that slot". So you
could equivocate to switch and get tokens, but you'd burn your collateral
for them. But this does make an incentive for the stakers to try to sign
the "correct" statement in line with peers.

[-- Attachment #2: Type: text/html, Size: 1625 bytes --]

 permalink raw reply	[|nested]
2021-12-18  2:00   ` Jeremy

  
From: ZmnSCPxj @ 2021-12-18  3:49 UTC ( / )
  To: Jeremy;  Bitcoin Protocol Discussion

Good morning Jeremy,


> Another interesting point: if you use a musig key for your staking key that is musig(a,b,c) you can sign with a until you equivocate once, then switch to b, then c. Three strikes and you're out! IDK what that could be used for.

You could say "oops, I made a mistake, can I correct it by equivocating just this time?".
Three strikes and you are out.

> Lastly, while you can't punish lying, you could say "only the stakers who sign with the majority get allocated reward tokens for that slot". So you could equivocate to switch and get tokens, but you'd burn your collateral for them. But this does make an incentive for the stakers to try to sign the "correct" statement in line with peers.

Note the quote marks around "correct" --- the majority of peers could be conspiring to lie, too.
Conspiracy theory time.....

Regards,
ZmnSCPxj