path: root/b8/2b6adcccc69d283fe25fcff13e400835016e28

Return-Path: <mappum@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 4D73BC50
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 24 Jan 2019 18:46:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com
	[209.85.160.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 56F867C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 24 Jan 2019 18:46:24 +0000 (UTC)
Received: by mail-qt1-f177.google.com with SMTP id n32so7795745qte.11
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 24 Jan 2019 10:46:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc; bh=guyJbR/Vyv5562krnXrrRJCRDAu+tZOhJtMlLWjCu1A=;
	b=B+/qzV20Hc722Ctrt8SOf3P6HXp4SFr/H31czXW1HoarOrZuSP83BBbF7qun3ur4DJ
	uAiuUtf4mvFn0DSsCk9idAEG6ov3M2r20qKqFq5qSBdJ/S0nL4IagvVn7oLqXMJ/aml7
	3xcZVhCPx5VF4gLpyA7A4WKNdfzrj+6mXTQqWTfm5BNrjPEQjl00OuZvok7vekQ4FJ8z
	WM0CGRM6S2ZMutZoneVDm74nGBvnI3SgL4V4WdnW6mUpbFLfuKes6SM9zNrEwf1BTRBl
	uiTrJOpgDtxbt6bEz2vitUkxRL1O1N7y/wusiLuwsKu1wcAQ2iYKDz14KlEe6g/Z/oWn
	gedA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:cc;
	bh=guyJbR/Vyv5562krnXrrRJCRDAu+tZOhJtMlLWjCu1A=;
	b=rhywYHlnG2F4+SKBSCipUAKUB0diBnlKXqdU/EX99YOhcOVPjHdYAiIB4rANvQX2UN
	RohqFnnqySEKru3nd+bmMrrrcZ/1BmoWCjS5tp0jN8xbEVaWz5A1lZCLUHY4HvgI6z/W
	QjpTpjW77WhUnnpLcJQUOraEOUvo3VbpQ540gH1Y9nA+J97rm0haSUokd++4uI+dVexT
	erP0r7zzR+pfsJE8dfRa2QHBvDqxcW6UjoflQn9CLUfyyTUylqxD0/xrJhA1scFHuMLn
	HdLTqV9GFNCKhjRpahH5eveS1eawMhXoYNFySx2t6v6zfBcqzBoeRfKhWh3ucx89SDBw
	bmXQ==
X-Gm-Message-State: AJcUukeQE0LegDW7PBpNd7Ahzblr5xka/jlemMu7TEHaoIn51vI8DUFm
	LwYSdd47g1+Y4C3aJo7vZFg4QSv01+NH4SixZPQ=
X-Google-Smtp-Source: ALg8bN505G2V9pN5Jc9mO99nwsiay2vMg7XHTIY/sbxio0JyQJxOFDOC/Wmw5Xf95mSi03D+4Zg+plwGgJ2s7ebMO8g=
X-Received: by 2002:ac8:f2a:: with SMTP id e39mr8083097qtk.262.1548355583151; 
	Thu, 24 Jan 2019 10:46:23 -0800 (PST)
MIME-Version: 1.0
References: <CACV3+OU1ynRuR2SioW+O+CAp5M7ZQA6af_hEY5JZCVrXpqjtKQ@mail.gmail.com>
	<BTyUDt_7oOQmFj_V61w2eUJ7rfi-eOuNphy5nN0xNAhY4sUHnR2-0U9m-ZEKip4YjFi2-hGBtucvFv7nCTVo3aBxZ94VQCa1Kx2pP_zgdxU=@protonmail.com>
	<CACV3+OWjszx6istHo7yaNxiS22kyhHQhcPxGT3QLDx3KPUMU6g@mail.gmail.com>
	<nq9NDv6z-EJuJ9jGMWdlIZbpVM6Rm8QyuWL3nRYtXWF90I-cErA_WS1ib28kt950bZYyfF1_eP153aDjhUy523wYSM9TVaeHqeZdp3xJpsk=@protonmail.com>
	<CACV3+OXQsUsgquJWZ9o8tTtak=axnbsdiNgLzF-j6yz1dDv4bA@mail.gmail.com>
	<wTXHV7W_AXHz5xdhXJVJr2OdSpEOaFh0PBQubFdZv4JyF6SlImszj2QyF9G-_Dem06A3iBWLF3vdgiHC_NlsVqy7DFX5XTphajNnMqiU6r0=@protonmail.com>
	<CABLeJxRmdccf2tVZ4MsdsEj6H9+NnOpp+AeMLZwYh-zTMkWJXw@mail.gmail.com>
	<8u0ExA_vvhRGzmFmxUoyqk6IBrnUEtEHAEMKzqLWLxC6IgBtvZR24jZBgeMeJlsPcjJKYgVar_rC388ZNjP09ZUkukfP1KRcL9NMDkrVrQM=@protonmail.com>
In-Reply-To: <8u0ExA_vvhRGzmFmxUoyqk6IBrnUEtEHAEMKzqLWLxC6IgBtvZR24jZBgeMeJlsPcjJKYgVar_rC388ZNjP09ZUkukfP1KRcL9NMDkrVrQM=@protonmail.com>
From: Matt Bell <mappum@gmail.com>
Date: Thu, 24 Jan 2019 10:46:11 -0800
Message-ID: <CACV3+OX-mx6eLMOvk5eh6nKGmS_6ZHR=G76LCCCkiPugB9NgRg@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000008511f0058038a08c"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 24 Jan 2019 18:47:51 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jan 2019 18:46:26 -0000

--0000000000008511f0058038a08c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=99t 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 fe=
e
> up to the entire staked amount minus dustlimit satoshis; obviously a stak=
er
> 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 the=
y
> are
> > > unique for each blockheight but still can be used to create signature=
s
> 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 =3D 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
>
>
>

--0000000000008511f0058038a08c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">It seems that miners would always claim t=
he stake for themselves, why not since the private key is public knowledge =
anyway? This is a nice security property since it wouldn&#39;t make economi=
cal sense for a miner to take a bribe from an attacker since it would have =
to be less than the stake amount.<div><br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">It still becomes very unlikely that the staker will win un=
less the staker already has a significant mining hashpower (and if the stak=
er has significant hashpower, then the Bitoin layer itself is at peril anyw=
ay, never mind sidechains built on top of it).</blockquote><div><br></div><=
/div><div>Since the likelihood of a successful attack is proportional to th=
e attacker&#39;s share of the Bitcoin hashrate, the sidechain&#39;s integri=
ty essentially has the same security level as the Bitcoin main chain. Altho=
ugh, the Bitcoin which was moved to the sidechain is susceptible to being s=
tolen if 67% of the stakers collude, which does makes storing funds on it w=
eaker to some degree.</div></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">On Thu, Jan 24, 2019 at 2:03 AM ZmnSCPxj &lt;<a =
href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning=
 Dustin,<br>
<br>
&gt; Wouldn=E2=80=99t a revealed private key for time locked funds create a=
 race to spend? I imagine miners who are paying attention would have the ad=
vantage but it would still just be a race.<br>
<br>
If Bitcoin had implemented RBF &quot;properly&quot; (i.e. not have the sill=
y &quot;opt-out&quot; rule) then such races are won by bidding up the fees.=
=C2=A0 A random person who is not the original staker would be willing to p=
ay miners a fee up to the entire staked amount minus dustlimit satoshis; ob=
viously a staker would be far less willing to pay up such a fee, so the ran=
dom person slashing the funds would have a major advantage in that race.<br=
>
Thus the race will be won by whoever mines the highest-fee transaction.<br>
It still becomes very unlikely that the staker will win unless the staker a=
lready has a significant mining hashpower (and if the staker has significan=
t hashpower, then the Bitoin layer itself is at peril anyway, never mind si=
dechains built on top of it).<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
&gt;<br>
&gt; On Tue, Jan 22, 2019 at 6:14 AM ZmnSCPxj via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; Good Morning Matt,<br>
&gt; &gt;<br>
&gt; &gt; &gt; ### ZmnSCPxj,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I&#39;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<br>
&gt; &gt; unique for each blockheight but still can be used to create signa=
tures or verify?<br>
&gt; &gt;<br>
&gt; &gt; One possibility is to derive `R` using standard hierarchical deri=
vation.<br>
&gt; &gt; Then require that the staking pubkey be revealed to the sidechain=
 network as actually being `staking_pubkey =3D P + hash(P || parent_R) * G`=
 (possibly with some trivial protection against Taproot).<br>
&gt; &gt; To sign for a blockheight `h`, you must use your public key `P` a=
nd the specific `R` we get from hierarchical derivation from `parent_R` and=
 the blockheight as index.<br>
&gt; &gt;<br>
&gt; &gt; Regards,<br>
&gt; &gt; ZmnSCPxj<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; bitcoin-dev mailing list<br>
&gt; &gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bit=
coin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundatio=
n.org/mailman/listinfo/bitcoin-dev</a><br>
<br>
<br>
</blockquote></div></div>

--0000000000008511f0058038a08c--