Re: [bitcoin-dev] [Bitcoin Advent Calendar] Oracles, Bonds, and Attestation Chains

[ZmnSCPxj via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Oracles, Bonds, and Attestation Chains

[Jeremy via bitcoin-dev]

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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Oracles, Bonds, and Attestation Chains

[ZmnSCPxj via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] [Bitcoin Advent Calendar] Oracles, Bonds, and Attestation Chains

[Jeremy via bitcoin-dev]

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 

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev