DomainKey-Signature: a=rsa-sha1; c=nofws; d=suredbits.com; s=mailo;
	q=dns; h=Sender: MIME-Version: In-Reply-To: References: From: Date:
	Message-ID: Subject: To: Content-Type;
	b=BvTuctUzsFPrwOOle9WksUlKjFcIIFWKqYSV3F3m7FKQK6BWKONnxi2gm+II+cnD+xxK2c
	l0Xgg9jzxzck1AO40LvTcOsorWDW77ojUoceVce1M0LvPUyGxD/RldGZvVct5cf51zJO0Bds
	Q518Ky0HQXW5nWO6soTK0v+BCMLEE=
Sender: chris@suredbits.com
MIME-Version: 1.0
In-Reply-To: <rRLvSIAs4ZyW4YTai9d_ON_xV2HH6NlhRIsU2C9mzTKiGuXmtJjafTtmK9lJIgBYVNVRGcfKAWON_l2ZE9bKuqON11NXGoKKn1SOGXi8Dbs=@protonmail.com>
References: <rRLvSIAs4ZyW4YTai9d_ON_xV2HH6NlhRIsU2C9mzTKiGuXmtJjafTtmK9lJIgBYVNVRGcfKAWON_l2ZE9bKuqON11NXGoKKn1SOGXi8Dbs=@protonmail.com>
From: Chris Stewart <chris@suredbits.com>
Date: Tue, 26 Sep 2017 12:51:50 -0500
Message-ID: <CAGL6+mEXEzrWK0w58tXEzHWvMQLdUJVEcJ5wBiFO0ye0yrKaig@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a1143df88777902055a1b542e"
Subject: Re: [bitcoin-dev] Sidechains: Mainstake
Precedence: list

--001a1143df88777902055a1b542e
Content-Type: text/plain; charset="UTF-8"

>For each sidechain ID, for each mainchain block, at most one sidechain
block header may be published. In addition, the sidechain block header
published on the mainchain blocks may only be published by the stake
lottery winner from the end of the previous block.

What happens if the stake winner disappears? It seems, in your scheme, that
this would cause progress to come to a screeching halt.

Our weak mitigation against a mainchain miner >50% attack is weakened
> further; now the mainchain miner with 51% hashpower need only block the
> creation of sidechain mainstake UTXOs except its own, and eventually the
> other mainstake UTXOs will time out and the miner can outright steal
> costlessly


Can we not nest mainstake outputs in p2wsh/p2sh scripts to mitigate this?
This means that they cannot block the creation of mainstake utxos -- but I
guess they would still be able to block the spends of this utxo.

Another thing that is problematic with using a p2sh output is 'relocking'
the stake. Unfortunately if the p2sh script hash's aren't identical I don't
think we can guarantee they didn't spend the stake to a non stake output.
If the script hash's *are* identical then the miner can censor the
transaction that re-locks the output.

Perhaps there is a hybrid that would work, however it depends on what you
mean by 'creation'. If it is just the *initial* creation of the utxo -- and
not subsequent OP_STAKEVERIFY change outputs -- I think this strategy might
work. You just won't be able to participate in the lottery while the utxo
is nested inside the p2sh output initially.

This also brings back the problem above -- what if a stake winner
disappears -- or a miners creates the illusion they disappeared via
censorship? I guess a miner would be losing out on transaction fees.

-Chris


