Topic: Drivechain critiques by gmaxwell revisited, maybe you changed your mind? (Read 1110 times)

https://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki

The future is now. It is possible to make P2WSH address, which can be unlocked, if you grind your signature, to take less than N bytes (testnet4 example: tb1qzsjnew5qcn75e4cqdsc6r9v8fjy5ensancqmv2l2n82p0q5f5tls758l9d). Which means, that sidechain users can just prepare some state of their network, convert it to 256-bit number, expressed as some private key, and use its public key in the locking script.

Then, only sidechain miners will know the key upfront (and the latest state of their network, at the same time). They will grind spending transaction, until reaching enough Proof of Work, to move the coins. It is possible to use tricks like OP_CHECKLOCKTIMEVERIFY or OP_CHECKSEQUENCEVERIFY, to enforce a given locktime, after enough Proof of Work will be reached.

When the final transaction will be broadcasted on-chain, it will contain all sidechain fees, so they will go into mainnet miners. It means that replacing this transaction will require providing a competing grinded signature, with full-RBFed fees. The private key will be known, if grinders will use half of the generator as their R-value (to make the signature smaller), but to get the coins, the attacker would still need to do the grinding, to spend more fees, than the original transaction, and to meet all locktime conditions, set by sidechain users.

All valid points.

Although it has come to the point where most changes nowadays can only be done through Core, which itself has a narrow development team.

It should be possible to implement a drivechain without necessitating a protocol change or soft fork. Actually I just did a google search and have seen that its already possible since the block templates and structures are more or less the same. The only thing that needs to be done is skip verification of transactions inside merged-mined blocks.

@garlonicon: I had deleted my post because I actually found some interesting information about one of the topics you mentioned and wanted to re-write it to not bore you with similar arguments as in my discussion with vjudeu .

As you were fast and already quoted my post before I deleted, I re-post my original post you cited from, here for reference (other interested people please exchange my post with garlonicons')

I'll reply once I read the mentioned documents.

---

But who would merge-mine a chain where you get zero revenue from merge-mining? I guess there could be some altruist merge-mining ("Sidechain/Metachain is good for Bitcoin, so we should mine it") and maybe you can also charge some small fees for peg-ins and peg-outs, but would that be enough to prevent 51% attacks? I don't believe these fees can be high, otherwise only seldom people would use the peg mechanism and instead use atomic swaps or centralized/P2P exchanges.

How do you achieve this? How can this script look like? Don't we need covenants or some other opcodes Script does currently not provide, to really create a blocking/unblocking mechanism on Bitcoin which ensures that we can't do the above mentioned attack? How exactly can homomorphic encryption help here? Can you create a sort of "covenant" with it?

My specific problem is: How do you exactly block the coins on Bitcoin, before you "move to the sidechain", to be later able to release them exactly to the person/address who pegs-out BTC on the sidechain? I still fail to understand which kind of script you could use. I know only the following methods:

- Drivechain, as described by Paul Sztorc. Needs more opcodes on Bitcoin.
- Dynamic multisig federations where simultanity is enforced by consensus on the sidechain (Nomic, Stacks). A subset of the strongest sidechain validators can enter the federation and thus move coins on the Bitcoin chain to those addresses who perform a peg-out on the sidechain to BTC. If they misbehave, they are not only excluded from the federation but also penalized on the sidechain. That's not completely bulletproof but may work well enough.
- Rollups, where part of the info is stored on-chain, so the whole transaction chain can be "reconstructed" if needed, but uses less bytes and thus can reduce tx weight/fees.

The goal of course is to prevent attacks where someone transfers coins from BTC to the side/metachain, buys things on the sidechain, and once he received the goods (or fiat/coins) moves the "blocked" coins on the mainchain. This could even be made in Nomic by colluding misbehaving federation members. They would be penalized but maybe the sidechain has enough value to be able to make a profit stealing coins.

I believe you are talking about a similar sidechain model like @vjudeu above, but I can't find any information about that concept. Are there any whitepapers/links?

Is there any real-world example for that concept? My impression is that this isn't an easy task and may be even be impossible if both metachain and pegged chain (Bitcoin) are decentralized, because it could allow attacks on several of the weaker chains happen at once to harm the metachain or steal coins.

Of course in the semi-centralized altcoin world there are models claiming they work this way (Komodo ecosystem, for example) but they're very likely only pegged together because all chains have the same set of colluding validators, or because this applies to the "commitment collectors" (in models like Komodo's dPoW).

That could work, but I can imagine a growing attack risk when a metachain (or sidechain) is losing security because its EOL is near and miners may abandon it gradually.
However, a similar model with "constantly renewing" sidechains could also work if the metachain contains an own altcoin, which could make the process safer because these coins (and the incentives for consensus their validation provides) would continue to exist. They could be simply swapped to a new chain, i.e. the new chain being a hardfork of the old one, and then "forgetting" the old transactions once it is secure enough. Or with a mini-blockchain scheme, like Cryptonite or Kaspa.

There is never "zero revenue", because you are still paid. Every transaction has a fee. Mainchain transaction, LN transaction, or even sidechain transaction. Those transactions for peg-ins, transfers on the sidechain, and peg-outs will have a fee. Of course, it could be zero if you want, but nothing stops those miners for confirming those things.

The fee of the sidechain miners, is simply the fee that comes from batching: if someone will do some transactions, that will pay 0.01 BTC, then the fee for the user will be the same. But it will be possible to batch things, and collect fees from batching transactions, in a similar way how LN nodes collect their routing fees.

Also, if you read how Drivechain is implemented, then you note there are two kinds of fees: L1 fees, and L2 fees. Here, it will be similar.

