ZmnSCPxj,

I'm intrigued by this mechanism of using fixed R values to prevent multiple
signatures, but how do we derive the R values in a way where they are
unique for each blockheight but still can be used to create signatures or
verify?

Thanks,
Matt

On Sat, Jan 19, 2019 at 6:06 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> 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 <mappum@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 <ZmnSCPxj@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
>
>
>