I didn't remove anything specifically,

the algorithm checks initial supply (central controlled supply) and compares it to current supply

at >50% central control, 1 party controls more of incentive market value than all other parties combined

the filter that removes >50% central premines is what removed it


what is new about centrally controlled tech?

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:



POB WINNING CHAIN TIP

1) 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-HEIGHT

1) 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 CHILDCHAIN

changes 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/BURNS

1) 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 MAINCHAIN

1-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!

By the way I wrote up similar design idea without any altcoins - bitcoin peg only which I think is also doable.

What you brought up is important, however.

I have spent a lot of time thinking about scenarios where childchain grows too large compared to main chain.

Unforgeable costliness of proof of burn is most important scale of security when it's the weakest link in security - while burned coin value is smaller than unforgeable costliness of proof of energy burn (PoW).

I believe the at extremely large highly adopted childchain scenario would have most rewards paid on childchain & thus security would approach almost entirely the base layers PoW security.

To ensure pow >= pob costs & rewards, I now think half of all rewards per childchain block should be given to layer 1 miner which would evenly distribute security to avoid weak parent.

It also effectively allows completely voluntary migrations and protocol changes through childchains, although I think it's extremely unlikely.

I think this solution works incentive-wise with any units of rewards including pure bitcoin childchains and in all extremes of scale! Neat.


So in case of non-bitcoin-peg coins it seems similar to bitcoin-peg-only case, all security will have to ensure the costs of attacks (i.e. purchasing power from any source - energy or coin based) are still larger than cost of total value transfer which in extreme case is just basic PoW incentives. But we already see that now due to meta tokens like USDT on some chains outgrowing native assets. Before we could ignore the transferred value of non-native assets but as they become statistically significant, they have to be included into attack-cost security considerations. Same with childchains - they can be ignored until they matter. By that point, you're likely to be quite aware of them not to forget.

Ardor child chains are described as `All transactions are processed and secured by the parent chain forgers` which is exact opposite of what's suggested here and I think vitally important for Bitcoin security - we do not want to force parent chain to process every childchain version as it would become no different of a security issue than having unlimited block size & risks with childchain bugs. Additionally without the burn, there's no mechanism to provide an alternative source of Bitcoin for the peg and have to rely on questionable pegs.

One thing that would be really helpful on Bitcoin is signature aggregation to make it easier to combine many small outputs for withdrawals, but that's planned regardless.

Theoretical design possible today presented for review. Please be brutal.

Permissionless Bitcoin Childchains w/ Continuous Proof of Bitcoin Burn (CPoBB) and 2-way-value-pegs (2wvp)

Basic idea:

Childchain consensus on chain-tip is reached via highest total accumulated burn, possible today. Queue of withdrawals from childchain is filled as required for childchain block validity from a fixed fraction of amount burned. Deposits onto childchain require separate independent from consensus Bitcoin burns.  Combined this allows childchains with enforced 1:1 coins value peg in both directions (2WVP).


Summary:

- Bitcoin can be the parent chain - highly secure and light PoW chain as it is today with no changes and no awareness of childchains
- Childchains will arrive at consensus on chain-tip based on total accumulated burned Bitcoin in return for childchain fees (simulating PoW sunk costs via sunk costs of burning Bitcoin)
- The child-to-parent-peg for childchain (cBTC) to Bitcoin (BTC) works by diverting a small fraction of burnt Bitcoins used for block commitments to reimbursing withdrawals over time (burning cBTC).
- The parent-to-child-peg for BTC to cBTC is done via a completely independent from block commitments BTC burns that generate equal number of cBTC.
- Both directions provide long timeframe 2-way-peg of creating/destroying ~1:1 valued assets w/ security on scale of burns over time. Atomic swaps provide short-time frame swaps between existing already 2wp assets.
- With no effect on or risk to mainchain, this would allow any degree of complexity to be anchored into Bitcoin, remain completely optional, and all risks and security scale with its own demand and some of Bitcoin's security.
- This inherits and simulates most of PoW benefits without additional energy costs for any number of childchains or any number of users without any of PoS downsides
- All Bitcoin owners would see Bitcoins becoming more scarce and thus more valuable

Childchain block producers and rewards:

Each childchain producer (burner) that's willing to burn Bitcoin will be assembling blocks and once ready will create a secret they will commit to the Bitcoin mainchain.
The new childchain blocks are not propagated until after there's a confirmation of commits on Bitcoin mainchain to hide the childchain commits from miners.


After the Bitcoin block is created, the childchain blocks are propagated.

The secret is then calculated from childchain block headers and is matched to burn commit transactions.
Chaintip chosen for the childchain is by most amount burnt by a commit for a valid known block, tie break is by first seen by height and further by tx order.
When presented with multiple childchain chaintips (at different bitcoin mainchain blockheight), one is chosen by the highest total amount burnt (simulation of total accumulated work).

Total accumulated burn is easily calculated for each chain tip and provides similar incentives as using total accumulated work, only 1 layer higher.

Most likely tx78 is picked due to most burn at which point the block content is validated. (validating every block version every time is not necessary, only winners)
If the tx78's block is valid, the fees of that block's tx are distributed based on amounts burnt.
If the block is invalid (e.g. if tx124 was picked by hash) it's removed from all consideration and a new block is picked same way as before. (tx124 burner gets nothing)

Let's say tx78's block was picked & tx124 block wasn't so 0.8 cBTC in simplest design are distributed to winner.

However, some fee smoothing is ideal to reduce the load on mainchain and overshooting or undershooting the amounts burnt each Bitcoin block.
This way the burning doesn't have to happen every block and accidentally participating in a block with too many burners can be used to even out the diluted rewards.
Additionally there's then always an expected minimum fee payout for a future block even if there are too few transactions.

With fee smoothing 0.8 cBTC is added to fee pool (can be stored in the header) and let's say 50% of fee pool is distributed each round based on amounts burnt in last 6 blocks (arbitrary number used for example).
At steady state and on average the new tx fees added would be roughly the total fee payout in each block.
The distribution of fees this block would have to be part of next block in order for next block to be considered valid (either implied during this block or as part of coinbase tx in next block)