It depends on the computing power. If you will have a bunch of CPU miners, sitting on a particular sidechain, then of course they would collect single satoshis, and of course the Proof of Work coverage will be quite low. Which means, if you have Lightning Network, then you have penalty transactions, and absolutely none Proof of Work protection (lightning transactions are simply zero-confirmation transactions, as long as they are not broadcasted). Here, you will have the same level of protection as in the Lightning Network, but also with Proof of Work coverage, and a public watchtower, where every honest node will send penalty transactions when needed.

It depends on the traffic, and on the Proof of Work coverage. I expect it could be on a similar level, like in LN, or maybe somewhat higher, because in sidechains, you can send your coins to anyone, without creating additional on-chain transaction, if your coins are already in the sidechain.

The mainchain should be blind, when it comes to everything that is happening on the sidechain. If you want to just test things, you should be able to do a self-transfer, or even no-transfer-at-all, and check, how it works. For that reason, every Script should be allowed, no matter what it contains, and then it is up to the users to define the conditions.

If they are needed, they could be implemented on a sidechain, because that part will not require any consensus changes, and will work as well.

Because then, the sidechain can act like a global watchtower. If you have LN closing channel transactions, or penalty transactions, you just keep them on your node, but the drawback is, that your node should then be online, 24/7. However, if you encrypt things first, and then post them in encrypted form to some P2P network, then honest nodes could observe the mainchain 24/7, and if they notice a transaction, that will match, they will decrypt the penalty transaction you posted before, and act as a global watchtower. Also, in the same way, they will block any double-spending attempt on that sidechain.

You can perform any computation you want, according to the ways it was "encrypted". Which means, if for example some public key is exposed, then you can create a multisig out of it. Or if some Schnorr signature is exposed, then you can bring the missing part, and join those signatures. Or you can do other tricks, for example prove that you solved puzzle number 66, without revealing the public key, and letting everyone break it before reaching the first confirmation. And yes, I guess making covenants is also possible, but I didn't explore the details yet.

You don't block the coins. You inform people, that you own the coins, and then they can decide, if they want to join your Script, and if the proof you provided is sufficient. For example, if you have already existing Lightning Network channel, then you should not close it, and then open "sidechain peg-in". You should simply show people: "here are my coins, here is my signature, here is my unlocking Script, can you accept that?". And guess what: some scripts are already acceptable. And also, some scripts are acceptable, if you want to just test things.

Also, sometimes you don't need to move coins. Sometimes you want to only test something. Then, what do you need? Not that much: you need to inform people, that you own some coins (even on P2PK), then you can do your testing, and then you can move your coins back on-chain, for example because you want to send them somewhere. And then, everything will be batched to a single on-chain transaction, and the destination would be the outcome of batching everything you did in the middle. Isn't it beautiful? Testing without producing new coins, out of thin air? Posting for example Ordinals on the sidechain, and sharing it with the network, without bloating the mainnet? Creating your own assets or tokens, and preserving the ownership, without pushing all of that to the mainnet? I think it is worth at least trying, and I think allowing any Script is needed, because those use cases, where coins are negligible, should be cheap on sidechain, and expensive on mainchain.

Not yet, but as you noticed, we talk to each other, and we created some small, private test network, and some of our posts just reflect the results of our testing. Of course, things are not yet ready to be shared publicly, but I think they are good enough to be discussed. And also, we need some feedback to fix some bugs, before we release all of that publicly. We don't want to flood the mainnet, or to harm it in any other way, and we know, that if we release something, then there is no "undo" button (as you can read in my signature).

Not yet, but testing sounds promising. Of course, NameCoin used Merged Mining, but there are some flaws, and our implementation is different. But still, there are some bugs to be fixed, and some extreme cases are hard to fix, so we will see, what to include in the first version.

You won't attack metachain that easily, because it would blindly follow the heaviest chain of Proof of Work. Which means, you can produce invalid headers, and the sidechain will trace that, and react accordingly. Because if you look at BCH or other altcoins, then you can notice, that one of their mistakes, was related to replay protection, and difficulty adjustments.

In case of 51% attack (or even 99% attack), the current network simply ignores invalid blocks, even if their Proof of Work is enormous. And I think it is a mistake. It should be noted, that "hey, the attack is ongoing", and the network should react accordingly. Which means, that invalid headers should still be notarized, and the value of the honest network should be relative to the total Proof of Work, produced by honest nodes and attackers combined. Because if it is not, then it is like pretending that there is no attack, which is a bad approach.

I want BIP300. If Bitcoin is going to destroy the banks and become the world’s money, it must have the properties of cash. Fast, cheap, and private. I don’t care what BlackRock or Michael Saylor wants.

Lightning is broken, and never had what it takes to scale Bitcoin anyway. There’s no reason to be concerned about "shitcoins on Bitcoin" because we already have monkee jpegs on L1. If anything in the future could possibly be worse, then we should already have the ability to throw it on a sidechain.

Miners don’t even need to run a sidechain node. Even if they did, it wouldn’t matter. Nobody has to keep an entire history of the L2 blockchain. Every peg-out is like a new genesis block, because L1 has confirmed that everything is valid to that point.

Why do you think so? It is just all about deploying existing Drivechain implementation on a different chain, that will initially have zero coins. Nothing else is really needed, because Proof of Work can be imported through Merged Mining (and Proof of Stake can be directly pegged here and now, just by sending coins to the addresses, owned by validators).

Not necessarily. The only needed thing is to move coins on both chains simultaneously. Which means, on Bitcoin, you can have even P2PK, because it can be useful in some situations, and it will be more private.

