[eoo]

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]

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 , 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/ 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.)

[eoo]

1. I'm not sure we agree on that... Bitcoin doesn't protect against attacks, it provides you with a relatively simple model to measure the cost of attacks.

At equilibrium, any Bitcoin network participant will look for two fundamental things: (a) being able to move their own assets and (b) relative market price stability of their bitcoin. In case of a sustained 50% attack, both properties start to crack, but not completely. But after the attack, they are regained -- (a) immediately, and (b) eventually.

Consider the attacker to be a government, for example, an actor with a relatively high amount of resources, and the Bitcoin participant a dissident citizen of such government. The dissident wouldn't like to have its assets frozen by the government (through strict censorship of the dissident's transactions), so the market value for Bitcoin drops comparatively to how wealthy was the dissident selling its bitcoin savings. But, also, the dissident might avoid selling if they have enough financial capacity to withstand the attack.

In order to carry out such attack, the government needs to increase its energy spending on Bitcoin, up to the point where the attack is successful for a prolonged period of time. Bitcoin production is intrinsically bound to energy generation, thus to its economic realities (variability of demand, climate conditions, political affairs, just to name a few).

It would cost a government X dollars a day, or Y watts a day, every day, minus the price of the coins generated to attack the network. I estimate X to be the total miner rewards: at the time of writing, 38M USD [1]. Y seems to be at around 456 GWh [2]. Is it worth it for your adversary? That number is the dissident's security parameter. As long as their savings are less valuable than the cost of the attack and they can sustain the attack financially, the dissident should be fine (or really scared about an enemy irrationally spending a lot of energy/money with the purpose of just preventing them to access their money temporarily).

In the end both miners and users just want the chain to move forward. If one particular actor or coalition potentially prevents it, users/miners outside the coalition (if they detect it) would raise their investment to continue chugging blocks.

I think there are no "legitimate" vs "attacker" uses of hashing power. It's more about coalitions between miners and how costly/profitable would it be for them to centralize the network, and how hard is it on the other participants to coordinate a decentralized counter-attack (which ends up profiting them). But eventually, the equilibrium between all participants is to spend as little money/energy as possible. And if it's not decentralized it becomes censorable: next, it loses its value: now who's gonna want to mine something worthless?

2. We see it the same way. I'd add that if Bitcoin is staying around (I don't think it can be shut down), one solution is to use Open Timestamps or other hacks that don't require "block real estate", thus in no way compete with transactions, essentially piggybacking the PoW and getting the timestamp for free.

[1] first result I got for "block rewards Bitcoin last 24 hours": https://bitinfocharts.com/bitcoin/

[2] first result for "24 hour bitcoin consumption watts": https://digiconomist.net/bitcoin-energy-consumption