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,
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
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 C
An interesting concept occurred to me today while chatting with Nic Carter.
If we set Bitcoin Core up to gossip headers for work shares (e.g., expected
500 headers per block would have 20kb overhead, assuming we don't need to
send the prev hash) we'd be able to have more accurate finality estimate
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
fr
> I was thinking that this would be a separate blockchain with separate headers
> that progress linearly like a normal blockchain.
Exactly, that's what I called "superblocks", where you have a separate chain,
just to keep block headers instead of transactions.
> A block creator would collect toge