2-way Bitcoin peg

First of all, the deposits onto the childchain are always simplest: burning Bitcoin (separate from commits) on mainchain is seen as a signal to create equal amount of cBitcoin on childchain for designated recipient.
The withdrawals of Bitcoin to childchain are the hard direction, but as drivechain's design suggested, doesn't have to be fast. Withdrawal's job is to provide the equal value on mainchain to enforce the peg even if it takes a long time to withdraw. Once the value of pegs is fixed in both directions, the trade between existing cBTC and BTC can be done independent of peg process and much faster via atomic swaps, subatomic channel trades, and so on.

There is no multisig pool and thus no people in charge of collaterals to worry about nor any oracles to collude.
Instead, the childchain Bitcoin (cBTC) value is kept by a childchain queue funding those withdrawals over time from the sidestream off burning transactions.

Let's say the childchain validity requires all commits to put between 10 to 20% of Bitcoin intended for burning into paying off the withdrawal queue. The number is a range so that the ratio between burning and fee can't be used to ID the childchain commits & can be picked at random with total spent being same either way. Let's also cap the withdrawals to not payout more than 50% of each withdrawal balance left.

Using those example design parameters this is what might see:

Note how overpaying A is not a big deal since we're not limited by a 1:1 pool to keep the peg. In fact his original withdrawal might've been much higher so wasn't overpaid significantly.

Hiding commits and withdrawals on childchain from miners until they are confirmed:

Simplest burning would just use OP_0 OP_RETURN type transactions with non-0 value.

Obvious burns and commits could be used as means to censor childchains by miners potentially seeking those transaction fees. Since they can't get around burning Bitcoin to access those, miners do not have significant advantage to win burns. To avoid miners censoring the childchain, fraction of the fees paid out on child chain must be paid to winning main chain miners on the childchain (e.g. 50%). This provides incentives to miners to support child chains without having to mine them. Withdrawals from childchain to main chain also requires other burners helping the child chain propagate safety.

If miners see obvious burning they can guess it's a childchain transaction. To hide that, provable burns can be hidden inside scripts. Various ideas of hiding burns are possible including varations on BMM or this:

The withdrawal and commits can be hidden as any P2SH and P2WSH transaction output as such:

BTC withdrawal output:

Provably unspendable burn output:

In other words, when users withdraw btc from 2 way peg on main chain (that are present in every burn whenever there's anyone withdrawing still), they reveal the secret that can be used to determine the output script is just a number and then op_false and that output can be forgotten.

The withdrawal of BTC reveals the secret as part of redeem stack that can be used to prove op_false script in burn output even without having the full blocks from childchains.
Ideally the effective batching of many transactions fees on childchains for paying burners that can then pay higher transaction fees on mainchain will be reason enough for miners to not mind their use.
The outputs for withdrawals can ideally be batched even easier by recipients after schnorr soft fork on BItcoin.

If that's too complicated, just burn by any regular more obvious means. As long as miners get paid, there's little reason to censor childchains.

Transactions on childchain:

The childchain clients would be built on top of or combined with a Bitcoin client and be fully Bitcoin-aware.
The childchain network transactions and childchian blocks containing them would be broadcast in 2 ways:
1) over their independent network of nodes
2) embedded in Bitcoin network as optional backup for data availability

The fees in transactions would be paid in cBTC. To minimize frequency of having to use the Bitcoin chain for commits, all the fees would go into a fee pool and be distributed over a specific period.
The rules for transactions in childchains can be anything they want otherwise. Childchain transactions embedded on Bitcoin would likely have to be at least the most important ones like requests for withdrawals to mainchain to make all childchain nodes aware it was made and render blocks not including them as invalid to avoid burner censorship.

Burning pools:

To avoid the issue of larger burn amounts easily winning over many smaller burn amounts, burning pools can be used. Combine burns with PSBT from many people for child chain commit they agree with. Unlike some mining pools, it's quite obvious what child block hash they are signing.

---

This work was previously written up by me here https://bitcointalk.org/index.php?topic=5212814.msg53482314#msg53482314 but as it started not as a pure Bitcoin peg I didn't feel comfortable posting it here. However, as thought experiment progressed, I would like to see opinions on this method. Please look there for considerations of withholding childchain blocks attacks, measuring security of childchains, avoiding weak subjectivity, censorship, and many other concerns I had.

Please post here if you find major issues or not, possible attacks, let's see if this makes any sense to pursue, a sanity check of sorts. Wanted to get the views for it on a pure Bitcoin board.

I think this might be the best approach to optional infinite complexity and expressiveness on Bitcoin without any security compromises to the main chain nor the countless issues of inferior consensus systems.
Best of all it's possible today.

See you space cowboy

--- edit changes ---

- should pick 1 winner per child height for most burned. pick chain tip by total accumulated burn only.
- paying all burners would cause small burns for same child height revealed/posted later to change fee payouts and makes no sense. only pay winner

--- to review ---

- fee smoothing needs bit of rework
- must show boundary conditions at ~0% adoption and ~100% adoption including paying fraction of fees to main chain miners to keep them vested and paid
- considerations for bmm style single tx chain commits (need ctv or similar soft fork to only allow single output and avoid wasted burns)

Proof of Stake is not trust minimized by design and isn't any different from any permissioned database where someone has to let you in and decide how much control you get.
You literally cannot enter into proof of stake as an independent without someone choosing to permit you access by choosing to give up some coins to give you or sell you.

Without permissionless entry you cannot guarantee a single trusted party or a trusted party of insiders at that point can't prevent anyone independent who disagrees with them from entering which renders it permanently centralized in control to internal party (from time it starts)

Proof of Work is the only known solution for this at this point as it's based on unfakeable metrics outside of the network that not only lets anyone enter but forces costs on them so they give up coins to even more people. Proof of Stake is entirely internal and thus not safe.

Additionally, on top of being permissioned by design, staking reward is literally incentivised centralization of control. You can grow % you control by staking by taking advantage of the fact that anyone not staking loses control.

