* Re: [bitcoin-dev] Bitcoin 2-way-pegged childchains via Proof of Burn
2020-06-25 21:43 [bitcoin-dev] Bitcoin 2-way-pegged childchains via Proof of Burn Cloud Strife
@ 2020-06-26 0:57 ` ZmnSCPxj
0 siblings, 0 replies; 2+ messages in thread
From: ZmnSCPxj @ 2020-06-26 0:57 UTC (permalink / raw)
To: Cloud Strife, Bitcoin Protocol Discussion
Good morning CS,
The difficulty is not so much the proof-of-whatever, but rather, the peg itself.
My understanding of your pegout from sidechain to mainchain is that this pegout is very low-bandwidth, i.e. only a tiny amount can be pegged out at each mainchain block.
This suggests to me that the sidecoin can still drop lower than maincoin during times when overall side-to-main flows are higher than main-to-side flows.
(atomic swaps cannot *maintain* a peg, they can only follow a peg if it exists; 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-currency atomic swaps.)
In any case, from my reading of your text, I seem, the goal is scaling ("acceptable option for lower value tx").
I studied sidechains some years ago, and, came to the conclusion that sidechains 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 solution for cryptocurrency cannot be via **more** blockchains.
Hence, Lightning Network.
In Lightning Network, every channel is a consensus system between two participants, hence every channel is a 2-of-2 (i.e. requires consensus of both participants to advance).
We use atomic swaps to transfer between channels and the blockchain.
The channel construction requires reference to an ultimate arbiter of any dispute/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 childchains "on-top" of Bitcoin without requiring any changes to Bitcoin itself 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 the childchain.
>
> The childchain tip 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 is a 2-way-peg coin that's secured in value without oracles or collateral by requiring that each valid child chain block must not only burn Bitcoin, but must always use a small % of the burnt amount to deterministically reimburse withdrawals from the childchain.
>
> Childchain -> mainchain :: user burns the child-BTC and is added to withdrawal 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 coins necessary.
>
> mainchain -> childchain :: user burns BTC (independent of mining childchain) and is issued equivalent 1:1 child-BTC on the childchain
>
> While childchains are less secure than the mainchain, both the childchain security and the 2-way-peg accuracy might be an acceptable option for lower value tx on scale determined by the burning rate.
>
> Childchains would replace the need for any additional Proof of Work chains for new blockchains to introduce any complexity (e.g. mimblewimble childchain).
>
> They would effectively use Proof of Work done on Bitcoin as proxy for unforgeable costliness and benefit from Bitcoin's censorship resistance and data 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 like "batching for fees".
>
> It also has the "benefits" claimed by proof of stake like no energy consumption without relying on internal permissions or tokens, trusted distributions, 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: https://bitcointalk.org/index.php?topic=5214173.0
>
> I am hoping for a review if there's an overlooked issue or maybe interest to create a proof of concept.
>
> Thank you
> -CS
^ permalink raw reply [flat|nested] 2+ messages in thread