📅 Original date posted:2017-12-05
📝 Original message:Hi Other Chris,
Thanks for pointing this out. Here are my responses.
On 12/4/2017 3:11 PM, Chris Stewart wrote:
>There is another interesting analysis on BMM and drivechains from
/u/almkglor on reddit. I'm going to share here for visibility.
>> 3 and 7 will mean that non-verifying miners will be (inadvertently)
complicit in theft. Drivechains have 1008-block cycles ostensibly to
protect against theft, so that someone can "raise the alarm" and tell
miners to downvote a particular theft withdrawal, but that sounds too
much like centralized collusion to me.
Well, that is simply not what "centralized" means. "Centralized" means
that one person has special, irreplaceable influence. In contrast,
"decentralized" means that the process is not uniquely influenced by
what any *one* individual does or believes. Which is the case here: each
miner can independently make a decision about what to check, how to
check it, and what to do as a result. They could do undertake this
process, even if they ignored what everyone else was doing.
>> ...
>>
>> It seems Drivechain's security model is: miners always upvote by
default. If a theft withdrawal is done on the mainchain, some sidechain
nodes call up their miner friends (which makes me worry about miner
centralization) to downvote it instead.
>>
>> The problem is: what if after a theft withdrawal is defeated, another
theft withdrawal is done? And another, and another? This weakens the
peg: while a theft withdrawal is on-going, a genuine withdrawal can't be
posted (at least as I understand Sztorc's explanation). This chokes the
sidechain withdrawal.
This is a good question.
The answer is that there are mechanisms in place to address these
problems. Contrary to the reviewer's interpretation, multiple
withdrawal-attempts *are* allowed simultaneously. (This part of design
may have changed between now and Nov 2015, and I'm not sure if it was
ever documented anywhere until very recently). Second, only one
withdrawal can be upvoted at a time [ie, per sidechain per main:block].
Third, upvoting one withdrawal automatically downvotes all of the other
withdrawals (all in-progress withdrawals for that sidechain). Thus, we
have the asymmetry we desire. An "auditor class" can ignore all of the
withdrawals, until a significant amount of time has been invested in one
candidate. This makes the attempt more futile. Since they are unlikely
to be meaninglessly harassed, this opens the door to a "farmer class"
who can take it upon themselves to make sure the good withdrawals get
in, and get upvotes (especially early upvotes). Thus, the system can
tolerate a large "loafer class" who just lazily upvotes everything (or
nothing, or only the front-runner).
> TLDR: a miner is most profitable if he always accepts BMM bribes, but
downvotes withdrawal transactions (WT). This obviously isn't ideal
because a withdrawal will never occur from the drivechain if enough
miners employ this strategy -- which seems to be the most profitable
strategy.
>
>-Chris
I agree that miners should "always accept BMM bribes". In my recent
email to Matt Corallo, I described that this is basically the same as
saying that miners should "always mine on top of the heaviest chain".
(Of course, in mainchain Bitcoin miners are advised to mine atop the
heaviest *valid* chain, which is different from this case. It is
different because blind-merged-miners have no way of knowing if the
sidechain blocks they are mining are valid or not, which is kind of the
point. In practice I estimate that between 70% and 100% of today's
hashpower is already mining the mainchain "blind" -- through some
combination of pools, spv and spy mining.)
I don't agree with the conclusion (that the optimal policy is "always
downvoting", see above), but even if this analysis turns out to be
correct, it isn't a total disaster. The result (which is in the original
Nov 2015 specification) is that miners are the ones who perform the
atomic swaps. Then they walk the coins side-to-main (which, at this
point, are *their* coins). As long as there are a few large mining
groups, competition will drive the atomic swap fees down to negligible
levels. This slightly encourages mining to consolidate into two large
pools...but of course that is also true of the status quo!
Paul
>
> On Mon, Dec 4, 2017 at 1:36 PM, Chris Pacia via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>
> I think you are missing a few things.
>
> First of all, I think the security model for sidechains is the
> same as
> that of every blockchain
>
> People will say things, like "but with sidechains 51% hashrate
> can steal
> your coins!", but as I have repeated many times, this is also
> true of
> mainchain btc-tx. is something else?
>
>
> There are substantial opportunity costs as well as a collective
> action problem when it comes to re-writing the mainchain.
>
> Is there anything similar for drivechains? As far as I can tell
> there is no opportunity cost to casting a malicious vote, no
> repercussions, and no collective action barrier that needs to be
> overcome.
>
> Unless I'm missing something I wouldn't liken the security of a
> drivechain to that of the mainchain.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171205/1ade3365/attachment.html>;
Paul Sztorc [ARCHIVE] /
npub10t…w9uu9
2023-06-07 18:08:08
in reply to nevent1q…vmkg
Author Public Key
npub10tqt6wdc2neye0cxwyphtre6n5uccgur94khtqjdry9wxhrvywlq6w9uu9Published at
2023-06-07 18:08:08Event JSON
{
"id": "7ee8cc443f0446a9998e240091ff2f1a72b0c360176df43084cc9d2fc50a1599",
"pubkey": "7ac0bd39b854f24cbf067103758f3a9d398c23832d6d75824d190ae35c6c23be",
"created_at": 1686161288,
"kind": 1,
"tags": [
[
"e",
"c96ad839ccc24a876eef1f6059684f6b22ca896fbabb922d4cebc940941cd895",
"",
"root"
],
[
"e",
"3278cde1fc466ee8a67e151909b979b678852f163ebb91534624b46a8d8c3571",
"",
"reply"
],
[
"p",
"e3e3813ca5b2f45117ae42a2a1c99f5c6bd172c115acc2538066aad916544817"
]
],
"content": "📅 Original date posted:2017-12-05\n📝 Original message:Hi Other Chris,\n\nThanks for pointing this out. Here are my responses.\n\nOn 12/4/2017 3:11 PM, Chris Stewart wrote:\n\u003eThere is another interesting analysis on BMM and drivechains from\n/u/almkglor on reddit. I'm going to share here for visibility.\n\u003e\u003e 3 and 7 will mean that non-verifying miners will be (inadvertently)\ncomplicit in theft. Drivechains have 1008-block cycles ostensibly to\nprotect against theft, so that someone can \"raise the alarm\" and tell\nminers to downvote a particular theft withdrawal, but that sounds too\nmuch like centralized collusion to me.\n\nWell, that is simply not what \"centralized\" means. \"Centralized\" means\nthat one person has special, irreplaceable influence. In contrast,\n\"decentralized\" means that the process is not uniquely influenced by\nwhat any *one* individual does or believes. Which is the case here: each\nminer can independently make a decision about what to check, how to\ncheck it, and what to do as a result. They could do undertake this\nprocess, even if they ignored what everyone else was doing.\n\n\u003e\u003e ...\n\u003e\u003e\n\u003e\u003e It seems Drivechain's security model is: miners always upvote by\ndefault. If a theft withdrawal is done on the mainchain, some sidechain\nnodes call up their miner friends (which makes me worry about miner\ncentralization) to downvote it instead.\n\u003e\u003e\n\u003e\u003e The problem is: what if after a theft withdrawal is defeated, another\ntheft withdrawal is done? And another, and another? This weakens the\npeg: while a theft withdrawal is on-going, a genuine withdrawal can't be\nposted (at least as I understand Sztorc's explanation). This chokes the\nsidechain withdrawal.\n\nThis is a good question.\n\nThe answer is that there are mechanisms in place to address these\nproblems. Contrary to the reviewer's interpretation, multiple\nwithdrawal-attempts *are* allowed simultaneously. (This part of design\nmay have changed between now and Nov 2015, and I'm not sure if it was\never documented anywhere until very recently). Second, only one\nwithdrawal can be upvoted at a time [ie, per sidechain per main:block].\nThird, upvoting one withdrawal automatically downvotes all of the other\nwithdrawals (all in-progress withdrawals for that sidechain). Thus, we\nhave the asymmetry we desire. An \"auditor class\" can ignore all of the\nwithdrawals, until a significant amount of time has been invested in one\ncandidate. This makes the attempt more futile. Since they are unlikely\nto be meaninglessly harassed, this opens the door to a \"farmer class\"\nwho can take it upon themselves to make sure the good withdrawals get\nin, and get upvotes (especially early upvotes). Thus, the system can\ntolerate a large \"loafer class\" who just lazily upvotes everything (or\nnothing, or only the front-runner).\n\n\u003e TLDR: a miner is most profitable if he always accepts BMM bribes, but\ndownvotes withdrawal transactions (WT). This obviously isn't ideal\nbecause a withdrawal will never occur from the drivechain if enough\nminers employ this strategy -- which seems to be the most profitable\nstrategy.\n\u003e\n\u003e-Chris\n\nI agree that miners should \"always accept BMM bribes\". In my recent\nemail to Matt Corallo, I described that this is basically the same as\nsaying that miners should \"always mine on top of the heaviest chain\".\n(Of course, in mainchain Bitcoin miners are advised to mine atop the\nheaviest *valid* chain, which is different from this case. It is\ndifferent because blind-merged-miners have no way of knowing if the\nsidechain blocks they are mining are valid or not, which is kind of the\npoint. In practice I estimate that between 70% and 100% of today's\nhashpower is already mining the mainchain \"blind\" -- through some\ncombination of pools, spv and spy mining.)\n\nI don't agree with the conclusion (that the optimal policy is \"always\ndownvoting\", see above), but even if this analysis turns out to be\ncorrect, it isn't a total disaster. The result (which is in the original\nNov 2015 specification) is that miners are the ones who perform the\natomic swaps. Then they walk the coins side-to-main (which, at this\npoint, are *their* coins). As long as there are a few large mining\ngroups, competition will drive the atomic swap fees down to negligible\nlevels. This slightly encourages mining to consolidate into two large\npools...but of course that is also true of the status quo!\n\nPaul\n \n\u003e\n\u003e On Mon, Dec 4, 2017 at 1:36 PM, Chris Pacia via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e\n\u003e\n\u003e I think you are missing a few things.\n\u003e\n\u003e First of all, I think the security model for sidechains is the\n\u003e same as\n\u003e that of every blockchain\n\u003e\n\u003e People will say things, like \"but with sidechains 51% hashrate\n\u003e can steal\n\u003e your coins!\", but as I have repeated many times, this is also\n\u003e true of\n\u003e mainchain btc-tx. is something else?\n\u003e\n\u003e\n\u003e There are substantial opportunity costs as well as a collective\n\u003e action problem when it comes to re-writing the mainchain. \n\u003e\n\u003e Is there anything similar for drivechains? As far as I can tell\n\u003e there is no opportunity cost to casting a malicious vote, no\n\u003e repercussions, and no collective action barrier that needs to be\n\u003e overcome. \n\u003e\n\u003e Unless I'm missing something I wouldn't liken the security of a\n\u003e drivechain to that of the mainchain.\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\u003e\n\u003e\n\u003e\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171205/1ade3365/attachment.html\u003e",
"sig": "9bdca3925c4e95852d1210864dedc7a17d3b46a5a19fc9268e0c470f47e513ede69c99f4bff0b4534755d9a3735f85e25dfd2a51c5e0b7d397e7336e809e3dc0"
}