public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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: Thu, 24 Jan 2019 10:46:11 -0800	[thread overview]
Message-ID: <CACV3+OX-mx6eLMOvk5eh6nKGmS_6ZHR=G76LCCCkiPugB9NgRg@mail.gmail.com> (raw)
In-Reply-To: <8u0ExA_vvhRGzmFmxUoyqk6IBrnUEtEHAEMKzqLWLxC6IgBtvZR24jZBgeMeJlsPcjJKYgVar_rC388ZNjP09ZUkukfP1KRcL9NMDkrVrQM=@protonmail.com>

[-- Attachment #1: Type: text/plain, Size: 3241 bytes --]

It seems that miners would always claim the stake for themselves, why not
since the private key is public knowledge anyway? This is a nice security
property since it wouldn't make economical sense for a miner to take a
bribe from an attacker since it would have to be less than the stake amount.

It still becomes very unlikely that the staker will win unless the staker
> already has a significant mining hashpower (and if the staker has
> significant hashpower, then the Bitoin layer itself is at peril anyway,
> never mind sidechains built on top of it).


Since the likelihood of a successful attack is proportional to the
attacker's share of the Bitcoin hashrate, the sidechain's integrity
essentially has the same security level as the Bitcoin main chain.
Although, the Bitcoin which was moved to the sidechain is susceptible to
being stolen if 67% of the stakers collude, which does makes storing funds
on it weaker to some degree.

On Thu, Jan 24, 2019 at 2:03 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Dustin,
>
> > Wouldn’t a revealed private key for time locked funds create a race to
> spend? I imagine miners who are paying attention would have the advantage
> but it would still just be a race.
>
> If Bitcoin had implemented RBF "properly" (i.e. not have the silly
> "opt-out" rule) then such races are won by bidding up the fees.  A random
> person who is not the original staker would be willing to pay miners a fee
> up to the entire staked amount minus dustlimit satoshis; obviously a staker
> would be far less willing to pay up such a fee, so the random person
> slashing the funds would have a major advantage in that race.
> Thus the race will be won by whoever mines the highest-fee transaction.
> It still becomes very unlikely that the staker will win unless the staker
> already has a significant mining hashpower (and if the staker has
> significant hashpower, then the Bitoin layer itself is at peril anyway,
> never mind sidechains built on top of it).
>
> Regards,
> ZmnSCPxj
>
> >
> > On Tue, Jan 22, 2019 at 6:14 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > Good Morning Matt,
> > >
> > > > ### 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?
> > >
> > > One possibility is to derive `R` using standard hierarchical
> derivation.
> > > Then require that the staking pubkey be revealed to the sidechain
> network as actually being `staking_pubkey = P + hash(P || parent_R) * G`
> (possibly with some trivial protection against Taproot).
> > > To sign for a blockheight `h`, you must use your public key `P` and
> the specific `R` we get from hierarchical derivation from `parent_R` and
> the blockheight as index.
> > >
> > > Regards,
> > > ZmnSCPxj
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>

[-- Attachment #2: Type: text/html, Size: 4126 bytes --]

  reply	other threads:[~2019-01-24 18:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-18 22:59 [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains 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
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 [this message]
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+OX-mx6eLMOvk5eh6nKGmS_6ZHR=G76LCCCkiPugB9NgRg@mail.gmail.com' \
    --to=mappum@gmail.com \
    --cc=ZmnSCPxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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