From: Matt Bell <mappum@gmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains
Date: Mon, 21 Jan 2019 10:47:13 -0800 [thread overview]
Message-ID: <CACV3+OXQsUsgquJWZ9o8tTtak=axnbsdiNgLzF-j6yz1dDv4bA@mail.gmail.com> (raw)
In-Reply-To: <nq9NDv6z-EJuJ9jGMWdlIZbpVM6Rm8QyuWL3nRYtXWF90I-cErA_WS1ib28kt950bZYyfF1_eP153aDjhUy523wYSM9TVaeHqeZdp3xJpsk=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 3926 bytes --]
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
>
>
>
[-- Attachment #2: Type: text/html, Size: 5377 bytes --]
next prev parent reply other threads:[~2019-01-21 18:47 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-18 22:59 Matt Bell
2019-01-19 1:42 ` ZmnSCPxj
2019-01-19 5:35 ` Matt Bell
2019-01-20 2:06 ` ZmnSCPxj
2019-01-21 18:47 ` Matt Bell [this message]
2019-01-22 9:19 ` ZmnSCPxj
2019-01-22 14:58 ` Satoshin
2019-01-22 20:03 ` Dustin Dettmer
2019-01-22 16:33 ` Dustin Dettmer
2019-01-24 10:03 ` ZmnSCPxj
2019-01-24 18:46 ` Matt Bell
2019-01-25 0:16 ` Peter Todd
2019-01-25 5:33 ` ZmnSCPxj
2019-01-22 20:22 ` Dr Adam Back
2019-02-01 9:19 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACV3+OXQsUsgquJWZ9o8tTtak=axnbsdiNgLzF-j6yz1dDv4bA@mail.gmail.com' \
--to=mappum@gmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox