public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Cloud Strife <quantumas3@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Bitcoin 2-way-pegged childchains via Proof of Burn
Date: Thu, 25 Jun 2020 17:43:20 -0400	[thread overview]
Message-ID: <CAHeORgLcir=hZSoiDAE2hfttW71tiMNor0updmgRc2z-W-v=ow@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2627 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3162 bytes --]

             reply	other threads:[~2020-06-25 21:43 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-25 21:43 Cloud Strife [this message]
2020-06-26  0:57 ` [bitcoin-dev] Bitcoin 2-way-pegged childchains via Proof of Burn ZmnSCPxj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHeORgLcir=hZSoiDAE2hfttW71tiMNor0updmgRc2z-W-v=ow@mail.gmail.com' \
    --to=quantumas3@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox