📅 Original date posted:2015-06-16
📝 Original message:On Tue, Jun 16, 2015 at 6:17 PM, Peter Todd <pete at petertodd.org> wrote:
> Merge-mined sidechains are not a scaling solution any more than SPV is a
> scaling solution because they don't solve the scaling problem for
> miners.
>
> Some kind of treechain like sidechain / subchains where what part of the
> tree miners can mine is constrained to preserve fairness could be both a
> scaling solution, and decentralized, but no-one has come up with a solid
> design yet that's ready for production. (my treechains don't qualify for
> transactions yet; maybe for other proof-of-publication uses)
>
>
Well doesn't my proposal solve the miner decentralization problem. Only the
direct parent and children chains are merge mined. To be more clear, let
the top chain to have level 1. Each chain that is a child of a chain of
level n has level n+1. For any chain C, a block is accepted if the hash of
its header has an appropriate number of trailing zeros (as usual). It can
also be accepted with special transactions as I will explain. Let C be a
chain of level n. Let C0,C1,....,C9 be its children (each of level n+1).
For any i in {0,1,...,9}, any solution to the mining problem of C can be
inserted as a special transaction inside Ci and this enables the block to
be accepted in Ci (so C and C0,C1,...,C9 are merge mined. But, for any i in
{0,1,...,9} and any j in {0,1,...,9}, any solution to the mining problem of
C cannot be inserted as a special transaction inside of child Cij of Ci. So
that means all of the chains are not merge mined, only localised parts,
right?
By the way, we can eventually get rid of the block size 1 MB limit by
requiring more than just the header to be hashed, but that can be done in
the future as soft fork with sidechains, and is a side topic.
--
PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/f1e0d73a/attachment.html>;
Andrew [ARCHIVE] /
npub1l8…hm88x
2023-06-07 15:37:47
in reply to nevent1q…84z2
Author Public Key
npub1l899vmy2zhg9zr96jvnxt85ayddd26qu36m02k22759e9djqldnqrhm88xPublished at
2023-06-07 15:37:47Event JSON
{
"id": "7c7ead4711dea3d993b469abcd2c4ea85d6d5f2ac5fd0d0c86e8d3569451d45b",
"pubkey": "f9ca566c8a15d0510cba9326659e9d235ad5681c8eb6f5594af50b92b640fb66",
"created_at": 1686152267,
"kind": 1,
"tags": [
[
"e",
"1eef2249ef2ccb9b29d0cfb214899c0200af52104249c9e48060be1ef0ababcc",
"",
"root"
],
[
"e",
"d1d37dee93b1236c677a2ba38900883fb0073207a9e7b76b73f2f165a4a4a1f7",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2015-06-16\n📝 Original message:On Tue, Jun 16, 2015 at 6:17 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e Merge-mined sidechains are not a scaling solution any more than SPV is a\n\u003e scaling solution because they don't solve the scaling problem for\n\u003e miners.\n\u003e\n\u003e Some kind of treechain like sidechain / subchains where what part of the\n\u003e tree miners can mine is constrained to preserve fairness could be both a\n\u003e scaling solution, and decentralized, but no-one has come up with a solid\n\u003e design yet that's ready for production. (my treechains don't qualify for\n\u003e transactions yet; maybe for other proof-of-publication uses)\n\u003e\n\u003e\nWell doesn't my proposal solve the miner decentralization problem. Only the\ndirect parent and children chains are merge mined. To be more clear, let\nthe top chain to have level 1. Each chain that is a child of a chain of\nlevel n has level n+1. For any chain C, a block is accepted if the hash of\nits header has an appropriate number of trailing zeros (as usual). It can\nalso be accepted with special transactions as I will explain. Let C be a\nchain of level n. Let C0,C1,....,C9 be its children (each of level n+1).\nFor any i in {0,1,...,9}, any solution to the mining problem of C can be\ninserted as a special transaction inside Ci and this enables the block to\nbe accepted in Ci (so C and C0,C1,...,C9 are merge mined. But, for any i in\n{0,1,...,9} and any j in {0,1,...,9}, any solution to the mining problem of\nC cannot be inserted as a special transaction inside of child Cij of Ci. So\nthat means all of the chains are not merge mined, only localised parts,\nright?\n\nBy the way, we can eventually get rid of the block size 1 MB limit by\nrequiring more than just the header to be hashed, but that can be done in\nthe future as soft fork with sidechains, and is a side topic.\n\n\n-- \nPGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/f1e0d73a/attachment.html\u003e",
"sig": "d30258e7f5abe7189b6ff3285e4ae2688d98ad4c379ff529d8275e5de813da470f3867243013ff078ad3bd8bdb5ad7366dbbcb2935fb2b0cd14df239a4459776"
}