3 ms·

There's a non-sequitour in your depiction of an attack. Gaining 50% of hashing power is not that interesting unless you really want to prevent someone from usin

by eoo 5y ago

There's a non-sequitour in your depiction of an attack. Gaining 50% of hashing power is not that interesting unless you really want to prevent someone from using their Bitcoin. And you can only prevent them from using it while your attack is sustained. When someone has gained ~50% of the hashing power, they only can do a small number of attacks [1], that are only profitable under external conditions, and even then, extremely risky unless you have a lot more than 50%. There really are no arguments for a race-to-the-bottom boundless energy spenditure. The equilibrium point is the market's appreciation of the service of securing a network of inflationless, politically neutral money, which is a pretty cool thing to have in our world of tyrannic governments. [1]: https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_computing_power https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_...

geofft 5y ago
I didn't say 50%. Simply, there is some level at which an attacker has enough computational power to pull off an attack, and such an attack is fought off by the legitimate participants in the network having enough computational power to make the attack unfeasible. Whether that's 50%, or even lower as the section you linked to suggests ("someone with only 40% of the network computing power can overcome a 6-deep confirmed transaction with a 50% success rate"), or higher as you claim, that point exists. The service of securing the network, as you put it, consists solely in having enough non-malicious computational power to make attacks unfeasible. Right? Or is it something else? If it does, then my argument stands. In order to be secure, Bitcoin needs the legitimate participants of the network to out-compute the illegitimate ones. Whether that's a one-to-one race, or a ten-to-one, or anything else, doesn't matter. The euphemism "securing the network" means nothing other than amassing computational power. If it is really true that attacks from attackers having lots of computational power are infeasible, and that it's not necessary for the network to have lots of computational power in order to "secure the network," then, quite simply, proof-of-work Nakamoto-style mining isn't necessary at all. You can do something like Stellar or (as I understand it, which I admit is not well) Lightning where transactions are confirmed and protected against double-spend by defining the problem in a different way that doesn't require mining. If that approach indeed works, then the objection in TFA stands - the spec should not encourage proof-of-work systems. Frankly, given that we're talking about decentralized identity and not about currency, and there's no double-spend equivalent in proving one's identity (I think?), it seems like Nakamoto consensus should be totally irrelevant here. Maybe inflationless, politically-neutral money is a great thing to have as a form of money, but what makes it a great form of decentralized identity?
- eoo 5y ago
  1. My point is that you lost me here: > This immediately produces an incentive for both the network to make use of as much computational capacity as possible to keep itself safe, and for any attacker to amass enough computational capacity to mount an attack This seems false to me. Could you elaborate on what incentives you see at play here? On another note, I feel one of the finest design details of Bitcoin is that its "decentralization-failure-mode", a.k.a. under a 50ish-percent-attack, is technically indistinguishable from normal operation. 2. The DID spec doesn't require the use of Bitcoin. So we agree with your last statement-disguised-as-question. Thus, it shouldn't have been listed as a reason for the rejection of the proposal (which spawned this thread)
  - geofft 5y ago
    1. Are we agreed that "securing the network" means "having enough computational power that an attacker cannot out-compute us," and conversely that the security threats that Bitcoin protects against are via attackers out-computing the legitimate network? And that these measurements of computational power are opposed to each other (i.e., if the legitimate participants have more and more computational power, attacks are harder, and if an attacker has more and more power, the network is less secured)? If yes, doesn't it follow that there's an incentive for the people who want a secure network to secure the network - by gaining more computational power - and for the people who want an attacked network to prepare to conduct attacks - by gaining more computational power? (If no, again, why Nakamoto consensus instead of something else?) 2. Correct, but there seem to be multiple "blockchain" methods listed at https://w3c.github.io/did-spec-registries/#did-methods https://w3c.github.io/did-spec-registries/#did-methods , and the spec itself suggests that you can verify a signature from a revoked key if the signature was timestamped via a ticking blockchain (like Bitcoin's). If it's true that the spec doesn't require the use of Bitcoin or other Nakamoto-style blockchains, which I agree seems to be the case, then I agree with you that it shouldn't be a reason to reject the spec - but also it seems like the reviewer's comment could be easily addressed. Just say that the W3C won't standardize any Nakamoto-consensus-based specs because the technology is wasteful and not specifically helpful for this particular purpose. (The reviewer is also asking the W3C not to standardize any centralized specs, like the ccp/Baidu one or the GitHub one, which also seems like a reasonable request and an easy thing to fix.) Then the reviewer could withdraw those objections. (Note that for timestamping, Certificate-Transparency-style logs can address that without mining: https://transparency.dev/ https://transparency.dev/ Right now the spec says "for example, it was anchored on a blockchain," without defining the word "blockchain," which most people interpret as a Nakamoto-style one. IMO it would be good if the spec instead mentioned CT-style logs. It's a small change, it wouldn't change the semantic content of that sentence, and it would address the objection that the spec encourages technologies that require mining - it's the only mention of blockchains in the core spec.)