This "very specific set of requirements" is just defined by the output Script. And if it is not sufficient, then guess what:
1) N-of-N multisig can be always used when needed.
2) Transactions can be encrypted with Homomorphic Encryption, and then processed on the sidechain in a new way.

Sidechain can be pushed forward, by collecting commitments from other chains. Which means, the difficulty of the sidechain, will be equal to the combined difficulty of all chains in existence (they may be sorted by hash function, or in any other way).

That would solve the problem only for this single altcoin, and Bitcoin, nothing else. But the area of similarity between altcoins is much wider, for example, there are not that many altcoins, which don't use secp256k1. I know the exact area of coverage should be examined individually in each case, but if sidechains will not be imported by any altcoin, then people should probably start thinking about a separate chain, designed specifically for that purpose.

Also, because this chain would produce no coins, it could be possible to "go back to zero" on a regular basis. Which means, that Initial Blockchain Download will not be a big deal, because coins can be pegged out, finalized on each chain, and we can start over, when the metachain will be too big. So, it would act like a trustless batching of the history, that would have to otherwise land on each individual chain.

This could of course be possible, I have also heard proposals about such a "metachain", but the problem of the peg between Bitcoin and the new "main chain", or other chains, would remain.

If we want the Bitcoin to be moved to a sidechain for scalability reasons, i.e. have a token on any chain which has exactly the same value than 1 BTC to be able to make payments without congesting the BTC chain, then we must have a mechanism to block Bitcoins on the Bitcoin chain, and be moved if a very specific set of requirements is fulfilled. And that is the central problem as far as I understand, we need mechanisms such as covenants which are controversial in the developer community. Or rely on multisig-based techniques like on Nomic (which already exists but is semi-centralized; I'm of course ignoring traditional federated chains here). A metachain wouldn't change that.

In addition, a metachain without any tokens would be difficult - how would you create consensus without having any monetary incentives to maintain it? I see more chances if an already existing altcoin (for example LTC) could implement a mechanism like Drivechain. Of course EVM chains provide already some sidechain capabilities (Optimism, Polygon ...) but no one I've heard of is really decentralized.

What about creating a separate chain, that will be used to peg coins in and out, and will have its own blockchain, outside Bitcoin? In that case, Bitcoin could be just one of the sidechains, instead of being the central point, where other sidechains are created.

I guess that approach will lead us faster to some working implementation, because creating some soft-fork, or no-fork, to peg things into Bitcoin, would probably be too controversial to be merged.

So: the new chain could start with zero coins, and could have consensus rules to allow tracing other blockchains, and creating pegs, but that chain will create no new tokens by itself. We don't need more coins, we need more functionalities.

It is possible here and now, without those BIPs. If I understand correctly, DAG means Directed Acyclic Graph. If so, then look at transactions, and try to represent inputs and outputs in a graph. Voila, you have a DAG. Not to mention that TapScript itself can represent it as well inside MAST.

If you want Proof of Stake, then it is possible here and now. Take signet for example. It can be fully connected with mainchain, all you need is just taking those signet challenges, and place them inside transaction outputs. In general, if you have any altcoin, that is here and now a federation, then you can have 1:1 peg with Bitcoin, without any soft-forks.

Also, that question reminds me about this topic, and my answer, that is also applicable here: https://bitcointalksearch.org/topic/solidity-scripts-in-bitcoin-transactions-using-inscriptions-5452759

Would it be possible to run DAG-like chains as Bitcoin sidechains with BIP-300 and BIP-301 implemented? On drivechain.info, Paul says about different possible things like PoS etc., but not about DAG.

If I understand it correctly, we will have two or more signatures on the mainchain (except solo testing by single users). And then, "the second signer's signature triggers the release of both" seems to be true in that case: if the last signature will be released on the sidechain, then it will burn those sidechain coins, and will be automatically propagated to the mainnet by any node. And if it will be released on the mainchain, then it will be observed by all sidechain nodes, so they will instantly fetch it, and act in the same way, by burning those sidechain coins.

So, even if we don't have OP_CHECKDATASIG or similar things on the mainchain, then still, if all sidechains will observe the mainchain, we will reach that feature indirectly (because then, sidechain coins would be effectively locked with OP_CHECKDATASIG, limited to the mainchain, instead of OP_CHECKSIG, which would be valid only on the sidechain). I also wonder if using sidechains as a "global watchtower" can enable other features, like automatically executed contracts (because then, by manipulating the conditions for decrypting and releasing some penalty transaction, it is possible to enforce other things, and probably push any transaction, not only related to getting coins from some attacker).

I added my comment to one of those proposals, maybe I will check the second one later: https://gist.github.com/mappum/da11e37f4e90891642a52621594d03f6?permalink_comment_id=4487165#gistcomment-4487165

The general concept is very simple: if you have on-chain coins, you can move them to the sidechain by signing them. And if you move them on the mainchain, then they are removed from the sidechain.

This general concept is enough to create any sidechain-based test network. You want to get some test coins? Just sign them, and you will get sidechain coins. Then, if you move them on-chain, they will be removed from the sidechain, and then new sidechain users could skip them entirely during initial sidechain download.

And then, everything else is about making things safe to use if there are more users, and if coins are not worthless, like in testnet.

It depends. Because if those proposals require any kind of soft-fork, then there is a high chance that they will be rejected. The only way we could have sidechains activated by some kind of soft-fork is when other features will be introduced, and then sidechains will be enabled as a side-effect (in a similar way as NFTs were activated as a side-effect of Taproot, for example people could introduce new sighashes, and then they will notice after activation that it can be also used to activate sidechains). Because some users don't want to create any strong link between Bitcoin and altcoins, and sidechains can provide that, no matter which proposal will be chosen. Also, introducing sidechains is that kind of change, which could be the last soft-fork we will ever need, because since then, all other features can be turned on and off, without any need to create another soft-fork for that.

Yes, because multisig is the simplest thing you can do, to avoid loss of funds. If you have N people, then N-of-N multisig will guarantee that if you will use some wrong script, that will be unspendable, then you can always contact with everyone, and reach a signature that will allow moving those coins. So, using multisig as a base is highly recommended, even if your plan is to use custom scripts. However, allowing peg-ins from any scripts is also needed, because people should be able to test those features alone, and because by doing that, people can check, what kind of output is the most popular, and increase their privacy by using the same address types (in a similar way as Tor Browser picked Firefox for Windows, to hide the real User Agent behind the most popular choice).

Yes. Also note that a single transaction can be used for many peg-ins and peg-outs at the same time (it is similar to coinjoin in this case, if something will fail, then the new state will not be reached). Some users provide their inputs, others provide their outputs, and a single sidechain UTXO can be moved from one address to another, to commit that state to the mainchain, and that will make things harder to reverse later (because then, reorging the sidechain behind that point will require reorging the Bitcoin blockchain).

Yes, peg-ins are encrypted, there is a proof that your signature is attached to some existing mainchain coins, but all things cannot be revealed, because then anyone could connect to the sidechain network, and push everything on-chain, and then the whole point of using sidechains is destroyed if things will not be batched.

Yes. Cheating is hard, because you cannot instantly move your coins on-chain. It is like leaving LN channel alone: possible, but hard to do, and it is better to cooperate with the network. Also, because things have to be batched in advance, you cannot just leave the sidechain alone, and be unnoticed. Sidechain full nodes can track all penalties, so a single honest node can simply check if someone tried to move those coins, and then a single honest node can act as a global watchtower.

It depends. If some miner is not attached to the sidechain, then that miner knows nothing about the state of the sidechain. But there are sidechain miners, that can use Merged Mining, and protect sidechain from chain reorganizations. Miners are needed, because without them, new users joining the sidechain will have no idea, what happened in the meantime, and which sidechain history is correct. So, sidechain miners participate in transaction batching, and they are those who can mine mainchain and sidechain, using the same amount of work, and they put things in the right order. If their power is sufficient, then they can mine mainchain blocks, and get fees from the sidechain, and from the mainchain. If not, then they can get only sidechain fees, gained from batching, in a similar way as LN nodes are rewarded.

Mostly yes, the basic concept is quite simple, and I think it will not change: signing is enough to create coins on sidechains, and moving them on the mainchain is enough to bring them back. This is the fundamental concept, and everything else is about making things safe beyond some test network. Because that concept alone should be sufficient to test sidechains, you can just sign your coins alone, then test all sidechain features you want, and then, after testing, you can safely move your coins on-chain, then nobody else will ever need to download those historical sidechain transactions.

Since then, I think about putting my theory into practice. The basic concept shows us how sidechains could be introduced in a no-fork way, when all soft-fork proposals will be rejected, one-by-one. I assume people won't accept soft-forks for sidechains, because then it will be the last soft-fork, and because it could have undesired side-effects, so sidechain enthusiasts will not reach consensus in this case. And then, the hardest part is making things safe enough, so that I, as a sidechain user, could accept someone else's proof, and be convinced enough, that such person cannot simply move those coins alone.

I am also quite skeptical, because I can still see some problems in the details, for that reason you cannot see some working examples yet, because I don't want to release a system, where I could still find ways to break it. However, I am pretty sure that it is possible to build a working system on top of this basic concept. I am 100% sure that building such testnet is possible, but then, building a mainnet is needed, and things should be mature enough when publicly released (because I don't want to release some half-baked code, and see some altcoin that will start doing it in a wrong way on the mainnet, and will discourage people from sidechains).

