Good Morning Matt, It seems to me that double signing can be punished by requiring that R be a trivial function on the blockheight of the block being signed on the sidechain network. Then a validator who signs multiple versions of history at a particular blockheight reveals their privkey. Since the privkey also protects their Bitcoin stake UTXO, they risk loss of their Bitcoin stake. A similar idea is used by Discrete Log Contracts to ensure Oracles do not sign multiple values at a particular time.
Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Saturday, January 19, 2019 1:35 PM, Matt Bell <map...@gmail.com> wrote: > Hi ZmnSCPxj, > > Just to clarify, my design does not specify the source of voting power, so it > is agnostic to whatever system you want to derive stake or valdiator set > membership from. > > Your idea of timelocking Bitcoin is interesting, I am eager to find a > solution where holding Bitcoin is enough to get voting power. It's possible > there may be an issue with the fact that the Bitcoin is not slashable > (although their voting power is), meaning a validator who double-signs cannot > have their Bitcoin removed from them. However their UTXO can be blacklisted > which does make their attack costly since they lose out on the time-value of > their stake. > > Our current thinking for the source of stake is to pay out stake to Bitcoin > merged-miners although I'll definitely do some more thinking about timelocked > Bitcoin as stake. > > On Fri, Jan 18, 2019, 5:42 PM ZmnSCPxj <zmnsc...@protonmail.com wrote: > > > Good morning Matt, > > > > It seems to me much more interesting if the stakes used to weigh voting > > power are UTXOs on the Bitcoin blockchain. > > This idea is what I call "mainstake"; rather than a blockchain having its > > own token that is self-attesting (which is insecure). > > It seems to me, naively, that the same script you propose here can be used > > for mainstake. > > > > For instance, the sidechain network might accept potential stakers on the > > mainchain, if the staker proves the existence of a mainchain transaction > > whose output is for example: > > > > <sidechain identifier> OP_DROP > > "1 year" OP_CHECKSEQUENCEVERIFY OP_DROP > > <pubkey> OP_CHECKSIG > > > > The sidechain network could accept this and use the value of the output as > > the weight of the vote of that stake. > > > > Regards, > > ZmnSCPxj > > > > Sent with ProtonMail Secure Email. > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Saturday, January 19, 2019 6:59 AM, Matt Bell via bitcoin-dev > > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > > I have been working on a design for Bitcoin sidechains using the > > > Tendermint BFT consensus protocol, which is commonly used to build > > > proof-of-stake networks (Cosmos is the notable one). > > > > > > The design ends up being very similar to Blockstream's Liquid sidechain, > > > since Tendermint consensus is not far off from Liquid's "strong > > > federation" consensus. > > > > > > Any feedback about improvements or critical flaws would be greatly > > > appreciated. The design document is here: > > > https://github.com/mappum/bitcoin-peg/blob/master/bitcoinPeg.md (that > > > repo also contains a simplified implementation of this sidechain design). > > > > > > Thanks for your feedback, > > > Matt Bell _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