Additionally, Proof of Work difficulty adjustments on average guarantee miner costs are approximately equal to their reward, it incentivizes the sale of coins to cover those costs which leads to improved distribution of control and miners reliance on the markets made of users to buy those coins from them at high value. Misbehavior by miners on any chain or fork would be met with decline in dollar value of rewards they depend on and thus cost them ability to cover their sunk costs. Proof of stake has no mechanism to incentivize stake owners would want to sell any coins.

Additionally, Proof of Work equipment ages out and causes massive costs of equipment to be continuously paid by miners, not just electricity. This allows replacement of miners who were unable to cover their costs over time and most attacks are expensive can be waited out. Proof of Stake holders can hold on forever.

So let's summarize:

Proof of stake allows permanent control with no incentive to give it up, the payouts actually reward growth of centralized control, entire system is always permissioned, and thus cannot be trust minimized or decentralized.

Proof of Work costs energy and yet is the best and only solution for Bitcoin we know of that has none of the above mistakes.

Further analysis of various issues and solutions:

Many worries about drivechain design involved them being required to process and mine it for fees to compete against other miners who are getting that side income without expending additional work, some even called it "attack on miners" for incentivising bandwidth costs of being sidechain aware. Since there's no federation to worry about, their ability to steal isn't there. Alternative threats to consider are possibly censorship and taking over the childchains. Let's examine taking over the childchains threat first.

Miners could desire those additional fee revenues and take over chilchains. Since this process relies on burning Bitcoin, it applies to miners like everyone else, and thus has high costs. The only real unique discount they can get is the mainchain fees back, but not the burnt Bitcoin which is most important. Perhaps, since this would still bring some fees to mainchain from burn commits and the childchain tx are likely there in first place to avoid high fees, those accumulated fees on childchain were unlikely to bring revenue to miners either way and the fees that do end up on mainchain are paid for indirectly by the effective batching of childchain fees that attracts burners. Furthermore, if the childchain tx are used for unique rules the child chain has (like virtual machines or stateful smart contracts), that's just another source of demand for mainchain this allows it to get.

Miners could see childchain as a threat to take away their fees, but would only be significant at high rate of childchain use and thus high rate of Bitcoin burn. Fee specific rules are dangerous if they become predictable for miners to detect in case of censorship attack by miners (like if rule is 10% of burn is fee, and miner detects output that paid 10% in fees of its value, they can try to censor all such tx to kill childchain). In fact, hiding childchain interactions with Bitcoin is important and fees are likely to be taken care of by demand.

Here's a strategy to hide childchain transactions on mainchain, use outputs that appear like many others.

For previous examples I suggested using OP_RETURN to be provably unspendable for commits and simple send to address for withdrawal fills.