Also, I will look at some other proposals, then maybe some of my problems could be solved. Because things evolved over time, when I thought about it for the first time, I didn't think about Taproot, and there were issues related to large multisigs, but since we have Schnorr signatures, it can be easily solved. So, there is a chance that some details related to storing things on the sidechain will change, but the main idea of signing coins to create them, and moving them on the mainchain to remove them, will probably remain unchanged.

Thanks for your long response, I have not forgot this discussion And even if I may sound sceptic I would love to see this implemented if it works.

I am still however struggling with understanding still some basic concepts of your sidechain. Maybe I'm too dumb for it If you have detailed the general concept in a whitepaper or on a website (apart from the bitcoin-dev posts which I already read) it would be helpful if you provide a link ... (It would also be cool if someone with more cryptography knowledge could comment on this).

In the meantime I have read two concepts of sidechains which are an improvement on federated sidechains but still not completely decentralized (and unfortunately rely on premined sidechain altcoins, so they would probably not convince a large part of the Bitcoin user base):

- Nomic
- Stacks (formerly Blockstack)

Both employ a kind of "dynamic" federation where thanks to Taproot the federation can consist of hundreds of multisig partipants, and federation members can change in regular intervals.

Is it possible that there are some similarities between what you've in mind and these models?

My general understanding of your sidechain concept, according to my interpretation of your answers, is this:

