ð
Original date posted:2020-12-31
ð Original message:Hi Roben,
It's an interesting proposal, but I have two issues with it, one technical
and one philosophical.
On the technical side, I don't understand how your proposal prevents miners
proposing a peg-out for an invalid sidechain fork which is not made
available to the nodes (there are missing blocks). It seems that the system
would need to allow users to challenge miners to make available full
sidechain blocks that are missing, which really complicates the protocol.
On the philosophical side, as you mentioned, it is very limited in the
types of sidechains it can verify. I won't be able to verify RSK
(merge-mined with Bitcoin, but with different block format and different
functionality). It cannot verify a zCash-like sidechain for the same
reasons. Therefore it is strictly a payment scalability solution.
Drivechains, on the other hand, enable many new use cases apart from
scaling, which have a much lower level of complexity (if implemented
correctly).
Since the inception of RSK sidechain, I suggested in its white-paper that
sidechains should be designed to support an hybrid peg-out system, based on
both a large multisig AND a drivechain, where both groups need to agree for
the peg-out to occur. It's a censorship/security trade-off that most users
would be willing to accept until a trusted-setup-free SNARK-like based
solution is finally available.
Until we have a sidechain-selectable SNARK-like succinct verification of
any block state transition function, having a single succint proof to cover
the whole sidechain validity, as in Coda (now renamed Mina), drivechains
are the low-hanging-fruit.
regards
On Thu, Dec 31, 2020 at 7:01 PM Ruben Somsen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi everyone,
>
> This post describes a fully decentralized two-way peg sidechain design.
> Activating new sidechains requires a soft fork, hence the name softchains.
> The key aspect is that all softchains are validated by everyone via
> Proof-of-Work Fraud Proofs (PoW FP) -- a slow but very efficient consensus
> mechanism that only requires the validation of disputed blocks. This does
> increase the validation burden of mainchain full nodes, but only by a
> minimal amount (~100MB per chain per year). It's similar to drivechains[0],
> but without the major downside of having to rely on miners, since all
> Bitcoin full node users can efficiently validate each sidechain.
>
>
> Proof-of-Work Fraud Proofs
>
> Last year I posted the idea of PoW FP to the Bitcoin mailing list[1][2].
> The idea is that we can use the existence of a fork in Bitcoin's PoW as
> evidence that a block might be invalid (i.e. a proof of potential fraud).
> Whenever this occurs, we download the block in question to verify whether
> it was valid (and available), and reject it if it was not. We forego the
> need for maintaining a UTXO set with UTXO set commitments (such as
> utreexo[3]), by assuming that the commitment inside the last block to exist
> in both forks is valid. As a result, we only need to download as many
> blocks (and their corresponding UTXO set proofs) as there are orphans,
> which lowers the validation costs considerably compared to running a full
> node.
>
> In the past 4 months, Forkmonitor has registered 11 stale and invalid
> blocks[4]. Extrapolating from that data, a PoW FP node verifying Bitcoin
> consensus would have to download and verify a little over 100MB per year in
> order to have consensus guarantees that come close to that of a full node:
> - All PoW headers (~4MB per year)
> - 3 x 11 = 33 full blocks (~2MB x 33 = 66MB)
> - UTXO merkle proofs (~1MB x 33 = 33MB with utreexo)
>
> The reason consensus is considered slow, is because we need to allow time
> for a honest PoW minority to fork away from an invalid chain. If we assume
> only 1% of all miners are honest, this means consensus slows down by 100x.
> If you are normally satisfied waiting for 6 confirmations, you now need to
> wait 600 confirmations. The longer you wait, the less honest miners you
> need.
>
>
> Softchains
>
> In order to have two-way pegged sidechains, you need a succinct method for
> proving to the mainchain that a peg-out is valid. PoW FP provides exactly
> that -- a low-bandwidth way of determining if a chain, and thus a peg-out,
> is valid. The slowness of PoW FP consensus is not an issue, as peg-outs can
> be made arbitrarily slow (e.g. one year).
>
> The safest design would be a set of softchains that shares its consensus
> code with Bitcoin Core, with the addition of UTXO set commitments, and
> disabling non-taproot address types to minimize certain resource usage
> issues[5]. All users validate the mainchain as usual with their full node,
> and all softchains are validated with PoW FP consensus. If a user is
> interested in directly using a specific softchain, they should run it as a
> full node in order to get fast consensus.
>
> Peg-ins occur by freezing coins on the mainchain and assigning them to a
> softchain. Peg-outs occur by creating a mainchain transaction that points
> to a peg-out transaction on a softchain and waiting for a sufficient number
> of mainchain confirmations. If the peg-out transaction remains part of the
> softchain according to PoW FP consensus, the coins become spendable.
>
> The peg-in/peg-out mechanism itself would require a soft fork (the exact
> design is an open question), and subsequently every softchain that gets
> activated will also require a soft fork.
>
>
> Potential dangers
>
> Softchain consensus still requires a form of validation from mainchain
> users, which means that consensus bugs can have an adverse effect. In
> particular, if a softchain suffers from a non-deterministic consensus bug,
> it may be the case that a majority accepts a peg-in, while a minority
> rejects it. This specific scenario could cause a chain split in mainchain
> consensus. This is why it would be safest to base softchain designs on
> Bitcoin Core.
>
> Similarly, it can theoretically be possible that a softchain gets a major
> reorg, invalidating a peg-out right as it would have become accepted on the
> mainchain, thus splitting consensus. The slow peg-out process makes this
> increasingly unlikely, but not impossible. One thing that might help (or
> perhaps only make it worse) is introducing a consensus rule that disallows
> reorgs that are bigger than half the peg-out time (e.g. half a year, if the
> peg-out is one year). This kind of rule does not actually solve this
> consensus problem, but instead pushes the problem forward so it plays out
> first on the softchain, giving time to take action before the problem
> affects the mainchain.
>
> It is also important that each softchain produces a non-trivial amount of
> PoW, because if the difficulty is too low, the cost of creating forks and
> increasing the resource usage of PoW FP consensus goes down. It may
> therefore make sense to have a minimum accepted difficulty for softchain
> blocks (slowing down the chain when fees are not sufficient). Merged Mining
> could also help here, since that would allow the softchains to potentially
> receive the same hashrate as Bitcoin (assuming all miners participate), but
> of course this would also put an additional validation burden on miners.
>
>
> In closing
>
> It may turn out that the consensus risks outlined above make this
> prohibitively risky, but at the very least it seems worth exploring the
> possibilities. At a minimum it would provide more opt-in block space, and
> it could potentially open the door to chains with entirely different
> consensus rules.
>
> Thank you for taking the time to read and comprehend my work. I will
> happily answer any questions and I look forward to any feedback on issues
> that I might have overlooked, and ideas on mitigating problems to ensure
> maximum safety.
>
> Hopefully this will bring decentralized two-way peg sidechains one step
> closer to becoming a reality.
>
> Happy new year, everyone.
>
>
> -- Ruben Somsen
>
>
>
> This post is mirrored and kept up-to-date here:
> https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1
>
>
> [0] Drivechains
> https://www.drivechain.info/
>
> [1] PoW FP
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-April/016873.html
>
> [2] PoW FP without a soft fork
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017287.html
>
> [3]: utreexo
> https://eprint.iacr.org/2019/611.pdf
>
> [4]: Forkmonitor
> https://forkmonitor.info/notifications
>
> [5]: Harding on worst-case utreexo
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017298.html
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201231/3ee7d3df/attachment-0001.html>;
Sergio Demian Lerner [ARCHIVE] /
npub1fvâŠ3vq7f
2023-06-07 18:28:00
in reply to nevent1qâŠu96f
Author Public Key
npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7fPublished at
2023-06-07 18:28:00Event JSON
{
"id": "c028350b98d74b8827a2122ae2001fc524b9f60d4b01ddabed9b359db125b7d5",
"pubkey": "4b38603408f5be002091210e869a4ca86fc2aa1ffd0871036a0668068ee626ee",
"created_at": 1686162480,
"kind": 1,
"tags": [
[
"e",
"43942924ea6b3bc6d9ab99b8f5944d73a88a93380a3a5f74ac2f8e391d64b89a",
"",
"root"
],
[
"e",
"f859d702b53154abf045076980b9f862d8bcf571154338db764c2d7c3ea0b83d",
"",
"reply"
],
[
"p",
"c4c73e48c7d7f313938a90d71ff5e4be5d01dd4157f98ed99adf14737bfb78e0"
]
],
"content": "ð
Original date posted:2020-12-31\nð Original message:Hi Roben,\n It's an interesting proposal, but I have two issues with it, one technical\nand one philosophical.\n\nOn the technical side, I don't understand how your proposal prevents miners\nproposing a peg-out for an invalid sidechain fork which is not made\navailable to the nodes (there are missing blocks). It seems that the system\nwould need to allow users to challenge miners to make available full\nsidechain blocks that are missing, which really complicates the protocol.\n\nOn the philosophical side, as you mentioned, it is very limited in the\ntypes of sidechains it can verify. I won't be able to verify RSK\n(merge-mined with Bitcoin, but with different block format and different\nfunctionality). It cannot verify a zCash-like sidechain for the same\nreasons. Therefore it is strictly a payment scalability solution.\nDrivechains, on the other hand, enable many new use cases apart from\nscaling, which have a much lower level of complexity (if implemented\ncorrectly).\n\nSince the inception of RSK sidechain, I suggested in its white-paper that\nsidechains should be designed to support an hybrid peg-out system, based on\nboth a large multisig AND a drivechain, where both groups need to agree for\nthe peg-out to occur. It's a censorship/security trade-off that most users\nwould be willing to accept until a trusted-setup-free SNARK-like based\nsolution is finally available.\nUntil we have a sidechain-selectable SNARK-like succinct verification of\nany block state transition function, having a single succint proof to cover\nthe whole sidechain validity, as in Coda (now renamed Mina), drivechains\nare the low-hanging-fruit.\n\nregards\n\nOn Thu, Dec 31, 2020 at 7:01 PM Ruben Somsen via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi everyone,\n\u003e\n\u003e This post describes a fully decentralized two-way peg sidechain design.\n\u003e Activating new sidechains requires a soft fork, hence the name softchains.\n\u003e The key aspect is that all softchains are validated by everyone via\n\u003e Proof-of-Work Fraud Proofs (PoW FP) -- a slow but very efficient consensus\n\u003e mechanism that only requires the validation of disputed blocks. This does\n\u003e increase the validation burden of mainchain full nodes, but only by a\n\u003e minimal amount (~100MB per chain per year). It's similar to drivechains[0],\n\u003e but without the major downside of having to rely on miners, since all\n\u003e Bitcoin full node users can efficiently validate each sidechain.\n\u003e\n\u003e\n\u003e Proof-of-Work Fraud Proofs\n\u003e\n\u003e Last year I posted the idea of PoW FP to the Bitcoin mailing list[1][2].\n\u003e The idea is that we can use the existence of a fork in Bitcoin's PoW as\n\u003e evidence that a block might be invalid (i.e. a proof of potential fraud).\n\u003e Whenever this occurs, we download the block in question to verify whether\n\u003e it was valid (and available), and reject it if it was not. We forego the\n\u003e need for maintaining a UTXO set with UTXO set commitments (such as\n\u003e utreexo[3]), by assuming that the commitment inside the last block to exist\n\u003e in both forks is valid. As a result, we only need to download as many\n\u003e blocks (and their corresponding UTXO set proofs) as there are orphans,\n\u003e which lowers the validation costs considerably compared to running a full\n\u003e node.\n\u003e\n\u003e In the past 4 months, Forkmonitor has registered 11 stale and invalid\n\u003e blocks[4]. Extrapolating from that data, a PoW FP node verifying Bitcoin\n\u003e consensus would have to download and verify a little over 100MB per year in\n\u003e order to have consensus guarantees that come close to that of a full node:\n\u003e - All PoW headers (~4MB per year)\n\u003e - 3 x 11 = 33 full blocks (~2MB x 33 = 66MB)\n\u003e - UTXO merkle proofs (~1MB x 33 = 33MB with utreexo)\n\u003e\n\u003e The reason consensus is considered slow, is because we need to allow time\n\u003e for a honest PoW minority to fork away from an invalid chain. If we assume\n\u003e only 1% of all miners are honest, this means consensus slows down by 100x.\n\u003e If you are normally satisfied waiting for 6 confirmations, you now need to\n\u003e wait 600 confirmations. The longer you wait, the less honest miners you\n\u003e need.\n\u003e\n\u003e\n\u003e Softchains\n\u003e\n\u003e In order to have two-way pegged sidechains, you need a succinct method for\n\u003e proving to the mainchain that a peg-out is valid. PoW FP provides exactly\n\u003e that -- a low-bandwidth way of determining if a chain, and thus a peg-out,\n\u003e is valid. The slowness of PoW FP consensus is not an issue, as peg-outs can\n\u003e be made arbitrarily slow (e.g. one year).\n\u003e\n\u003e The safest design would be a set of softchains that shares its consensus\n\u003e code with Bitcoin Core, with the addition of UTXO set commitments, and\n\u003e disabling non-taproot address types to minimize certain resource usage\n\u003e issues[5]. All users validate the mainchain as usual with their full node,\n\u003e and all softchains are validated with PoW FP consensus. If a user is\n\u003e interested in directly using a specific softchain, they should run it as a\n\u003e full node in order to get fast consensus.\n\u003e\n\u003e Peg-ins occur by freezing coins on the mainchain and assigning them to a\n\u003e softchain. Peg-outs occur by creating a mainchain transaction that points\n\u003e to a peg-out transaction on a softchain and waiting for a sufficient number\n\u003e of mainchain confirmations. If the peg-out transaction remains part of the\n\u003e softchain according to PoW FP consensus, the coins become spendable.\n\u003e\n\u003e The peg-in/peg-out mechanism itself would require a soft fork (the exact\n\u003e design is an open question), and subsequently every softchain that gets\n\u003e activated will also require a soft fork.\n\u003e\n\u003e\n\u003e Potential dangers\n\u003e\n\u003e Softchain consensus still requires a form of validation from mainchain\n\u003e users, which means that consensus bugs can have an adverse effect. In\n\u003e particular, if a softchain suffers from a non-deterministic consensus bug,\n\u003e it may be the case that a majority accepts a peg-in, while a minority\n\u003e rejects it. This specific scenario could cause a chain split in mainchain\n\u003e consensus. This is why it would be safest to base softchain designs on\n\u003e Bitcoin Core.\n\u003e\n\u003e Similarly, it can theoretically be possible that a softchain gets a major\n\u003e reorg, invalidating a peg-out right as it would have become accepted on the\n\u003e mainchain, thus splitting consensus. The slow peg-out process makes this\n\u003e increasingly unlikely, but not impossible. One thing that might help (or\n\u003e perhaps only make it worse) is introducing a consensus rule that disallows\n\u003e reorgs that are bigger than half the peg-out time (e.g. half a year, if the\n\u003e peg-out is one year). This kind of rule does not actually solve this\n\u003e consensus problem, but instead pushes the problem forward so it plays out\n\u003e first on the softchain, giving time to take action before the problem\n\u003e affects the mainchain.\n\u003e\n\u003e It is also important that each softchain produces a non-trivial amount of\n\u003e PoW, because if the difficulty is too low, the cost of creating forks and\n\u003e increasing the resource usage of PoW FP consensus goes down. It may\n\u003e therefore make sense to have a minimum accepted difficulty for softchain\n\u003e blocks (slowing down the chain when fees are not sufficient). Merged Mining\n\u003e could also help here, since that would allow the softchains to potentially\n\u003e receive the same hashrate as Bitcoin (assuming all miners participate), but\n\u003e of course this would also put an additional validation burden on miners.\n\u003e\n\u003e\n\u003e In closing\n\u003e\n\u003e It may turn out that the consensus risks outlined above make this\n\u003e prohibitively risky, but at the very least it seems worth exploring the\n\u003e possibilities. At a minimum it would provide more opt-in block space, and\n\u003e it could potentially open the door to chains with entirely different\n\u003e consensus rules.\n\u003e\n\u003e Thank you for taking the time to read and comprehend my work. I will\n\u003e happily answer any questions and I look forward to any feedback on issues\n\u003e that I might have overlooked, and ideas on mitigating problems to ensure\n\u003e maximum safety.\n\u003e\n\u003e Hopefully this will bring decentralized two-way peg sidechains one step\n\u003e closer to becoming a reality.\n\u003e\n\u003e Happy new year, everyone.\n\u003e\n\u003e\n\u003e -- Ruben Somsen\n\u003e\n\u003e\n\u003e\n\u003e This post is mirrored and kept up-to-date here:\n\u003e https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1\n\u003e\n\u003e\n\u003e [0] Drivechains\n\u003e https://www.drivechain.info/\n\u003e\n\u003e [1] PoW FP\n\u003e\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-April/016873.html\n\u003e\n\u003e [2] PoW FP without a soft fork\n\u003e\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017287.html\n\u003e\n\u003e [3]: utreexo\n\u003e https://eprint.iacr.org/2019/611.pdf\n\u003e\n\u003e [4]: Forkmonitor\n\u003e https://forkmonitor.info/notifications\n\u003e\n\u003e [5]: Harding on worst-case utreexo\n\u003e\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017298.html\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201231/3ee7d3df/attachment-0001.html\u003e",
"sig": "f72eaa1ed22a476b16131a25053606662ad2b0ced87e3dbf54bea1fcc1c8cc5d82ce818f798d1a0e81d5c312fd0df85452f705ad980469c020a5f7fbdf42986d"
}