Jerrrry 5y ago
Which is why, almost tautologically, it doesn't matter the power expense of blocks or even individual transactions. If a micro-coin becomes possibly promising, someone will dump 12gW into it a year until the consumption matches it's appreciation. May as well have the work be useful or artificially difficult for good or better reasons.

by eoo 5y ago

geofft 5y ago

I didn't say 50%. Simply, there is some level at which an attacker has enough computational power to pull off an attack, and such an attack is fought off by the legitimate participants in the network having enough computational power to make the attack unfeasible. Whether that's 50%, or even lower as the section you linked to suggests ("someone with only 40% of the network computing power can overcome a 6-deep confirmed transaction with a 50% success rate"), or higher as you claim, that point exists. The service of securing the network, as you put it, consists solely in having enough non-malicious computational power to make attacks unfeasible. Right? Or is it something else? If it does, then my argument stands. In order to be secure, Bitcoin needs the legitimate participants of the network to out-compute the illegitimate ones. Whether that's a one-to-one race, or a ten-to-one, or anything else, doesn't matter. The euphemism "securing the network" means nothing other than amassing computational power. If it is really true that attacks from attackers having lots of computational power are infeasible, and that it's not necessary for the network to have lots of computational power in order to "secure the network," then, quite simply, proof-of-work Nakamoto-style mining isn't necessary at all. You can do something like Stellar or (as I understand it, which I admit is not well) Lightning where transactions are confirmed and protected against double-spend by defining the problem in a different way that doesn't require mining. If that approach indeed works, then the objection in TFA stands - the spec should not encourage proof-of-work systems. Frankly, given that we're talking about decentralized identity and not about currency, and there's no double-spend equivalent in proving one's identity (I think?), it seems like Nakamoto consensus should be totally irrelevant here. Maybe inflationless, politically-neutral money is a great thing to have as a form of money, but what makes it a great form of decentralized identity?

eoo 5y ago
1. My point is that you lost me here: > This immediately produces an incentive for both the network to make use of as much computational capacity as possible to keep itself safe, and for any attacker to amass enough computational capacity to mount an attack This seems false to me. Could you elaborate on what incentives you see at play here? On another note, I feel one of the finest design details of Bitcoin is that its "decentralization-failure-mode", a.k.a. under a 50ish-percent-attack, is technically indistinguishable from normal operation. 2. The DID spec doesn't require the use of Bitcoin. So we agree with your last statement-disguised-as-question. Thus, it shouldn't have been listed as a reason for the rejection of the proposal (which spawned this thread)
- geofft 5y ago
  1. Are we agreed that "securing the network" means "having enough computational power that an attacker cannot out-compute us," and conversely that the security threats that Bitcoin protects against are via attackers out-computing the legitimate network? And that these measurements of computational power are opposed to each other (i.e., if the legitimate participants have more and more computational power, attacks are harder, and if an attacker has more and more power, the network is less secured)? If yes, doesn't it follow that there's an incentive for the people who want a secure network to secure the network - by gaining more computational power - and for the people who want an attacked network to prepare to conduct attacks - by gaining more computational power? (If no, again, why Nakamoto consensus instead of something else?) 2. Correct, but there seem to be multiple "blockchain" methods listed at https://w3c.github.io/did-spec-registries/#did-methods https://w3c.github.io/did-spec-registries/#did-methods , and the spec itself suggests that you can verify a signature from a revoked key if the signature was timestamped via a ticking blockchain (like Bitcoin's). If it's true that the spec doesn't require the use of Bitcoin or other Nakamoto-style blockchains, which I agree seems to be the case, then I agree with you that it shouldn't be a reason to reject the spec - but also it seems like the reviewer's comment could be easily addressed. Just say that the W3C won't standardize any Nakamoto-consensus-based specs because the technology is wasteful and not specifically helpful for this particular purpose. (The reviewer is also asking the W3C not to standardize any centralized specs, like the ccp/Baidu one or the GitHub one, which also seems like a reasonable request and an easy thing to fix.) Then the reviewer could withdraw those objections. (Note that for timestamping, Certificate-Transparency-style logs can address that without mining: https://transparency.dev/ https://transparency.dev/ Right now the spec says "for example, it was anchored on a blockchain," without defining the word "blockchain," which most people interpret as a Nakamoto-style one. IMO it would be good if the spec instead mentioned CT-style logs. It's a small change, it wouldn't change the semantic content of that sentence, and it would address the objection that the spec encourages technologies that require mining - it's the only mention of blockchains in the core spec.)

Jerrrry 5y ago

Which is why, almost tautologically, it doesn't matter the power expense of blocks or even individual transactions. If a micro-coin becomes possibly promising, someone will dump 12gW into it a year until the consumption matches it's appreciation. May as well have the work be useful or artificially difficult for good or better reasons.