1) it is initiated often by some multisig contract between a subset of the later participants, but they don't constitute a "static" federation. (There is however "no strict way" to initiate a peg-in.)
2) Peg-ins and peg-outs occur in batches in regular, but relatively long intervals (e.g. 3 months), if new participants provide mainchain inputs (which can be used for penalties and/or new funds) or inputs from other sidechains. (may be similar to the "dynamic federations" of the Stacks/Nomic concepts).
3) Peg-ins use advanced (e.g. homomorphic) encryption techniques to calculate the output scripts and the needed keys to move the attached coins/utxos for the "last mainchain transaction" (i.e. the part of the peg-in residing on the mainchain) which can provide some security for the case 4, in cooperation with miners.
4) if there is a wrongful peg-out attempt of a cheater ("Malice") who wants to peg-out with an earlier sidechain state, then all sidechain users who have observed a later (regular) state of the sidechain can provide a proof that this state exists, and overrule "Malice's" peg-out. (quite similar to the Optimistic rollup approach).
5) Bitcoin Miners participate in the control of the peg-outs.

I may have later some comments about your answers in the latest post, but I first want to ensure that the understanding of your concept is correct.

There is no strict enforcement, because there are many options:
1) You can use P2PK. Then, to make it safe, you have to create it with someone else in a way, where you know the public key, but nobody alone knows the private key. Multiplication of ECDSA points is a partial answer, because then nobody can sign it. A full answer is for example 2P-ECDSA, described here: https://duo.com/labs/tech-notes/2p-ecdsa-explained
2) You can use P2PKH. It is possible to encrypt things first, then compute the key as in P2PK case, and then hash it. After encrypted hash will be computed, it can be decrypted and sent to the network, then even nobody knows the combined public key behind this hash, because it was available only under homomorphic encryption. Note that having unencrypted signature will reveal that key, but you can also accept other proofs inside your sidechain, and then keep it hidden.
3) You can use P2SH. Then, if both parties know that things are standard, and evaluate into OP_TRUE, they can send it on-chain. In that case, the whole script is unknown. Also, OP_CODESEPARATOR can be used to sign only part of the script, and accept anything that comes before that opcode, but in this case it is better to use P2WSH or P2TR, because P2SH with OP_CODESEPARATOR inside will be non-standard.
4) You can use P2WSH. Then, it is similar case as with P2SH, but you can create more scripts, and keep it standard. Also, it is cheaper, because of witness discount, but the whole way of encrypting things first, executing them in encrypted form, getting needed proofs, and then decrypting and sending on-chain, is still the same.
5) You can use P2WPKH. Then, to make it standard, you can always use compressed public key.
6) You can use P2TR. Then, you can prepare N-of-N multisig as a base, and then you can safely experiment with TapScript.

A lot of flexibility is needed, because people will not accept sidechains as a soft-fork, and because they should be upgradeable, when other features will be enabled on-chain. Also, it increases privacy, so it is a good thing to allow broadcasting all current standard scripts, because a no-fork way means that in the best case, nobody should exactly know, when it started, and if those things were active in the past. For example, what if there were active sidechains, and if some users joined them, and then all of them moved their coins back to the mainchain or lost them? If possible, the starting point should be unknown, and it should remain as "always was possible, always was active, since 2009". I think that kind of sidechain will have no Genesis Block, it could always start earlier than all nodes assume, but all proofs were simplified into OP_TRUE and discarded.

Look at Drivechain proposal, and try to figure it out, how sidechain miners can always steal funds by constantly signalling the wrong state of the sidechain, continuously for many months. If you compare LN user broadcasting some previous closing transaction, with sidechain user doing the same, it looks very similar. The main difference is timing: in LN it could be two weeks, in sidechains it could be three months.

Why not? On-chain interactions are prepared in advance. It is not like in LN, where you can open a channel instantly with anyone. Here, in sidechains, on-chain updates can happen only from time to time, it was proposed to happen every three months. So, if you have on-chain coins now, and want to move them into the sidechain, you join a larger group by connecting to the sidechain network, and adding your signature. It will not be instantly visible on-chain as a new transaction with zero confirmations. It will go through a long batching process, and will be finally published as a single, large, on-chain transaction, where many coins will be pegged in, many coins will be pegged out, and a single sidechain output will represent those who will stay inside the sidechain. Also note that if you choose Taproot, then signatures can be batched, so a single signature can represent many users. And note that things will be executed in encrypted form, so you will not know exactly, how many people are inside, because nodes can reveal proofs provided by other nodes, and because partial scripts that will evaluate into OP_TRUE can be discarded. Also, only some users will go through this on-chain process, because most will use swaps.

If you have a CoinJoin transaction, then what is the cost to penalize misbehaving node? There is a choice between time-based cost, and satoshi-based cost. I think sidechains will reach some equilibrium somewhere in the middle, because using coins is one way, but you can use less coins if you want to wait longer. I don't know exactly how large will be sidechain transactions, and how many signatures will be joined in a multisig, or how many coins will be allocated for penalties, it has to be tested in practice.

Why not? If that penalty will be satoshi-based, then it can affect those who have some satoshis. But for those who don't, there is still a time-based penalty. For example, I can safely sign a transaction that will give you all my coins, and will be valid after 10 years. Because I am almost 100% sure that I will move those coins by then, and the transaction I gave you will be invalid, when that timelock will expire.

So yes, you can send someone some coins inside the sidechain, when that person will have no on-chain coins. They will be quickly valid inside the sidechain, but to get any mainchain coins, that person will need to go through peg out, that is difficult, it consumes a lot of time, and then sidechain miners will have a lot of time to get all of those coins from that person.

