Using childchains would require using mainchain nodes too as childchains must be mainchain aware without requiring mainchain to be childchain aware, best of both worlds.
Childchains would natively depend on mainchain for security, so any devs working on childchain would have to keep mainchain interests in mind.
Mainchain hashrate is not hurt since childchains do not need hashrate and they accumulate fees otherwise not used for Bitcoin and increase payment to miners, effectively paying for more mainchain hashrate. Any tx demand from burning w/ high enough fees for inclusion in blocks increases the fee market and further increases mainchain security.
I honestly think this allows any and all altcoin type experimentation on Bitcoin, benefits Bitcoin, and removes need for altcoins
I've been trying to consider various options for such designs and mention why I chose what I did, could be wrong:
c- child chain (some refer to as side chain / sc)
m- main chain or parent chain
POB WINNING CHAIN TIP1) pick child chain tip at c-height via (total) burnt size
---- gives advantage to higher burn amounts even if small % of total burnt, requires burning pools (e.g. 5% x 18, 10% x 1 - 18 people burning 5% lose to 1 person burning 10% of total)
---- revealing data for earlier large burn commit at later time does not necessarily shift c-chain tip if original chain has more accumulated burn
2) pick child chain tip at c-height via deterministic random func weighted by m-burn amount (source of randomness is current m-block-header-hash)
---- if winner for deterministic randomness is chosen based on all submitted burns, revealing c-block data for a relatively small burn at later time could shift the c-chain tip too easily
---- if winner for deterministic randomness is chosen based on all submitted burns, burn at later time for same c-block could shift chain tip
---- if winner for deterministic randomness is chosen based on all submitted burns & burns require reveal on childchain, revealing an old burn could shift the c-chain tip too easily
3) winner via tx fee instead of burn (allows miners paying enormous fee to themselves for free)
---- gives control to m-miners paying themselves when there's spare block space (so do not have to displace others fees)
---- if using covenants to limit to 1 tx, gives m-miners control when spare block space and low/no displaced miner fee from others
I consider (1) best. (2) can cause shifts in chain tips with relatively insignificant costs. (3) happens in (1) either way by being forced to pay enough of miner fee to be included in block. (2) might only work if
C-HEIGHT VS M-HEIGHT1) c-height = m-height : you cannot post earlier c-height commitat later time
---- does not address doing m-chain commit at correct m-height but withholding c-data until later time
2) c-height independent of m-height: you can post any c-height commit at any m-height
---- allows reorganizing childchain at later time via new commit or revealing old data
I consider (2) best. C-chain reorg can happen in both cases, but the latter does not punish tx that were delayed by a block before cancelation of rbf is broadcast.
WHO GETS C-FEES REWARDS ON CHILDCHAINchanges to who gets fees is as damaging as changes to winning chain tip by changing state
1) winning chain tip gets 100%
- simplest but punishes losing chain tips
2) split b/w every burn for that c-height (weighted by amount)
- causes an issue for a burn at later m-height commits or revealed data for same c-height forcing changes to earlier paid out fees, invalidating state
- if m-miners double as c-miners, and others burns are discovered by mainchain miners, it creates incentive for mainchain miners to censor others burns to increase their own % payouts on childchain
3) split b/w every burn for that m-height (weighted by amount)
- possible if public childchain commits do not require reveal to know all participants & payout is independent of c-block validity or availability - cannot be changed later.
- if m-miners double as c-miners, and others burns are discovered by mainchain miners, it creates incentive for mainchain miners to censor others burns to increase their own % payouts on childchain
4) split rewards between main-chain miners and child-chain "miners/burners" (e.g. 50/50)
- total burnt doesn't change via split, still unforgeable costliness
- payout to childchain miners is smaller reducing how much they are willing to burn and thus childchain security
- miners get paid enough of a main-chain fee regardless for burns to be included in full blocks
- at ~0% childchain adoption m-miners get paid aggregation of smaller fees so reduces incentive to censor childchains and encourages to allow childchain "mining" by others if they want to withdraw via burn-diversion scheme
- at ~100% childchain adoption m-miners would still get paid on childchain even if nobody is sending mainchain tx, otherwise main chain hashrate would go unpaid and security would be gone
5) only paying main-chain miners
- forces them to actively produce c-blocks and thus be child-chain aware forcing higher costs on them
- at 0% childchain adoption, would be very difficult to expect any significant burn. Allowing others to produce childchain blocks for reward or for tx they want goes away. Also, if independent burners aren't incentivized to include all childchain transactions for their fees, they have no cost to censor other childchain users.
Simplest is (1) + (4). (3) seems to suffer from incentive problem of possibly making it more profitable for childchain-miners to censor other childchain-miners. Also (4) appears to be required to account for high % adoption and incentivizing main chain miners not censoring childchain at low % adoption. Incentivizing main chain miners to allow childchain seems safest via being paid in childchain coins. Either way, mainchain miners do get trickle down of accumulated small fees on childchain by burners being able to include larger mainchain fees to be included in blocks.
PAYING MAIN CHAIN MINERS?1) no, only enough fee for inclusion
---- doesn't dissentivize childchain censorship if miners decide it's profitable
2) yes, fraction of fees paid on childchain
---- gives more incentive for miners to allow childchains for extra income
---- at high adoption, can become main chain miners ~entire income
---- at low adoption & thus low value, miners can ignore childchain completely, doesn't force them to claim rewards, incentivizes miners to allow others to burn for withdrawals or use childchain for c-coins to have value
3) pay everything to main chain miners on childchain
---- removes incentive for child chain users to create blocks or include others childchain tx
---- at low adoption, miners can ignore childchain and effectively stop its growth forever
4) require payment of fraction of burn to mainchain miners on mainchain (not known ahead of time, so has to be for previous m-block)
---- miners can ignore childchain completely when accumulated fees are not worth syncing childchain nodes.
---- similar to (2) but gives miners additional discount on creating childchain blocks and thus control over childchain
---- does not incentivize miners to allow others to burn and propagate childchain without funds to withdraw on childchain
5) bmm style single tx where c-winner is effectively picked via highest miner fee and not burn amount (bmm requires output templates soft forked primitives)
---- miners get paid directly so safe at high % adoption, more direct transition than 50/50 mainchain/childchain miner split
---- minimum impact on main-chain utxo set
---- maximum discount possible for mainchain miners to control childchain blocks for censorship/doublespends/rewards at opportunity cost of non-miners fee displaced. e.g. m-miners can double spend on childchain by paying themselves 1sat-1000000 btc in tx fee without any risk of losing that money by referencing an earlier c-height at later m-chain height.
6) paying mainchain miners based on empty mainchain block weight
---- at low % adoption, does not incentivize mainchain miners to allow childchain
---- at high % adoption, effectively pays mainchain miners to censor mainchain users and force them to move to childchain
---- Encourages smaller bandwidth use by main chain for easier mainchain validation and creates a minimum main chain fee at which its more profitable for miners not to include that mainchain tx than to include for higher childchain reward.
I like (2) to account for both layers block producers independently. (4) is not necessary and worse for childchain security. Beautify in paying mainchain miners in childchain coins is in effect dissentivizes mainchain miners from creating childchain blocks if they want to withdraw 2wp as they would be literally reimbersing themselves for net-0 income from childchain. I dislike (6) since I want users to choose layer they want but I could see how it could be used to utilize childchains as means of protocol upgrades by abstracting mainchain to only miners and incentivizing use of higher layers. Block weight cap already limits bandwidth. Ideally impact on mainchain should be minimal & do no harm to mainchain. BMM (5) could be combined with burning to reduce m-miner discount and increase their costs while retaining minimum impact on mainchain utxo.
HIDDEN OR KNOWN CHILDCHAIN COMMITS/BURNS1) Public burns and commits
---- Main chain miners might choose to censor childchain commits to prevent losses of fees to childchain.
---- On other hand, users that can only pay very small fees would have an option to childchain over nothing at all connected to Bitcoin miners. Mainchain miners would not benefit from those fees if they are too low to be included in full main chain blocks, child chain does serve as an aggregation or batching of many small fees into a single fee that's large enough to be included in the m-block.
---- If c-reward is split weighted by (winning burn amount / total burn amounts), m-minners might censor others burns on mainchain to reduce total burn amounts to maximize their c-reward
---- Immediately know the difference between accumulated burn between different block versions to calculate differences and thus how much additional cost would be required for a double spend.
2) Private burns
---- Allows withholding the reveal of a commit until later time for potential double spends
---- Immediately know the difference between accumulated burn between different block versions to calculate differences and thus how much additional cost would be required for a double spend.
lmk if group chat is undesired, I'm just happy to see any discussion on these sc/cc ideas.
MECHANISM OF WITHDRAWALS TO MAINCHAIN1-directional peg to childchain is possible by burning mainchain coins to mint same # of coins on childchain.
1) Childchain commits require fraction of burnt amount (let's say 10%) to be used to payout withdrawal queue for validity. Childchain withdrawal requests to be added to the withdrawal queue can be published on as mainchain or childchain tx.
---- As long as childchain blocks are created, each requires burns & fraction of that used for withdrawals for validity, overtime all c-coins can be converted to m-coins at 1:1 or better at some point in future
---- For edgecase where users doing withdrawal from childchain are also childchain-miners they effectively pay 10% less to decide consensus from paying to themselves instead of someone else. However, the difference between someone else paying for their own withdrawal and themselves is, in first case, they get that withdrawal but, in the latter case, they do not get any new main-chain Bitcoin and effectively lose amount withdrawn to mainchain. Childchain security at each height can be approximated by businesses/exchanges via total accumulated burn; For measuring # of confirmations when childchain tx is secure, they simply need to account for maximum discount of 10% where 90% is still unforgeably costly
---- Childchain reorgs and overpaying withdrawals do not by themselves hinder future withdrawals
2) No withdrawal mechanism so price of childchain coins relies on 1-directional peg and demand of childchain keeping c-coin purchasing power as close to mainchain bitcoin
---- no risks from discounts for consensus to any party
---- strongly depends on unpredictable high demand or it falls below 1:1 value
3) Instead of burning mainchain coins, they can be placed in mainchain outputs controlled by childchain block producers. Peg depends on having a coin in mainchain reserve for each coin on childchain.
---- main chain consensus rules are not aware of childchains without main chain rule changes, so very hard to account for changes in block producers, non-responsive block producers, and malicious block producers
---- allows profitable collusion of childchain producers to steal more mainchain funds than costs to do it, breaking the peg.
---- any reorgs on childchain could mean invalid withdrawal was already done and thus reserve is already lacking coins and, thus, breaks 1:1 peg
I consider (1) best and unique in where 2 way peg can be created without mainchain changes without issues of collusion, trust, or oracles. It's hard to find another mechanism for source of mainchain Bitcoins.
Did I make mistake? Do you disagree? Please, let me know. Thank you!
