Date: Sun, 20 Jan 2019 02:06:08 +0000
To: Matt Bell <mappum@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <nq9NDv6z-EJuJ9jGMWdlIZbpVM6Rm8QyuWL3nRYtXWF90I-cErA_WS1ib28kt950bZYyfF1_eP153aDjhUy523wYSM9TVaeHqeZdp3xJpsk=@protonmail.com>
In-Reply-To: <CACV3+OWjszx6istHo7yaNxiS22kyhHQhcPxGT3QLDx3KPUMU6g@mail.gmail.com>
References: <CACV3+OU1ynRuR2SioW+O+CAp5M7ZQA6af_hEY5JZCVrXpqjtKQ@mail.gmail.com>
	<BTyUDt_7oOQmFj_V61w2eUJ7rfi-eOuNphy5nN0xNAhY4sUHnR2-0U9m-ZEKip4YjFi2-hGBtucvFv7nCTVo3aBxZ94VQCa1Kx2pP_zgdxU=@protonmail.com>
	<CACV3+OWjszx6istHo7yaNxiS22kyhHQhcPxGT3QLDx3KPUMU6g@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains
Precedence: list

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 sidec=
hain network. Then a validator who signs multiple versions of history at a =
particular blockheight reveals their privkey. Since the privkey also protec=
ts their Bitcoin stake UTXO, they risk loss of their Bitcoin stake. A simil=
ar idea is used by Discrete Log Contracts to ensure Oracles do not sign mul=
tiple values at a particular time.

Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
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, s=
o it is agnostic to whatever system you want to derive stake or valdiator s=
et membership from.
>
> Your idea of timelocking Bitcoin is interesting, I am eager to find a sol=
ution where holding Bitcoin is enough to get voting power. It's possible th=
ere may be an issue with the fact that the Bitcoin is not slashable (althou=
gh their voting power is), meaning a validator who double-signs cannot have=
 their Bitcoin removed from them. However their UTXO can be blacklisted whi=
ch does make their attack costly since they lose out on the time-value of t=
heir stake.
>
> Our current thinking for the source of stake is to pay out stake to Bitco=
in merged-miners although=C2=A0I'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 i=
ts own token that is self-attesting (which is insecure).
> > It seems to me, naively, that the same script you propose here can be u=
sed for mainstake.
> >
> > For instance, the sidechain network might accept potential stakers on t=
he 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.
> >
> > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origina=
l Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=
=90
> > On Saturday, January 19, 2019 6:59 AM, Matt Bell via bitcoin-dev <bitco=
in-dev@lists.linuxfoundation.org> wrote:
> >
> > > I have been working on a design for Bitcoin sidechains using the Tend=
ermint BFT consensus protocol, which is commonly used to build proof-of-sta=
ke networks (Cosmos is the notable one).
> > >
> > > The design ends up being very similar to Blockstream's Liquid sidecha=
in, since Tendermint consensus is not far off from Liquid's "strong federat=
ion" consensus.
> > >
> > > Any feedback about improvements or critical flaws would be greatly ap=
preciated. The design document is here: https://github.com/mappum/bitcoin-p=
eg/blob/master/bitcoinPeg.md (that repo also contains a simplified implemen=
tation of this sidechain design).
> > >
> > > Thanks for your feedback,
> > > Matt Bell