On Fri, Sep 22, 2017 at 8:49 PM, ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning bitcoin-dev,
>
> I have yet another sidechain proposal: https://zmnscpxj.github.io/
> sidechain/mainstake/index.html
>
> I make the below outlandish claims in the above link:
>
> 1. While a 51% mainchain miner theft is still possible, it will take even
> longer than in drivechains (either months of broadcasting intent to steal
> before the theft, or locking funds that are likely to remain locked after a
> week-long theft).
> 2. A 26% anti-sidechain miner cannot completely block all sidechain
> withdrawals as they could in drivechains.
> 3. Outside of attacks and censorship, the economic majority controls
> sidechains, without going through miners as "representatives of the
> economic majority".
> 4. With sufficient cleverness (stupidity?), proof-of-stake can be made to
> work.
>
> I hope for your consideration.  I suspect that I have not thought things
> out completely, and probably missed some significant flaw.
>
> Regards,
> ZmnSCPxj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr"><div>&gt;For each sidechain ID, for each mainchain block, =
at most
one sidechain block header may be published.  In addition, the
sidechain block header published on the mainchain blocks may
only be published by the stake lottery winner from the end of
the previous block.<br><br></div>What happens if the stake winner disappear=
s? It seems, in your scheme, that this would cause progress to come to a sc=
reeching halt. <br><br><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ou=
r weak mitigation against a mainchain miner &gt;50% attack
     is weakened further; now the mainchain miner with 51% hashpower
     need only block the creation of sidechain mainstake UTXOs except
     its own, and eventually the other mainstake UTXOs will time out
     and the miner can outright steal costlessly</blockquote><div><br></div=
><div>Can we not nest mainstake outputs in p2wsh/p2sh scripts to mitigate t=
his? This means that they cannot block the creation of mainstake utxos -- b=
ut I guess they would still be able to block the spends of this utxo.<br></=
div><div><br> </div><div>Another thing that is problematic with using a p2s=
h output is &#39;relocking&#39; the stake. Unfortunately if the p2sh script=
 hash&#39;s aren&#39;t identical I don&#39;t think we can guarantee they di=
dn&#39;t spend the stake to a non stake output. If the script hash&#39;s *a=
re* identical then the miner can censor the transaction that re-locks the o=
utput.</div><div><br></div><div>Perhaps there is a hybrid that would work, =
however it depends on what you mean by &#39;creation&#39;. If it is=20
just the *initial* creation of the utxo -- and not subsequent=20
OP_STAKEVERIFY change outputs -- I think this strategy might work. You=20
just won&#39;t be able to participate in the lottery while the utxo is=20
nested inside the p2sh output initially.<div><br></div></div><div>This also=
 brings back the problem above -- what if a stake winner disappears -- or a=
 miners creates the illusion they disappeared via censorship? I guess a min=
er would be losing out on transaction fees.</div><div><br></div><div>-Chris=
<br></div><div><br></div><div><br></div></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On Fri, Sep 22, 2017 at 8:49 PM, ZmnSCPxj via =
bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Good morning bitc=
oin-dev,<br></div><div><br></div><div>I have yet another sidechain proposal=
: <a href=3D"https://zmnscpxj.github.io/sidechain/mainstake/index.html" tar=
get=3D"_blank">https://zmnscpxj.github.io/<wbr>sidechain/mainstake/index.ht=
ml</a><br></div><div><br></div><div>I make the below outlandish claims in t=
he above link:<br></div><div><br></div><div>1. While a 51% mainchain miner =
theft is still possible, it will take even longer than in drivechains (eith=
er months of broadcasting intent to steal before the theft, or locking fund=
s that are likely to remain locked after a week-long theft).<br></div><div>=
2. A 26% anti-sidechain miner cannot completely block all sidechain withdra=
wals as they could in drivechains.<br></div><div>3. Outside of attacks and =
censorship, the economic majority controls sidechains, without going throug=
h miners as &quot;representatives of the economic majority&quot;.<br></div>=
<div>4. With sufficient cleverness (stupidity?), proof-of-stake can be made=
 to work.<br></div><div><br></div><div>I hope for your consideration.=C2=A0=
 I suspect that I have not thought things out completely, and probably miss=
ed some significant flaw.<br></div><div><br></div><div>Regards,<br></div><d=
iv>ZmnSCPxj<br></div><br>______________________________<wbr>_______________=
__<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--001a1143df88777902055a1b542e--