📅 Original date posted:2017-12-03
📝 Original message:Process note: It looks like the BIPs have never been posted to
bitcoin-dev, only high-level discussion around the idea. As I understand
it, this is *not* sufficient for BIP number assignment nor
(realistically) sufficient to call it a hard "proposal" for a change to
consensus rules.
Would love to get feedback from some others who are looking at deploying
real-world sidechains, eg the RSK folks. We can't end up with *two*
protocols for sidechains in Bitcoin.
Comments on BIP 1:
At a high level, I'm rather dissapointed by the amount of data that is
going into the main chain here. Things such as a human readable name
have no place in the chain, IMO. Further, the use of a well-known
private key seems misplaced, why not just track the sidechain balance
with something that looks like `OP_NOPX genesis_block_hash`?
I'm not convinced by the full semantics of proposal/ack of new
sidechains. Given the lack of convincing evidence of that "Risk of
centralisation of mining" drawback in section 4.3 of the sidechains
paper has been meaningfully addressed, I'd say its pretty important that
new sidechains be an incredibly rare event. Thus, a much simpler system
(eg a version-bits-based upgrade cycle with high threshold) could be
used to add new sidechains based on well-known public parameters.
The semantics of the deposit process seem very suboptimal. You note that
only one user can deposit at a time, but this seems entirely
unnecessary. As implemented in the first Elements Alpha release (though
I believe subsequently removed in later versions due to the nature of
Elements of targeting asymmetric "federated" sidechains), if you have
outputs that look like `OP_NOPX genesis_block_hash` as the sidechain
deposit/storage address, deposit can be fully parallel. To reduce
blockchain bloat, spending them for the purpose of combining such
outputs is also allowed. You could even go further and allow some new
sighash type to define something like SIGHASH_ALL|SIGHASH_ANYONECANPAY
which further specifies some semantics for combining inputs which all
pay into the same output.
Finally, you may also want to explore some process for the removal of
sidechain balances from the main chain. As proposed it seems like a
sidechain might, over time, fade into an insecure state as mining power
shifts and new miners no longer consider it worth the value to mine an
old sidechain (as has happened over time with namecoin, arguably).
Comments on BIP 2:
I may be missing something, but I find the security model here kind of
depressing...Not only do hashpower-secured sidechains already have a
significantly reduced security level, but now you're proposing to
further (drastically) reduce it by requiring users to potentially pay in
excess of the value an attacker is willing to pay to keep their chain
secure, on a recurring basis? It seems like if a chain has 10 BTC stored
in it, and I wish to reorg it for a potential gain of, lets say, 6 BTC,
I can pay 6 * 1 BTC (1 per block) to reorg it, and users on the chain
would be forced to pay >6 BTC to avoid this?
While I appreciate the desire to implement the proposed mitigation in
section 4.3 of the sidechains paper (delegating the mining effort of a
merge-mined sidechain to an external entity), I believe it was primarily
referencing pooling the sidechain work, not blindly taking the highest
bidder. I suppose, indeed, that, ultimately, as long as the sidechain is
of relatively small value in comparison to BTC, miners do not risk the
value of their BTC/mining investment in simply taking the highest bidder
of a merge-mined block, even if its a clear attack, but I don't think
thats something to be celebrated, encouraged, or designed to be possible
by default. Instead, I'd, in line with Peter Todd's (and others')
objection to merged mining generally, call this one of the most critical
issues with the security model.
Ultimately, I dont believe your proposal here really solves the drawback
in section 4.3 of the paper, and possibly makes it worse. Instead, it
may be more useful to rely on a high threshold for the addition of new
sidechains, though I'd love to see discussion on this point specifically
on this list. Further, I'd say, at a minimum, a very stable
default-available low-bandwidth implementation of at least the
pool-based mitigation suggested in the paper must exist for something
like this to be considered readily stable enough to be deployed into the
Bitcoin ecosystem.
Matt
On 12/01/17 13:38, Paul Sztorc via bitcoin-dev wrote:
> Hello,
>
> First, Drivechain has vaguely escaped vaporware status. If you've ever
> thought "I'd like to take a look into Drivechain when there is code",
> then now is a pretty good time. (Unfinished items include M1, and M8_V2.)
>
> https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
>
> Also,
> Site: http://www.drivechain.info/
> Blank sidechain:
> https://github.com/drivechain-project/bitcoin/tree/sidechainBMM
>
> Second, I think drivechain's documentation / BIP-Drafts are tolerably
> readable.
>
> Here they are:
>
> 1.
> https://github.com/drivechain-project/docs/blob/master/bip1-hashrate-escrow.md
> 2.
> https://github.com/drivechain-project/docs/blob/master/bip2-blind-merged-mining.md
>
> cc: Luke, I think they are ready to be assigned formal BIP Numbers.
>
> This is also a request for code review. The most helpful review will
> probably take place on GitHub.
>
> Regular review is also welcome. Although, please read our
> recently-updated FAQ, at: http://www.drivechain.info/faq .
> And also see major earlier discussions:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014364.html
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014559.html
>
> Have a nice weekend everyone,
> Paul
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-07 18:08:06
in reply to nevent1q…0nvu
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuPublished at
2023-06-07 18:08:06Event JSON
{
"id": "8f355e759f06ceb3ef46a2ed9c5b710bce70c5d4507ba10c67d360ee8eb57515",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686161286,
"kind": 1,
"tags": [
[
"e",
"c96ad839ccc24a876eef1f6059684f6b22ca896fbabb922d4cebc940941cd895",
"",
"root"
],
[
"e",
"7e0831dba7a004f6c2f99a7e4cc6d9590459c7d274af79ed1d0d8cb121e67e6f",
"",
"reply"
],
[
"p",
"7ac0bd39b854f24cbf067103758f3a9d398c23832d6d75824d190ae35c6c23be"
]
],
"content": "📅 Original date posted:2017-12-03\n📝 Original message:Process note: It looks like the BIPs have never been posted to\nbitcoin-dev, only high-level discussion around the idea. As I understand\nit, this is *not* sufficient for BIP number assignment nor\n(realistically) sufficient to call it a hard \"proposal\" for a change to\nconsensus rules.\n\nWould love to get feedback from some others who are looking at deploying\nreal-world sidechains, eg the RSK folks. We can't end up with *two*\nprotocols for sidechains in Bitcoin.\n\nComments on BIP 1:\n\nAt a high level, I'm rather dissapointed by the amount of data that is\ngoing into the main chain here. Things such as a human readable name\nhave no place in the chain, IMO. Further, the use of a well-known\nprivate key seems misplaced, why not just track the sidechain balance\nwith something that looks like `OP_NOPX genesis_block_hash`?\n\nI'm not convinced by the full semantics of proposal/ack of new\nsidechains. Given the lack of convincing evidence of that \"Risk of\ncentralisation of mining\" drawback in section 4.3 of the sidechains\npaper has been meaningfully addressed, I'd say its pretty important that\nnew sidechains be an incredibly rare event. Thus, a much simpler system\n(eg a version-bits-based upgrade cycle with high threshold) could be\nused to add new sidechains based on well-known public parameters.\n\nThe semantics of the deposit process seem very suboptimal. You note that\nonly one user can deposit at a time, but this seems entirely\nunnecessary. As implemented in the first Elements Alpha release (though\nI believe subsequently removed in later versions due to the nature of\nElements of targeting asymmetric \"federated\" sidechains), if you have\noutputs that look like `OP_NOPX genesis_block_hash` as the sidechain\ndeposit/storage address, deposit can be fully parallel. To reduce\nblockchain bloat, spending them for the purpose of combining such\noutputs is also allowed. You could even go further and allow some new\nsighash type to define something like SIGHASH_ALL|SIGHASH_ANYONECANPAY\nwhich further specifies some semantics for combining inputs which all\npay into the same output.\n\nFinally, you may also want to explore some process for the removal of\nsidechain balances from the main chain. As proposed it seems like a\nsidechain might, over time, fade into an insecure state as mining power\nshifts and new miners no longer consider it worth the value to mine an\nold sidechain (as has happened over time with namecoin, arguably).\n\n\nComments on BIP 2:\n\nI may be missing something, but I find the security model here kind of\ndepressing...Not only do hashpower-secured sidechains already have a\nsignificantly reduced security level, but now you're proposing to\nfurther (drastically) reduce it by requiring users to potentially pay in\nexcess of the value an attacker is willing to pay to keep their chain\nsecure, on a recurring basis? It seems like if a chain has 10 BTC stored\nin it, and I wish to reorg it for a potential gain of, lets say, 6 BTC,\nI can pay 6 * 1 BTC (1 per block) to reorg it, and users on the chain\nwould be forced to pay \u003e6 BTC to avoid this?\n\nWhile I appreciate the desire to implement the proposed mitigation in\nsection 4.3 of the sidechains paper (delegating the mining effort of a\nmerge-mined sidechain to an external entity), I believe it was primarily\nreferencing pooling the sidechain work, not blindly taking the highest\nbidder. I suppose, indeed, that, ultimately, as long as the sidechain is\nof relatively small value in comparison to BTC, miners do not risk the\nvalue of their BTC/mining investment in simply taking the highest bidder\nof a merge-mined block, even if its a clear attack, but I don't think\nthats something to be celebrated, encouraged, or designed to be possible\nby default. Instead, I'd, in line with Peter Todd's (and others')\nobjection to merged mining generally, call this one of the most critical\nissues with the security model.\n\nUltimately, I dont believe your proposal here really solves the drawback\nin section 4.3 of the paper, and possibly makes it worse. Instead, it\nmay be more useful to rely on a high threshold for the addition of new\nsidechains, though I'd love to see discussion on this point specifically\non this list. Further, I'd say, at a minimum, a very stable\ndefault-available low-bandwidth implementation of at least the\npool-based mitigation suggested in the paper must exist for something\nlike this to be considered readily stable enough to be deployed into the\nBitcoin ecosystem.\n\nMatt\n\nOn 12/01/17 13:38, Paul Sztorc via bitcoin-dev wrote:\n\u003e Hello,\n\u003e \n\u003e First, Drivechain has vaguely escaped vaporware status. If you've ever\n\u003e thought \"I'd like to take a look into Drivechain when there is code\",\n\u003e then now is a pretty good time. (Unfinished items include M1, and M8_V2.)\n\u003e \n\u003e https://github.com/drivechain-project/bitcoin/tree/mainchainBMM\n\u003e \n\u003e Also,\n\u003e Site: http://www.drivechain.info/\n\u003e Blank sidechain:\n\u003e https://github.com/drivechain-project/bitcoin/tree/sidechainBMM\n\u003e \n\u003e Second, I think drivechain's documentation / BIP-Drafts are tolerably\n\u003e readable.\n\u003e \n\u003e Here they are:\n\u003e \n\u003e 1.\n\u003e https://github.com/drivechain-project/docs/blob/master/bip1-hashrate-escrow.md\n\u003e 2.\n\u003e https://github.com/drivechain-project/docs/blob/master/bip2-blind-merged-mining.md\n\u003e \n\u003e cc: Luke, I think they are ready to be assigned formal BIP Numbers.\n\u003e \n\u003e This is also a request for code review. The most helpful review will\n\u003e probably take place on GitHub.\n\u003e \n\u003e Regular review is also welcome. Although, please read our\n\u003e recently-updated FAQ, at: http://www.drivechain.info/faq .\n\u003e And also see major earlier discussions:\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014364.html\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014559.html\n\u003e \n\u003e Have a nice weekend everyone,\n\u003e Paul\n\u003e \n\u003e \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",
"sig": "f74061b83e128303a35d403b8e5126f4e94a446dbca8bc8c59ea54b4d9064973a273e3f41697b0561e1d7a3290bff1bc005c99f6d7a6422cfffd0a7bd75c993f"
}