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=Zoq5RZvqETth+w0OwsBfN60I0bP7cWSn10zw0QYHFGEd96q0pKYVWNu6fCA1zpP91EkDf6
	GKnv8pjBlI92qKLS8+xK5xNHo3ruYbKEjVMZc9nS6QYknx3VFG0mTjUcUKp7xsXdYHEAu17A
	UvqzWzVDFZgxkFtfT30U2PPZ+GFW8=
Sender: chris@suredbits.com
MIME-Version: 1.0
In-Reply-To: <H7RPmZGfkVC8opGMMCW7Orav6yD05-AVB9bNtNU8C0hKYokiXL32VSmn0wkjn77qh4MvacPOePdVQ5gQZuAMF6q2oEuvKDSu6crNcEoXx_0=@protonmail.com>
References: <H7RPmZGfkVC8opGMMCW7Orav6yD05-AVB9bNtNU8C0hKYokiXL32VSmn0wkjn77qh4MvacPOePdVQ5gQZuAMF6q2oEuvKDSu6crNcEoXx_0=@protonmail.com>
From: Chris Stewart <chris@suredbits.com>
Date: Tue, 5 Sep 2017 12:06:32 -0500
Message-ID: <CAGL6+mFHe_SfMea1oMZ3n-G3ey9yToAvTMTcfdxJ5qDD1dTXyQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c056162c74caa0558743fad"
Subject: Re: [bitcoin-dev] Sidechain headers on mainchain (unification of
 drivechains and spv proofs)
Precedence: list

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

Hi ZmnSCPxj,

Basically, in case of a sidechain fork, the mainchain considers the longest
> chain to be valid if it is longer by the SPV proof required length.  In t=
he
> above, at mainchain block 10, the sidechain H is now 4 blocks (H,G,F,E)
> longer than the other sidechain fork that ended at d.
>
> Mainchain nodes can validate this rule because the sidechain headers are
> embedded in the mainchain block's coinbase.  Thus, mainchain fullnodes ca=
n
> validate this part of the sidechain rule of "longest work chain".
>

What happens in the case that the provided merkle tree hash has a invalid
transaction in it? Wouldn't this mean that the mainchain nodes would think
the longest work chain is the valid chain, and it would kill off any
consensus valid chain that sidechain miners are trying to construct? It
seems that a malicious miner could extend the chain to whatever the SPV
proof block height is and make it impossible for the chain to reorg after
that. I guess if that is a sufficiently long block waiting period it may
not be a realistic concern, but something to think about any way.

Just a side note -- I think it should be highly recommended that the
coinbase maturity period on the sidechain to be longer than 288 (or
whatever we decide on the parameter). This incentivizes the s:miners to
work together to extend the chain by working with other s:miners (otherwise
they won't be able to claim their bribes). If they do not work together
they will not be able to spend their s:coinbase_tx outputs until they
extend their own sidechain by 288 blocks meaning they need to tie up a
large amount of capital to go rogue on their fork.

Another interesting thing might be to use the OP_WITHDRAWPROOFVERIFY op cod=
e
<https://github.com/ElementsProject/elements/blob/elements-0.14.1/src/scrip=
t/interpreter.cpp#L1420>
used in the elements project. Since the cannonical merkle root hashes are
included in the mainchain, we can provide a merkle proof to the bitcoin
blockchain to initiate a withdrawl from the sidechain. I wrote up a blog
post on how OP_WPV works here
<https://medium.com/@Chris_Stewart_5/what-can-go-wrong-when-transferring-co=
ins-into-a-sidechain-with-op-withdrawproofverify-b2f49b02ab60>.
This allows us to prove that a transaction occurred on the sidechain to
lock up those funds.

-Chris
=E2=80=8B

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

<div dir=3D"ltr"><div><div><div><div><div>Hi ZmnSCPxj,<br></div><div><br></=
div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Basically, =
in case of a sidechain fork, the mainchain considers the
 longest chain to be valid if it is longer by the SPV proof required=20
length.=C2=A0 In the above, at mainchain block 10, the sidechain H is now 4=
=20
blocks (H,G,F,E) longer than the other sidechain fork that ended at d.<br><=
/div><div><br></div>Mainchain
 nodes can validate this rule because the sidechain headers are embedded
 in the mainchain block&#39;s coinbase.=C2=A0 Thus, mainchain fullnodes can=
=20
validate this part of the sidechain rule of &quot;longest work chain&quot;.=
<br></blockquote><br></div>What happens in the case that the provided merkl=
e tree hash has a invalid transaction in it? Wouldn&#39;t this mean that th=
e mainchain nodes would think the longest work chain is the valid chain, an=
d it would kill off any consensus valid chain that sidechain miners are try=
ing to construct? It seems that a malicious miner could extend the chain to=
 whatever the SPV proof block height is and make it impossible for the chai=
n to reorg after that. I guess if that is a sufficiently long block waiting=
 period it may not be a realistic concern, but something to think about any=
 way. <br></div><br></div>Just a side note -- I think it should be highly r=
ecommended that the coinbase maturity period on the sidechain to be longer =
than 288 (or whatever we decide on the parameter). This incentivizes the s:=
miners to work together to extend the chain by working with other s:miners =
(otherwise they won&#39;t be able to claim their bribes). If they do not wo=
rk together they will not be able to spend their s:coinbase_tx outputs unti=
l they extend their own sidechain by 288 blocks meaning they need to tie up=
 a large amount of capital to go rogue on their fork.<br><br></div>Another =
interesting thing might be to use the <a href=3D"https://github.com/Element=
sProject/elements/blob/elements-0.14.1/src/script/interpreter.cpp#L1420">OP=
_WITHDRAWPROOFVERIFY op code</a> used in the elements project. Since the ca=
nnonical merkle root hashes are included in the mainchain, we can provide a=
 merkle proof to the bitcoin blockchain to initiate a withdrawl from the si=
dechain. I wrote up a blog post on how OP_WPV works <a href=3D"https://medi=
um.com/@Chris_Stewart_5/what-can-go-wrong-when-transferring-coins-into-a-si=
dechain-with-op-withdrawproofverify-b2f49b02ab60">here</a>. This allows us =
to prove that a transaction occurred on the sidechain to lock up those fund=
s.<br><br></div>-Chris<br><div><div>=E2=80=8B</div></div></div>

--94eb2c056162c74caa0558743fad--