You assume that earlier participants know the script that was used, and you assume that they have all needed keys, so they can move those funds alone. There is no need to strictly require that. Because to make it generic enough, it is needed to accept things in a form they exist on the sidechain. So, Alice joining the sidechain from the mainchain directly is not the only use case. Another valid way is to leave one sidechain, and join another sidechain. As long as proofs are compatible, they can be accepted. So, if Alice can provide a proof that she is going to leave sidechain A, and join sidechain B, then Bob from sidechain B can check that proof, and accept it. Also, proofs from other kinds of swaps can be accepted, so a swap can be batched into the sidechain transaction, that will be finally visible on-chain. There are many possibilities, someone going from LN into the sidechain by forming a different channel closing transaction is also an option.

You also cannot prevent some malicious miner who wants to steal coins, convincing him that mining on top of some earlier block is not going to work. And you cannot prevent some LN user from broadcasting some earlier closing channel transaction. All systems have their assumptions: Bitcoin assumes that the heaviest Proof of Work chain is formed by honest nodes, break that assumption, and Bitcoin no longer works. LN assumes that the honest participants will grab the coins, before expiration of the timelock of some earlier closing channel transaction. And sidechains assume that their users will inform the mainchain with sufficient proofs about the correct state of the sidechain, before the thief will grab those on-chain coins (but again: assume that someone created a malicious Drivechain, and read what Paul Sztorc said about sidechain miners stealing those coins).

1) Alice will encrypt her penalty transaction, and send to the sidechain, with sufficient proofs.
2) Malice will send some earlier transaction, trying to steal the coins.
3) Every sidechain user will have a proof that Malice published transaction that should be invalidated.
4) Only if absolutely no sidechain user will react, or if all Bitcoin miners will decide to accept malicious transaction, those funds can be stolen.

No, it only means that their action is needed to initiate it, but later it can be passed to anyone. If someone will decide to leave the sidechain, then that transaction will be a typical Bitcoin transaction, so it can contain any outputs. If you have Alice and Bob in transaction input, you can still have Charlie in transaction output. Also, if Dave wants to join the sidechain, while Charlie wants to leave it, then Dave will provide some on-chain transaction input, that can be used to create transaction output for Charlie. In the end, everything will be batched, so all sidechain interactions can be cut-through in the final on-chain transaction.

Not only, because people entering the sidechain can also provide their inputs, so those who want to exit, can use those coins.

It took me some days to analyze your answer, but I've still problems to understand the solution to the (crucial) question "how must the last transaction on the mainchain look like" to be able to peg-in on the sidechain, which prevents me (=Alice, the "originator" of some sidechain funds) moving the funds causing chaos on the chain, invalidating tons of transactions, etc.

The crucial part where I fail to see a solution using Bitcoin Script is the penalty mechanism. In an "open" sidechain, where you transact directly with all users, it can't be like with Lightning, because you're not updating a state with a single multisig partner and could thus invalidate previous states like in LN.

I also looked at an "overcollaterized sidechain" model, where extra funds for penalties are required in addition to the funds used for peg-ins, but this didn't solve my problem - to ensure, via a mainchain contract, that only the last person in a chain of payments can peg-out (and previous intents are properly penalized).

The only model which is not close to a "federation" (see below) but may be possible (from my understanding) is a 1:1 clone of LN on a sidechain. This would need all sidechain participants being connected via "channels" made by multisig transactions with penalty transactions sent in an encrypted fashion to the counterparty and stored on the blockchain.

This of course has the disadvantage that the sidechain cannot "onboard" new participants who never used Bitcoin, all have to have funds locked on the mainchain, otherwise the penalty mechanism would not work. This is of course a very limited sidechain which would maybe have the advantage of more flexibility with respect of the requirement of a merchant to be 24/7 online to receive payments, but instead partly sacrifices LN's privacy (although maybe not all of it, due to homomorphic encryption).