Hiding from miners like in BMM could be more secure so similar can be achieved in theory by P2SH where all you see is a hash of a script in ScriptPubKey of 1+ outputs in mainchain tx that looks like any other P2SH. (I'll use P2SH terminology but P2WSH would work as well)
That hash could hide all kinds of information.

Burners are best expected to commit to Bitcoin before broadcasting the childchain block. The burn and the withdrawal filling tx could be hidden as P2SH. Withdrawal P2SH would allow recipient to spend it after the childchain block is propagated. When recipient withdraws from that output they would reveal a secret that could be used to determine that the burn output is provably unspendable as script always evaluates to false. To avoid detection by miners via known ratio of burned Bitcoin to withdrawal BItcoin, the exactly 20% example rule diverted to withdrawals should be a flexible range like 10%-20%. The total amount burner spends doesn't change but burner is free to pick a random ratio within a popular range to hide himself. When withdrawal happen and redeemscript and secret are fed into it, secret becomes public knowledge, and it could be a notice that the other is the standard burn output that could be verified with the known secret as unspendable.


P2SH script for withdrawal output:


P2SH script for burning


The secret in burning script helps randomize the hash of that script that's visible in its burn output script, but it always ends up with a false at top of stack and fails.
Feeding withdrawal p2sh the secret makes second derivable based on standards childchain uses. sha256 I believe is less costly than signature validation so it is checked first to save on computation if it fails.
Nodes would still need to know to check for this childchain burn script but they don't have to monitor the childchains to find the secret to prove the burn utxo prunable (so no higher bandwidth use requirement).

What if fees on mainchain are larger than income from fees on childchain?

- Childchain is likely to have capped blocksize or gas limit of some kind, but would allow miners to pick best paying tx to fill childchain blocks. Burners could wait until childchain fees accumulate or rise high enough to make burning worth it - could be 1000s of childchain tx fees to cover the single bitcoin fee and compensating bitcoin burners. Ideally childchain would also have mechanisms to replace fees to let them grow if necessary.

What about issue with some blocks with too many burners and some blocks with too few as it's hard to predict others behavior before the block is mined?

- The fees payouts can be averaged out slightly with a simple formula. All the fees from each block could go into a childchain fee pool state from which payouts to burners are made. The total of 50% of current fee pool can be paid out total each block creating a predictable minimum payout schedule even if all childchain tx were to suddenly stop. Instead of only paying out to the burners in each block, the payout could be to amount burnt by A in previous N (e.g. 6) blocks. At steady state pool consumed would be same as new fees gained.

The payout to burner A for example would be calculated like this each block:


What about projects that already use another coin other than Bitcoin but want to migrate and switch to pure Bitcoin childchain?

- could do a design where you let let's say 20% of fees be paid by the altcoin where it's burnt to phase it out but allows a max of same 20% capacity per block so the additional capacity doesn't take fees away from miner. The value of altcoin could be set to be a specific amount of sBTC, bytes, or gas for those fee considerations depending how chain measures it. Most important is that it doesn't take away from miner sBTC fees hence added capacity just for those tokens. It's more work to pay with it but it's also helpful for those already with them. As they are burnt they become less important on transition to pure sBTC use. This could be used to transition away from unsecure premined coins to trust minimized supply.


I'm not sure this will be a good idea, but if pure fee only childchain scares people, there are things they can do w/o compromising the mainchain - benefit of a well defined base mainchain to add onto:

Let's call this hypothetical coin "Inflation Bitcoin" "IBC" (to avoid confusing people that it's same as non inflationary bitcoin, this doesn't exist, I just made it up for this example).
You can create a block reward that pays in IBC, let's say 0.0002% of total IBC supply per block which should roughly be equal to about 10% inflation per year.
You create those IBC out of nothing (gasp) to give to burners (e.g. via fee pool) which devalues all other IBC. The network tracks total Bitcoin still deposited vs total IBC that exists.
While it starts with those equal, slowly over time total ICB becomes larger, and the ratio between those values can be used for conversion on withdrawals and deposits.
Effectively it simulates the dilution you see from block rewards but that's limited to only the childchain. And while the value of the pegged coin is still proportional to Bitcoin, it's offset by ever changing inflation factor.
I think it's a bit confusing to call it anything resembling Bitcoin when it has permanent inflation but this demonstrates the flexibility with the peg childchains can have if they choose to.
Technically, it might even work in the opposite direction where the peg is changed to increase in value over time (e.g. 5% per year like HERO) with main issue being the withdrawals would take longer to fill.
I haven't thought all the possibilities for this through yet but I welcome discussions.

---
If I forget to credit you after a discussion or forget or don't realize I have to credit someone else, lmk.

Further thoughts on how to do childchains w/o an altcoin, only Bitcoin 2-way-peg:

I summarized main points here https://bitcointalk.org/index.php?topic=5214173.0 after writing this and following post in this thread

What's the incentive to burn Bitcoin to commit the childchain tip hash without getting something for it?
Perhaps to secure your own transaction or perhaps fees.

But then what's the incentive to pay more than minimum possible to achieve that?
Maybe competition for fees or only outpaying someone else who's censoring

What if we found a way to recover the costs of burning? Perhaps via child chain fees as a sort of pure fee based 0 new emission similar to endgame Bitcoin design.
Otherwise the reasons not to censor transactions of others or expend costs on validating/committing those become very small if you can't recover value to cover sunk costs.

Let's say for case of mainchain-BTC (Sats = 1e-8 BTC) and childchain-BTC (cSats = 1e-8 cBTC)


Both versions are valid so easiest design is to split all the childchain fees paid in cSats (2/3 to A, 1/3 to B) and Burner A's block version is picked deterministically (bc he burned most or hash of btc block gave him higher chance by burning more).
(but if they are solo committer, they get to recover all their childchain fees, is this an issue? not really. still costs from burning minimums and bitcoin chain fee)

Can't depend on fee market early on so need to have minimum fee rate set 1 cSat/byte (or different but well defined costs for bytes, op codes, so on)
Ofc, like on mainchain, growing larger through competition over capped block size from childchain's choice of bandwidth security considerations.

When they want to withdraw cSats and create childchain tx for it, future burners are required to allocate (let's say) 20% from total to filling withdrawals.

Let's examine a future block that includes earlier withdrawal signal on childchain
where 200 cSats was burned to withdraw 200 Sats on mainchain:


I think over time A would recover his withdrawal.
To deposit 100k Sats to childchain you burn 200k Sats to deposit unspendable address on Bitcoin independently (6x confirms?) and are simply required to be issued 200 cSats by nodes and childchain block commiters in order to be considered valid who are all Bitcoin-aware.
(I wish there was a way to do this by creating provably unspendable and prunable utxo on Bitcoin. There will definitely need to be safely above-dust minimums for Bitcoin utxo)

Like drivechain's truthcoin suggests, requiring long deposit and withdrawal times is acceptable for holding the peg, it's job is to secure the hardest childchain to Bitcoin direction to hold the price.

Trading cBTC vs BTC is separate and can be done via atomic swaps or even sidechain dex's via primites like atomic swaps or simple x-confirmations rules that are all Bitcoin aware and don't need to issue coins, just trade existing coins.

What's the vulnerabilities or attack vectors here?

There's no multisig-federation account to worry about, no oracles to collude, Bitcoin miners or nodes aren't required to do anything different.
Bitcoin miners could censor it like they could censor any account but miss out on fees, could try to obfuscate burning and childchain identifiable features until after confirmations (e.g. BMM work)

Rate of childchain recovery for the peg clearly depends on rate of burning, which itself depends likely on childchain fee income that would grow with popularity.
Hence users should understand the risks of deposits/withdrawals/holders scale inversely proportional to burn rates and childchain fees.

Childchain commiter's censorship of deposits would render those childchain blocks invalid.
Childchain commiter's censorship of withdrawals after the signal would render those childchain blocks invalid.
Childchain commiter's censorship of signaling desire to withdraw is possible
  - a deterministic random function to select burner based on amount burned would allow other burners to get their tx through eventually
  - actively expending mainchain burning costs on censoring a childchain would hurt their ability to recover value from other users fees and burners, worst case rendering cBTC near worthless until they are broke and/or leave
  - source of burning of mainchain Bitcoin is finite so eventually runs out, so can be waited out much like a malicious censorship attack on Bitcoin
  - censoring childchain tx would also cost commiters the childchain fees (i.e. bribes)
  - withdrawals could be signaled on Bitcoin mainchain OP_RETURN that all nodes are aware of and childchain block producer alone can't censor thus forcing attacker to include it or be treated as irrelevant invalid commit missing out on all fees

What if there are no fees because no child chain tx? No need to commit blocks then.
What if there are only fees from 1 party? They can burn minimum amount to commit that block, recovering their child chain fee but still not free from burning main chain.

What if there are multiple versions of childchains bc no nodes were online or got disconnected or eclipsed or withheld?

Probably biggest risk so let's consider what happens after you have both versions of blockchain.

The burn transactions of commits for blocks you didn't have before that were considered invalid/useless before would make sense and the selection rule based on burn amounts will lead you to a single chaintip.
If childchain commits are identifiable, you would be aware if you see commits for your chain that you do not have blocks for and can weight their importance based on amounts burnt.

What if attacker commits blocks with big burn amounts but withholds actual blocks until later?

- the payouts for withdrawals aren't really an issue since overpaying from burning sidestream doesn't cause a shortage

- using N-blocks irreversible checkpoints could cause childchain fragmentation and thus weak subjectivity (e.g. which of 2 valid childchains is real childchain named X? which dev picks? why?)

- using deterministic random functions based on Bitcoin mainchain's header's hash at same height as commit for selection of childchain tip would make the attack less reliable over time as attacker's childchain block is not guaranteed to be the winner and could cause all the burns from that point onward invalid as they would use invalid childchain tip and total loss. Attacker has no way to know bitcoin's future block header hash when burning Bitcoin for a commit transaction. If burning Bitcoin is detectable in general, unclear sources of burnt Bitcoin could be used as an early signal of a threat.
So attacker's best bet is to do a single large burn for a lower childchain blockheight at which ideally there was the least amount of non-attacker Bitcoin burnt? Still costs Bitcoin, and could ruin his chances to recover any childchain value from withdrawals. Consensus over the childchain tip would then be best determined by chaintip with most bitcoin burnt (a running total) and not simply childchain height which can wildly fluctuate in costs block to block.

- using the above, security of the chaintip, much like its ability to hold a peg, could be measured in total accumulated Bitcoin burned of valid commits so not rely on weak subjectivity. Users or businesses accepting assets on such a childchain should consider security significant after the total value of sent assets in that childblock is less than total value burnt at a later point's chaintip.

- the reasons for avoiding subjectivity and thus avoiding the use of N-blocks checkpoints appear similar.

- maybe pre-programmed early phase reliance on N-blocks checkpoints that disappear over time might be acceptable as means to bootstrap the network while it's very small and well connected?
  checkpoints can be triggered to permanently off when some total amount burned hits a number first time as well.
  checkpoints could also be determined using amount of known Bitcoin burnt instead of block height: e.g. after 1 BTC burnt after a block, that block is irreversible. that threshold increases each block by X% until it approaches 21M BTC and thus turns off (X=100% would mean it turns off in ~24 blocks based on 1*2^N=21m)

Basically could go with checkpoint security (similar to what PoS chains are forced to use) where you choose irreversible checkpoints at Z BTC burnt or N blocks thus inheriting reversibility-resistance properties of Bitcoin but face consequences of weak subjectivity if you're not well connected. (i.e. having to subjectively decide which version of irreversible childchain blocks is real one)

OR, more importantly, something PoS cannot do but much like PoW, is avoid weak subjectivity by always using childchain tip with most total Bitcoin burnt - very costly to fake metric from Bitcoin unfakeable costs of doing work in Proof of Work. It also still inherits censorship resistances of Bitcoin that allow permissionless entry into producing childchain blocks via Bitcoin transactions, also something PoS cannot guarantee since it doesn't have any unfakeable external sources of information. It's not going to inherit full Bitcoin resistance against reversibility and depend on it's own total-burn degree of security but it ALREADY relies on that for the peg to work and the ability to have the trust minimized bi-directional peg in the first place should be advantage enough to this method.

XCP-like fully embedded protocols don't have to worry about separate withheld childchain blocks as all data is available on Bitcoin chain and could require burning of bitcoin instead of altcoin for the backwards peg.
Tradeoff is it limits you to only using BTC tx to create separate state with limited space for verbose customizable contract code for programmable money within that state and high costs.

UTXO growth from many small withdrawals and burns would be improved via giving prunable ways to provably burn Bitcoin (like in OP_RETURN outputs) and ways to sign all inputs with a single signature via schnorr softfork to make those inputs far easier to batch.

No altcoin necessary in this design!!

Please poke holes in this!



For future considerations or open question I haven't had time to think through?

- what about reverse checkpoints? childchain blocks are not reversible until chaintip burns X Bitcoin total since that childblock? This would give some minimum cost to reversals and thus increased degree of security guarantees without being reliant on weak subjectivity. Attacker would have to burn either himself or wait for others to burn X Bitcoin before he can double spend where he also has to burn at least X Bitcoin to double spend preventing cheap and low cost reversals. The scale of X could be set always same as (or proportional to) the total amount of childchain cBTC in existence which is most that can be double spent not considering childchain possible tokens or w/e.

- I should include considerations of following for attackers: income from childchain fees, costs of withdrawals where lower withdrawal % sidestream might be better, and how withdrawals can be abused to recover some costs for choices of high withdrawal % sidestream

no thats my address with keys of which I can sign stuff if necessary, seemed easier than PGP key

burn addresses should not be spendable (but still checksum correctly) and that clearly is a regular address. I'll mark it as such. removed completely.

disclaimer should probably be next after title to clarify I'm not making a shitcoin, there's no burn address or any shitcoin yet or planned. this is just a design.

point is with even 1 pool the network would be relatively safe as the costs for attack would be significant for miners (who could just switch to another pool they make if it's the operator causing issues)

either way miners answer to the users via the market or they lose money they can't recover

similar,

but instead of burning for a few weeks only and then allocating tokens,

you do burning and allocating tokens every block continuously

and also use that transaction to commit your sidechain block hash

and use burning of coins as metric for consensus mechanism instead of burning of energy/capital via proof of work.

let bitcoin handle the proof of work, no need to reinvent a wheel in less secure manner.

best part about counterparty distribution is unlike every ICO the costs couldn't be faked.

miners have sunk costs and depend on selling coins to cover the sunk costs

at equilibrium the coin rewards and costs are nearly equal, forcing sale of majority of coins

by selling coins miners depend on the users on the market to give them value

if coin owners don't like what miners are doing, they can sell the coins costing miners money so miners are unable to cover sunk costs

miner abuse could easily cause a fork via algorithm change or user activated forks

then coin owners can sell only on specific forks to effectively
1. crash the security of that chain
2. profitability of miners on that chain (i.e. losses)
3. crash value of every owner of coins on that chain (exodus)

Big difference in 25 coins/block worth $7000 each and 25 coins/block worth $1 each

miners answer to users, both depend on each other.

faster blocks just means they are easier to revert, and likely there will be competing blocks doing it accidentally given a small window to propagate the new block.

no matter the block time, what counts is accumulated work on top of the block for the cost backing its finality

Continuous Proof of Bitcoin Burn for securing separate blockchains, optionally acting as Bitcoin childchains via Bitcoin-pegged tokens without a need for a federated bridge or oracles.



Disclaimer:

This is not an altcoin thread. I'm not making anything. The design discussed options for existing altcoins and new ways to built on top of Bitcoin inheriting some of its security guarantees. 2 parts: First, the design allows any altcoins to switch to securing themselves via Bitcoin instead of their own PoW or PoS with significant benefits to both altcoins and Bitcoin (and environment lol). Second, I explain how to create Bitcoin-pegged assets to turn altcoins into a Bitcoin childchain equivalent. Let me know if this is of interest or if it exists, feel free to use or do anything with this, hopefully I can help.

Issue:

- how to create continuous sunk costs, permissionless entry, high cost of attacks?
- how to do it without needing to build up a new source of hardware capital or energy costs?
- how to peg another chain's token value w/o incentivized collusion risk of federation or oracles?
- how to make childchain use fully optional for all bitcoin parties?
- how to allow programmable Bitcoins w/ unlimited permissionless expressiveness w/o forcing mainchain into additional risks?

Solution to first few points:

- Continuous Proof of Bitcoin Burn (CPoBB) to distribute supply control and childchain consensus control to independent parties
- Distributes an altcoin for permissionless access and childchain-only sybil protection.
- In case of childchain block-producer censorship, Bitcoin's independent data availability makes childchain nodes trivially aware

PoW altcoin switching to CPoBB would trade:

- cost of capital and energy -> cost of burnt bitcoin
- finality of their PoW -> finality of Bitcoin's PoW
- impact on environment -> 0 impact on environment
- unforgeable costliness of work -> unforgeable costliness of burn
- contract logic can include conditions dependent on real Bitcoins as it's Bitcoin-aware

PoS altcoin switching to CPoBB would trade:

- permissioned by coin holders entry -> permissionless entry by anyone with access to Bitcoin
- no incentive to give up control or sell coins -> incentive to sell coins to cover the cost of burnt bitcoin
- incentivized guaranteed centralization of control over time by staking -> PoW guarantees with same 0 environmental impact
- nothing at stake -> recovering sunk costs at stake
- contract logic can include conditions dependent on real Bitcoins as it's Bitcoin-aware

We already have a permissionless, compact, public, high-cost-backed finality base layer to build on top - Bitcoin! It will handle sorting, data availability, finality, and has something of value to use instead of capital or energy that's outside the childchain - the Bitcoin coins. The sunk costs of PoW can be simulated by burning Bitcoin, similar to concept known as Proof of Burn where Bitcoin are sent to unspendable address. Unlike ICO's, no contributors can take out the Bitcoins and get rewards for free. Unlike PoS, entry into supply lies outside the alt-chain and thus doesn't depend on permission of alt-chain stake-coin holders. It's hard to find a more bandwidth or state size protective blockchain to use other than Bitcoin as well so altcoins can be Bitcoin-aware at little marginal difficulty - 10 years of history fully validates in under a day.

What are typical issues with Proof of Burn?

- limited burn time window prevents permissionless entry in the future. how many years did it take for most heavily mined projects to become known and well reviewed? many. thus entry into control of supply that's vital to control of chain cannot be dependent on the earliest stage of the project. (counterparty)
- "land grabs" "rent seeking" - by having limited supply without continuous emission or inflation we encourage holding vs spending (assuming goal is security vs spam/sybil and not SoV which Bitcoin does best already).

Solution:

- These issues can be fixed by having Proof of Burn be permanently accessible and continuous: Continuous Proof of Bitcoin Burn CPoBB

This should be required for any design for it to stay permissionless. Optional is constant fixed emission rate for altcoins not trying to be money if goal is to maximize accessibility. Since it's not depending on brand new PoW for security, they don't have to depend on massive early rewards giving disproportionate fraction of supply at earliest stage either. If 10 coins are created every block, after n blocks, at rate of 10 coins per block, % emission per block is = (100/n)%, an always decreasing number. Childchain coin doesn't need to be scarce money, and could maximize distribution of control by encouraging further distribution. If no burners exist in a block, altcoin block reward is simply added to next block reward making emission predictable.

Childchain block content should be committed in burn transaction via a root of the merkle tree of its transactions. Childchain state will depend on Bitcoin for finality and block time between commitment broadcasts. However, the throughput can be of any size per block, unlimited number of such childchains can exist with their own rules and validation costs are handled only by nodes that choose to be aware of a specific childchain by running its consensus compatible software.

Important design decision is how can protocol determine the "true" side-block and how to distribute incentives. Simplest solution is to always :

1. Agree on the valid childchain block matching the merkle root commitment for the largest amount of Bitcoin burnt, earliest inclusion in the bitcoin block as the tie breaker
2. Distribute block reward during the next side-block proportional to current amounts burnt
3. Bitcoin fee market serves as deterrent for spam submissions of blocks to validate

e.g.


Validity is deterministic by rules in client side node software (e.g. signature validation) so all nodes can independently see version 3 is invalid and thus burner of tx124 gets no reward allocated. The largest valid burn is from tx78 so version 2 is used for the blockchain in childchain. The total valid burn is 1.06 BTC, so 10 altcoins to be distributed in the next block are 0.094, 0.472, 9.434 to owners of first 3 transactions, respectively.

Censorship attack would require continuous costs in Bitcoin on the attacker and can be waited out. Censorship would also be limited to on-childchain specific transactions as emission distribution to others CPoB contributors wouldn't be affected as blocks without matching coin distributions on childchain wouldn't be valid. Additionally, childchains can allow a limited number of childchain transactions to happen via embedding transaction data inside Bitcoin transactions (e.g. OP_RETURN) as a way to use Bitcoin for data availability layer in case childchain transactions are being censored on their network. Since all childchain nodes are Bitcoin aware, it would be trivial to include.

Childchain blocks cannot be reverted without reverting Bitcoin blocks or hard forking the protocol used to derive childchain state. If protocol is forked, the value of childchain coins on each fork of childchain state becomes important but Proof of Burn natively guarantees trust minimized and permissionless distribution of the coins, something inferior methods like obscure early distributions, trusted pre-mines, and trusted ICO's cannot do.

More bitcoins being burnt is parallel to more hash rate entering PoW, with each miner or burner getting smaller amount of altcoins on average making it unprofitable to burn or mine and forcing some to exit. At equilibrium costs of equipment and electricity approaches value gained from selling coins just as at equilibrium costs of burnt coins approaches value of altcoins rewarded. In both cases it incentivizes further distribution to markets to cover the costs making burners and miners dependent on users via markets. In both cases it's also possible to mine without permission and mine at a loss temporarily to gain some altcoins without permission if you want to.

Altcoins benefit by inheriting many of bitcoin security guarantees, bitcoin parties have to do nothing if they don't want to, but will see their coins grow more scarce through burning. The contributions to the fee market will contribute to higher Bitcoin miner rewards even after block reward is gone.

Childchain Bitcoin-pegs:

What is the ideal goal of the childchains? Ideally to have a token that has the bi-directionally pegged value to Bitcoin and tradeable ~1:1 for Bitcoin that gives Bitcoin users an option of a different rule set without compromising the base chain nor forcing base chain participants to do anything different.

Issues with value pegs:

- federation based pegs allow collusion to steal bitcoins stored in multi-party controlled accounts
- even if multisig participants are switched or weighted in some trust minimized manner, there's always incentive to collude and steal more
- smart contract pegs (plasma, rollups) on base chain would require bitcoin nodes and miners to validate childchain transactions and has to provide block content for availability (e.g. call data in rollups), making them not optional.
- bitcoin nodes shouldn't be childchain aware so impossible to peg the value

Let's get rid of the idea of needing Bitcoin collateral to back pegged coins 1:1 as that's never secure, independent, or scalable at same security level. As drive-chain design suggested the peg doesn't have to be fast, can take months, just needs to exist so other methods can be used to speed it up like atomic swaps by volunteers taking on the risk for a fee.

In continuous proof of burn we have another source of Bitcoins, the burnt Bitcoins. Childchain protocols can require some minor percentage (e.g. 20%) of burner tx value coins via another output to go to reimburse those withdrawing side-Bitcoins to Bitcoin chain until they are filled. If withdrawal queue is empty that % is burnt instead. Selection of who receives reimbursement is deterministic per burner. Percentage must be kept small as it's assumed it's possible to get up to that much discount on altcoins emissions.

Let's use a really simple example case where each burner pays 20% of burner tx amount to cover withdrawal in exact order requested with no attempts at other matching, capped at half amount requested per payout. Example:


Withdrawal requests can either take long time to get to filled due to cap per burn or get overfilled as seen in "request1" example, hard to predict. Overfilling is not a big deal since we're not dealing with a finite source. The risk a user that chooses to use the childchain pegged coin takes on is based on the rate at which they can expect to get paid based on value of altcoin emission that generally matches Bitcoin burn rate. If childchain loses interest and nobody is burning enough bitcoin, the funds might be lost so the scale of risk has to be measured. If Bitcoins burnt per day is 0.5 BTC total and you hope to deposit or withdraw 5000 BTC, it might take a long time or never happen to withdraw it. But for amounts comparable or under 0.5 BTC/day average burnt with 5 side-BTC on childchain outstanding total the risks are more reasonable.

Deposits onto the childchain are far easier - by burning Bitcoin in a separate known unspendable deposit address for that childchain and childchain protocol issuing matching amount of side-Bitcoin. Withdrawn bitcoins are treated as burnt bitcoins for sake of dividing block rewards as long as they followed the deterministic rules for their burn to count as valid and percentage used for withdrawals is kept small to avoid approaching free altcoin emissions by paying for your own withdrawals and ensuring significant unforgeable losses.

Ideally more matching is used so large withdrawals don't completely block everyone else and small withdrawals don't completely block large withdrawals. Better methods should deterministically randomize assigned withdrawals via previous Bitcoin block hash, prioritized by request time (earliest arrivals should get paid earlier), and amount of peg outstanding vs burn amount (smaller burns should prioritize smaller outstanding balances). Fee market on bitcoin discourages doing withdrawals of too small amounts and encourages batching by burners.

The second method is less reliable but already known that uses over-collateralized loans that create a oracle-pegged token that can be pegged to the bitcoin value. It was already used by its inventors in 2014 on bitshares (e.g. bitCNY, bitUSD, bitBTC) and similarly by MakerDAO in 2018. The upside is a trust minimized distribution of CPoB coins can be used to distribute trust over selection of price feed oracles far better than pre-mined single trusted party based distributions used in MakerDAO (100% pre-mined) and to a bit lesser degree on bitshares (~50% mined, ~50% premined before dpos). The downside is 2 fold: first the supply of BTC pegged coin would depend on people opening an equivalent of a leveraged long position on the altcoin/BTC pair, which is hard to convince people to do as seen by very poor liquidity of bitBTC in the past. Second downside is oracles can still collude to mess with price feeds, and while their influence might be limited via capped price changes per unit time and might compromise their continuous revenue stream from fees, the leverage benefits might outweigh the losses. The use of continuous proof of burn to peg withdrawals is superior method as it is simply a minor byproduct of "mining" for altcoins and doesn't depend on traders positions. At the moment I'm not aware of any market-pegged coins on trust minimized platforms or implemented in trust minimized way (e.g. premined mkr on premined eth = 2 sets of trusted third parties each of which with full control over the design).

---

originally drafted https://pastebin.com/bD7cggF6

Brief issues with current altchain options:

a. PoW: Additional PoW chains require high energy and capital costs to create permissionless entry and trust minimized miners that are forever dependent on markets to hold them accountable. Using same algorithm or equipment as another chain or merge-mining puts you at a disadvantage by allowing some miners to attack and still cover sunk costs on another chain. Using a different algorithm/equipment requires building up the value of sunk costs to protect against attacks with significant energy and capital costs. Drive-chains also require miners to allow it by having to be childchain aware and thus incur additional costs on them and validating nodes if the childchain rewards are of value and importance.
b. PoS: PoS is permissioned (requires permission from internal party to use network or contribute to consensus on permitted scale), allows perpetual control without accountability to others, and incentivizes centralization of control over time. Without continuous source of sunk costs there's no reason to give up control. By having consensus entirely dependent on an internal state, the network, unlike PoW but like private databases, cannot guarantee independent permissionless entry and thus cannot claim trust minimization. Has no built in distribution methods so depends on safe start (snapshot of trust minimized distributions or PoW period) followed by losing that on switch to PoS or starting off dependent on a single trusted party such as case in all significant pre-mines and ICO's.
c. Proof of Capacity: PoC is just shifting costs further to capital over PoW to achieve same guarantees.
d. PoW/PoS: Still require additional PoW chain creation. Strong dependence on PoS can render PoW irrelevant and thus inherit the worst properties of both protocols.
f. Tokens inherit all trust dependencies of parent blockchain and thus depend on the above.
g. Embedded consensus (counterparty, veriblock?, omni): Lacks mechanism for distribution, requires all tx data to be inside scarce Bitcoin block space so high cost to users instead of compensated miners. If you want to build a very expressive scripting language, might very hard & expensive to fit into Bitcoin tx vs CPoBB external content of unlimited size in a committed hash. Same as CPoBB is Bitcoin-aware so can respond to Bitcoin being sent but without source of Bitcoins like burning no way to do any trust minimized Bitcoin-pegs it can control fully.

Few notes from discussions:

- fees must be high to be included in next block (and helps pay and bribe bitcoin miners), RBF use is encouraged to cancel late transactions
- what if not enough burners, just passive nodes? you can burn smallest amount of bitcoin yourself when you have a transaction you want to go through
- using commit hashes on bitcoin to lock altcoin state isn't new (e.g. kmd) but usually those rely on some federation or permissioned proof of stake mechanism with no real costs. this is combination of both.
- this is not exactly like counterparty's embedded consensus as block data and transactions are outside Bitcoin, but consensus is derived with help of embedded on Bitcoin data.
- deterministic randomness (e.g. via that Bitcoin block's hash) could be used to assign winning childchain block weighted by amount burned to allow occasional blocks formed by others curbing success rate of censorship by highest burner
- blockstacks proposed similar methods as I just saw: https://blog.blockstack.org/video-reusing-bitcoins-hashpower-to-launch-the-stacks-blockchain/ https://blockstack.com/tokenpaper.pdf https://blockstack.org/whitepaper.pdf
    with many similarities (probably from where I vaguely got the idea)! but also major differences:
    - wants to transition away from using proof of burn via tunable proofs and native proof of work (whitepaper)
    - a dominant premine (trust maximized) relative to emission that defeats the purpose of distributing control over incentives (figure 3 in tokenpaper suggests premine still ~30%-70% by year 2050)
    - variable emission rate "adaptive mint and burn" makes supply unpredictable (and possibly gameable)
    - additional rewards that aren't trust minimized like "app mining" and "user incentives" possibly gameable with premine
    - election of a leader includes their own PoW to be elected even at start (5% cap), why lol?
    - blockstack also suggested use of randomness that depends on that block so Bitcoin miners that already spent energy mining that block can't just re-do it to get picked at no cost

Main questions to you:

- why not?
    (other than blocktime)

- can this be done without an altcoin?
    (Not sure and don't think so w/o compromising unforgeable costliness and thus trust minimization. At least it's not using an altcoin that's clearly centralized.)

- how to make it less detectable by Bitcoin miners?
    ( BMM could use some techniques described here: https://twitter.com/SomsenRuben/status/1210040270328254464 )
    ( Perhaps since childchain nodes receive proposed blocks independently and can figure out their hash, the commit message ( childchain id + block commit + miner address) can be hashed one more time before its placed on Bitcoin, making miners unaware until after Bitcoin block is found that this is that childchain's burn. Childchain block producers would have to delay childchain block propagation until after Bitcoin block is propagated, 10 minutes blocktime helps here. Hiding the fact that Bitcoin is burnt until after the fact is another possibly important matter. )

- Should reward be split between valid blocks?
    (Blockstacks approach does not reward blocks marked by different from leader chaintip. That seems dangerous since childchain tx sorting would be difficult to match and could take significant time to be compensated for perfectly valid work and coins burned. It doesn't seem as necessary in burning since we're not expending costs based on only one previous block version, the costs are independent of block assembly. Tradeoff is between making it easier for independent "mining" of childchain and making it easier to validate for full nodes on childchain)

open to working on this further with others

People still don't know bitcoin increased block size?

Size: 2.2 MB https://www.smartbit.com.au/block/540107

Now sitting at record high averages near ~1.2 MB https://bitcoinvisuals.com/chain-block-size

Limiting blocksize/time is a security feature above all else to address bandwidth and validation costs, with additional benefit that space scarcity drives fees that are meant to replace block reward eventually.

Block time change, by the way, would be a soft fork too (depends on definition).

Many exchanges finally batching as well which allows more throughput for others.

The next Schnorr, MAST, Taproot soft fork will reduce tx size as well allowing more throughput.

Various other current proposed BIP that can help deal with higher throughput:


Regardless, on-chain methods increase scaling linearly while off-chain offer orders of magnitude bigger scaling w/o compromising security of base layer. Even trust minimized solutions like rollups could technically be used as well, if not for bitcoin, then for token layers on embedded consensus and take them off chain.

my idea was here https://pastebin.com/U1fR92tY

but I just realized A can just not grab the rebate thus not paying for the file

best way to do this is then classic mutually assured destruction contract or transaction

like 2-2 multisig with specific output amount where each signs their input to create and both lose funds unless both sign the payment transaction from the multisig once both parties are happy.

having total output amount will assure both parties contributed enough to match the output or tx is always invalid, bond/refund from file provider is obviously smaller than payment. then either you form the multisig on chain and then depend on both parties being happy or you, both can lose money if either is unhappy, and money never leaves your account if the multisig transaction isn't formed.

as always most things are solved with multisig lol


____

sorry for bad link, was trying to erase the post but board didn't let me. thanks for link as well.