Date: Fri, 26 Jun 2020 00:57:13 +0000
To: Cloud Strife <quantumas3@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <okQj-0Wqe15uKxpyE__yGosi6QkxODpX2AVkebxFNXN3NXHOSA-Q10N_CMj8hSI1UGLObVDdM-wvmIAb2pklg4jX_vVPlpsr6EMMry5d7MM=@protonmail.com>
In-Reply-To: <CAHeORgLcir=hZSoiDAE2hfttW71tiMNor0updmgRc2z-W-v=ow@mail.gmail.com>
References: <CAHeORgLcir=hZSoiDAE2hfttW71tiMNor0updmgRc2z-W-v=ow@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Bitcoin 2-way-pegged childchains via Proof of Burn
Precedence: list

Good morning CS,

The difficulty is not so much the proof-of-whatever, but rather, the peg it=
self.
My understanding of your pegout from sidechain to mainchain is that this pe=
gout is very low-bandwidth, i.e. only a tiny amount can be pegged out at ea=
ch mainchain block.
This suggests to me that the sidecoin can still drop lower than maincoin du=
ring times when overall side-to-main flows are higher than main-to-side flo=
ws.
(atomic swaps cannot *maintain* a peg, they can only follow a peg if it exi=
sts; if the peg is weak, atomic swaps cannot strengthen it.
this is because atomic swaps allow a non-1:1 exchange rate, as in cross-cur=
rency atomic swaps.)


In any case, from my reading of your text, I seem, the goal is scaling ("ac=
ceptable option for lower value tx").
I studied sidechains some years ago, and, came to the conclusion that sidec=
hains are not good for scaling.
We already know that blockchains do not scale well (excessive bandwidth use=
, permanent records needed to support newcomers); thus, the scaling solutio=
n for cryptocurrency cannot be via **more** blockchains.
Hence, Lightning Network.

In Lightning Network, every channel is a consensus system between two parti=
cipants, hence every channel is a 2-of-2 (i.e. requires consensus of both p=
articipants to advance).
We use atomic swaps to transfer between channels and the blockchain.
The channel construction requires reference to an ultimate arbiter of any d=
ispute/non-consensus between the channel participants; this is provided by =
the blockchain layer off which the channel is based.

Thus blockchain for arbitration, channels for scaling.


Regards,
ZmnSCPxj


> Hi everyone,
>
> I am hoping to get a critique on a proposal of how to construct=C2=A0chil=
dchains=C2=A0"on-top" of Bitcoin without requiring any changes to Bitcoin i=
tself nor requiring any user or miner to be aware of them.
>
> The childchain is Bitcoin-aware and simulates the properties of Proof of =
Work by requiring continuous burning of Bitcoin in return for the fees on t=
he childchain.
>
> The childchain=C2=A0tip is selected by highest total accumulated Bitcoin =
burnt (with goal to simulate total accumulated work) for that full chained =
set of childchain block commits.
>
> The only asset on the childchain=C2=A0is a 2-way-peg coin that's secured =
in value without oracles or collateral by requiring that each valid child c=
hain block must not only burn Bitcoin, but must always use a small % of the=
 burnt amount to deterministically reimburse=C2=A0withdrawals from the chil=
dchain.
>
> Childchain -> mainchain :: user burns the child-BTC and is added to withd=
rawal queue filled as part of validity requirements by childchain "miners" =
until filled 1:1 on mainchain or more. Note that occasionally overpaying a =
widthdrawal does not break 1:1 peg as there's no fixed size 1:1 pool of coi=
ns necessary.
>
> mainchain -> childchain :: user burns BTC (independent of mining childcha=
in) and is issued equivalent 1:1 child-BTC on the childchain
>
> While childchains=C2=A0are less secure than the mainchain, both the child=
chain security and the 2-way-peg accuracy might be an acceptable option for=
 lower value tx on scale determined by the burning rate.=C2=A0
>
> Childchains would replace the need for any additional Proof of Work chain=
s for new blockchains to introduce any complexity (e.g. mimblewimble childc=
hain).
>
> They would effectively use Proof of Work done on Bitcoin as proxy for unf=
orgeable costliness and benefit from Bitcoin's censorship resistance and da=
ta availability. Large numbers of low value tx that might be priced out of =
using the main chain could possibly in bulk provide enough childchain fees =
combined through childchain miners to afford much higher mainchain fees lik=
e "batching for fees".
>
> It also has the "benefits" claimed by proof of stake like no energy consu=
mption without relying on internal permissions or tokens, trusted distribut=
ions, or centralizing mechanisms like staking by simulating proof of work. =
It should allow both growing the Bitcoin ecosystem and replace the need to =
create alternative cryptocurrencies just to make a new blockchain.
>
> More detailed write up available here:=C2=A0https://bitcointalk.org/index=
.php?topic=3D5214173.0=C2=A0=C2=A0
>
> I am hoping for a review if there's an overlooked issue or maybe interest=
 to create a proof of concept.
>
> Thank you
> -CS