So for me, the Optimistic Rollup model seems the path to follow. Something like this could maybe be achieved with covenants (I'm not expert enough to know if OP_CHECKTEMPLATEVERIFY like proposed in BIP-119 would be enough).

I may however be overlooking something ... if you can give me a concrete example how such a penalty mechanism could work exactly (i.e. with at least descriptions of the needed locking scripts) maybe I can imagine better

---

By the way, to most of the answers of the last post I agree and some were already clear for me. In some cases however I disagree:

The "reaction" is the problem here (see what I wrote about penalties above). If we use a simple timelock (CLTV/CSV) for the last mainchain tx before the peg-in, then there remains the problem that we can't create a timelock which only affects Alice. It would affect all other sidechain participants which want to peg-out with these funds. So this would create a race condition at the end of the timelock. There is no contract condition I can imagine that only Dave can fulfill (the last participant of the chain) but not Bob (intermediate) nor Alice (always talking about Bitcoin Script).

The "overcollateralized sidechain" idea I briefly mentioned before would separate a peg-in UTXO and a penalty-utxo for each Alice instance, and only the penalty would be timelocked on the mainchain, so peg-outs before the timelock ends would work. But I realized we're here only moving the problem to the penalty output.

This security model would be flawed, I hope I (or you) misunderstood here You can't prevent someone who wants to steal coins convincing him that there is some way to peg-out "faster".

Again, how exactly would this penalty mechanism work? The "Lightning way" only seems to work (imo) for payment channels and maybe the "LN on a sidechain" model I outlined above.

Wouldn't that mean that payments could only be done between of the members of this multisig contract? This would of course work, but would be even more limited than the "LN on sidechain" model.

If not, how does the connection (and the "penalty/risk transfer") to other sidechain users work?

You're right, this is not the same thing as a federation, but it's quite similar in that only the users participating in this multisig contract have control over peg-outs.

The same is true inside Lightning Network: each time you check that it is 2-of-2 multisig, even if it could be different. So, here it will be similar: typical scripts will be accepted instantly, but other, less typical scripts, can be also supported if everyone agrees, so that the network could be upgraded if needed. For example, if some TapScript opcode will be re-enabled by some kind of soft-fork, then there should be a way to upgrade sidechains accordingly. So, when it comes to network acceptance, then any script is accepted. But when it comes to clients, then they can do a pattern matching, and accept only specific type of scripts, in the same way as miners include transactions, based on their standardness rules, while also accepting non-standard transactions in other blocks.

You can imagine the last Lightning Network transaction quite easily: it is theoretically possible that something could go wrong, but there are ways to prevent cheating. One of those ways is creating some kind of penalty transaction. Another way is to add some timelock, enforced directly, or relatively. In the sidechain proposal, even in the one proposed in BIPs, there are cases, where sidechain funds can be stolen. The same is true in LN. And here it is not different, because you can always create a double-spend inside, no matter what kind of Script will be used. Even in the mainchain, there are ways to steal funds, by creating a chain reorganization.

In the Lightning Network, there are penalty transactions. Also, funds are timelocked, so if they will go on-chain, they cannot be moved instantly. For sidechains, it was proposed to freeze them for three months. So, Alice can go on-chain, and then sidechain users will have a lot of time to react. In general, on-chain interaction will be for peg-ins and peg-outs, any other cases will be handled by swaps, in the same way as it was proposed in Drivechain.

They are in the same situation as Alice. And this way is compatible with Drivechain: it is not about preventing that from happening at all (because if some previous owner had those coins, then you cannot fully invalidate them, without moving any funds on-chain). It is rather about disincentivizing cheating by saying: "yes, you can always peg-out directly to the mainchain, but no matter if you are the last owner of those coins or not, this is not the fastest way, better swap your coins, instead of going through peg-ins and peg-outs".

Only the last user can be 100% sure that any attempt to go through peg-out will be successful, and nobody will release any penalty transaction in the meantime.

It can be performed by any sidechain user, because Bitcoin users know nothing about the last owner. They don't have the chain, they don't talk to that network. It is the same case as with BitDNS, or with commitments: if you only use Bitcoin, then you can see only Bitcoin transactions, not sidechain transactions, not LN transactions, not commitments, etc. Also, there is no federation needed, unless users explicitly want that (because scripts should be accepted by the network, but selected by the clients).

Yes, it is possible. If you have N parties, then you can always start with N-of-N multisig. Then, if your TapScript will be unspendable for any reason, the cooperation between all parties will recover those funds. This recovery mode is highly recommended in case of emergency, it is better than making key-path unspendable by committing to provably unknown public keys. And then, if you assume that your TapScript can be really big (as huge as the maximum block size, which we saw recently, but in standard cases it is limited by transaction size), and if you also assume that it can be expanded into multiple transactions, then yes, you can execute any script. It is cheaper to just execute it in encrypted form, without pushing it on-chain, but yes, if you really want to enforce zk-snark on-chain, then you can, but it will be very expensive). The typical way will be to use N-of-N multisig as a protection, and then execute anything in encrypted form (and after successful execution, a single signature is all we need to make it cheap, three months is a plenty of time to prepare it).

If you want to know, how it will look on-chain, then any Taproot output looks the same: it is just a public key with 02 prefix enforced. Behind that, you can have N-of-N multisig, that can be done by a single Schnorr signature (you can use any multisig scheme, there are some of them proposed, I don't know what will be finally deployed in the Bitcoin Core descriptors). And behind that, you have TapScript, that is simply a tree. You can use any scripts there, you can encrypt them, and then execute in encrypted form, between sidechain users. Also, you don't have to store everything in your transactions, you only need to keep that part, which was not yet executed, and simplified into OP_TRUE. As long as those parts will be executed faster than in three months, it is cheaper to keep them in the sidechain.

There is also OP_CHECKSEQUENCEVERIFY, that could be a better match, because it will be relative to the time of enforcing things on-chain.

No, because in this case, sidechain miners are not the ones engaged in the multisig. They are needed to mine both mainchain and the sidechain at the same time, so the same computing power can protect the sidechain from chain reorganizations. In this way, double spends inside the sidechain are resolved, so miners are needed to make sure that new users will get the right sidechain transactions in the right order. Miners are not there to protect the scripts, they are there to enforce the order in which they were created on the sidechain. And then, if someone will push something on-chain, to start a peg-out, then any sidechain user can decrypt penalty transactions (if any), and act as a global watchtower, preventing the cheater from getting the coins.

I may be overlooking something, but the problem I see here is that these sidechains would be difficult to use, as they themselves would not give any guarantee that the funds on the mainchain wouldn't be moved and thus the coins on the sidechain would have a tendency to be "unstable". Any time you accept a sidechain transfer, you would have to check if its origin is based on a mainchain UTXO which is properly locked.

The difficulty for me is to imagine a kind of hashlock for this last mainchain tx, which fulfills the following conditions:

1) prevents the originator of the sidechain coins (let's call it Alice, like in the example used in your discussion with Paul Sztorc) to move the coins for the whole time the coins "live" on the sidechain
2) prevents all intermediate receivers of sidechain coins of this origin (Bob in Paul Sztorc's example) to withdraw coins and unlock/move these mainchain coins,
3) can be unlocked only by the last user of the chain of sidechain payments whose origin are Alice's mainchain coins (Dave in Sztorc's example),
4) that the withdrawal/unlocking (Dave) can be performed by any Bitcoin/sidechain user, not only one who is part of a "federation" of multisig participants (otherwise the whole federation may become unavailable and then the sidechain coins float in a "limbo" maybe forever)
5) is possible to construct with standard Bitcoin Script / TapScript.

