Filters are toggleable on top, descriptions available by clicking on % centralization



https://codepen.io/realcrypto/full/MWKgXYg

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

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).

"burn" - act of rendering coins permanently irreversibly unspendable by anyone
c- child chain (some refer to as side chain / sc), cBTC = childchain-BTC
m- main chain or parent chain, BTC or mBTC = mainchain-BTC

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.

secret = hash of ( childchain id & hash of childchain block header & other data like address miner wants to use on childchain for fees )

Bitcoin block contains the following content embedded and part of its transactions (more on hiding them later):

tx11: burns 0.01 BTC & <secret for valid childchain block version 1>
tx56: burns 0.05 BTC & <secret for valid childchain block version 1>
tx78: burns 1 BTC &  <secret for valid childchain block version 2>
tx124: burns 0.2 BTC & <secret for INVALID childchain block version 3>

Total fees paid in childchain block version 1 is 0.8 cBTC from however many tx

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)

Optional:  
cBTC payout to burner = (50% of cBTC fee pool) * (Bitcoin this burner burnt for winning commits in last 6 winning commits) / (total burns by last 6 winning commits by anyone)

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:

Withdrawal queue:

1. 10k sats to requester A
2. 200k sats to requester B.

Block commits:

Burner C
    burns 20k sats to commit his version of childchain block to Bitcoin (80%)
    sends 5k sats to A's withdrawal (20%)

Burner D
    burns 10k sats to commit another version of childchain block to Bitcoin (85%)
    sends 1.7k sats to A's withdrawal (15%)

Burner E
    burns 50k sats to commit another version of childchain block to Bitcoin (81%)
    sends 5k sats to A's withdrawal (8.1%) (hit 50% cap on 1st so paying out next one as well)
    sends 6.7k sats to B's withdrawal (10.9%)

A fully paid (overpaid)
B remaining balance is 200k-6.7k is now at top for next block's queue

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:

op_sha256 <sha256(secret)> op_equalverify
< recipient pub key > op_checksigverify

spender's scriptSig stack: their signature, <secret>

Provably unspendable burn output:

<secret>
op_drop
op_false

no spending script possible

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)

[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.]

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.

TLDR: Proposing the following that's possible today to use for any existing or new blockchains:

 * arriving at consensus AND distributing coins via burning Bitcoin instead of electricity/equipment to create permissionless, unfakeable, green, and trust minimized childchains.    
 * creating Bitcoin-peg from altcoin chain to mainchain (the hard direction) by allocating small percentage of Bitcoin intended for burning to reimbursing withdrawals

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.

childchain block reward is set always at 10 altcoins per block
Bitcoin block contains the following content embedded and part of its transactions:

tx11: burns 0.01 BTC & OP_RETURN <childchain id> <sha256 root of valid childchain block version 1> <childchain address for reward>
tx56: burns 0.05 BTC & OP_RETURN ... <...root of valid childchain block version 1> ...
tx78: burns 1 BTC & OP_RETURN ... <...root of valid childchain block version 2> ...
tx124: burns 0.2 BTC & OP_RETURN ... <...root of INVALID childchain block version 3> ...

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 queue:

request1: 0.2 sBTC
request2: 1.0 sBTC
request3: 0.5 sBTC

same block burners:

tx burns 0.8 BTC, 0.1 BTC is sent to request1, 0.1 BTC is sent to request2
tx burns 0.4 BTC, 0.1 BTC is sent to request1
tx burns 0.08 BTC, 0.02 BTC is sent to request 1
tx burns 1.2 BTC, 0.1 BTC is sent to request1, 0.2 BTC is sent to request2

withdrawal queue:

request1: filled with 0.32 BTC instead of 0.2 sBTC, removed from queue
request2: partially-filled with 0.3 BTC out of 1.0 sBTC, 0.7 BTC remaining for next queue
request3: still 0.5 sBTC

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

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.