Could you provide an example for such a lock? I'm not familiar with TapScript so I don't know if it's expressive enough.

I don't know if OP_CHECKLOCKTIMEVERIFY would have any use in this scenario. We could imagine an example where Alice owns a business who sells goods accepting the sidechain coins, but she also buys regularly things there. So she could move some coins temporarily to the sidechain to profit from lower fees with the idea to move them back near the expiration of the timelock. But the lock problem persists, as she's not forced to "take back" the coins, and could make some payments, and then simply wait until expiration to move the mainchain coins.

Maybe a solution to the problem could come from the Optimistic Rollup technique? I.e. one could imagine a sidechain where an user who proved having received the sidechain coins could pay a "penalty fee" and then perform a withdraw which will be frozen for some blocks. If there is another user later in the chain, who has proved that he also has received the coins (i.e. in Sztorc's example this would be Dave, and the "scamming" user may be Alice or Bob) then he would be able to send a "fault proof" and receive not only the coins, but also the penalty fee from Bob. If nobody opposes in this fashion, Bob gets back the penalty fee and also can move the coins on the mainchain. Still this would need probably new opcodes (?).


If I interpret it right, this would be very similar to the classic "federated" sidechain (RSK, Liquid). Or are there any improvements on it that I'm overlooking?

I think you may be onto something, this looks like like a possible improvement on rollups, but I still think it would need things like recursive covenants and zk proof or "fault proof" opcodes. The model may be possible on chains with turing-complete script languages though.

It depends on the user. You just choose some UTXO, and sign it. As long as this UTXO is not moved on the mainchain, it is valid on the sidechain. So, in this way you, as a user, can choose any locking script. If you want to just test sidechains, then you can do that alone, by using any single-key address. If you use some 2-of-2 multisig, behind raw multisig, P2SH or P2WSH, then you need two signatures to move coins on-chain (that would remove them from the sidechain). You can also add any conditions, like OP_CHECKLOCKTIMEVERIFY, or any Script you want. That means, all conditions to move funds back from the sidechain to the mainchain, are entirely chosen by users, and all transactions look the same as usual, so you don't know that funds are locked on the sidechain, unless you connect to that network.

Yes, encryption is the hardest thing, but it is definitely possible. It is needed to ensure that sidechains will not make things worse (if you would send unencrypted transactions that would be instantly valid on the mainchain, then the whole sidechain history could be pushed on the mainchain, so the situation would be the same, as without any sidechains).

The Script is whatever will be accepted by receivers. The simplest script is N-of-N multisig, where N is the number of parties interested in a particular UTXO. In the Lightning Network, you have 2-of-2 multisig, as a basic script. Here, it goes further, so you can use for example P2TR with N-of-N multisig on a spend-by-key path, and then you can add any TapScript you want to this basic setup.

As long as there is lack of necessary opcodes, some tricks are needed: you encrypt your TapScript, and you work on your encrypted version, that will finally be decrypted by the last user, and will form a valid on-chain transaction. It is possible to prove that your data has a given format, in the same way as it is possible to prove in Monero that your amount of coins is in a given range, or as it is possible to prove that some addresses in a given set were selected, when some transaction moved the coins.

In general, you can encrypt your Script first, then execute it without decrypting (homomorphic encryption), and then you can ensure that the final result evaluates to OP_TRUE, without revealing your script. You don't need to know the content, you only have to ensure that it is correct, it meets standardness rules, it won't give another party a way to sneak OP_SUCCESS somewhere in the TapScript etc. (in general, you need to check the format, and make it strict).

I've looked at your idea in the mailing list, and it would of course be phenomenal if it was possible already with today's Bitcoin Script abilities. It looks a bit similar like rollups, but without posting always updates to the main chain. The use of homomorphic encryption looks also interesting.

But there are some things I don't understand. Mainly the following point:

How does your last transaction on the main chain look like, before moving to the sidechain? You wrote that when you move to the sidechain, you sign a new transaction but broadcast it only inside the sidechain network (and encrypted, so it can't be broadcast to the mainchain by other sidechain observers). But which is the Script you use in your last transaction to avoid that yourself move the coins while they're happily living on the sidechain? There has be some kind of lock (probably to a P2SH-style hash), but what exactly would unlock it? If unlocking it would need a kind of ZK proof, wouldn't this lock need a new opcode? (From the discussion with Paul Sztorc I interpret there would also be some kind of timelock.)

It's a bit of a pity that neither your discussion with Paul Sztorc nor the one on the mailing list progressed more because the topic is very interesting ...

(As this is not a Drivechain proposal but another kind of sidechain, it would perhaps be worth an own thread.)

My opinion didn't change since last time I talked about it. The community will probably reject sidechains in the current form. That means, it cannot be deployed as a soft-fork, because it will not reach that level of support. I also wrote about deploying that as a no-fork, you can read some discussions there: https://www.truthcoin.info/blog/sc-vision/

Again, you can also read my posts about it in another topic: https://bitcointalksearch.org/topic/m.61692197

In short, there is no need to use any chain for Ordinals at all. But if you really need it, then you can make a separate chain, that will commit to Bitcoin inside transactions' signatures.

Because you really don't need those data on-chain, attached explicitly into Bitcoin transactions. It is expensive, it is incompatible with what Satoshi said about BitDNS (thank you garlonicon for mentioning that), and there are better ways to achieve the same security level. Because if your concern is Proof of Work protection, then using commitments is sufficient to achieve that, even if your data will be stored on a separate chain, because SPV proof to a Bitcoin transaction, and another SPV proof to your commitment inside your signature, can easily cover that, and prevent reorgs as well as Bitcoin.