I think in any future arrangement of full/light nodes, Bitcoin is still Bitcoin as long as any attacker (including a miner with majority hashing power) has to pay the same proof of work cost in order to double spend as they currently have to spend today in order to get their double spend accepted by a full node.

SPV client security will be acceptable once there exist fraud proofs which an attacker can't bypass without paying the full cost of a history rewrite.

Full nodes can detect invalid blocks produced by miners because they have a full history of transactions, so if a miner tries to mine a transaction that spends coins that don't exist the full node will detect this.

A miner can't spend coins that don't exist if it's being checked by full nodes - it actually has to pay enough proof of work cost to rewrite the history of the blockchain retroactively make the coins exist.

This is very expensive, even for a miner with a majority hash power.

An SPV client can only verify proof of work - it doesn't have the transaction history to verify that inputs are valid. A miner with majority hash power can spend coins that don't exist, and SPV clients will accept their chain as valid, and there currently exists no proof which an honest full node can supply to the SPV clients to convince them that the chain containing the highest proof of work is actually invalid.

You can try to fix this with committed UTXO sets, but it doesn't really change anything - SPV clients can't validate the UTXO sets any more than they can verify blocks, so a miner with majority hash power can just commit an invalid UTXO set without needing to pay the proof of work cost to retroactively rewrite the blockchain.

Maybe instead of a UTXO set, the protocol should be changed to require miners to commit a tree of existence proofs for all the inputs referenced in the block.

This way honest full nodes can produce fraud proofs which SPV clients can verify, so now the cost of producing fake blocks which SPV clients will accept is the same as the cost of producing fake blocks which full nodes will accept.

Factom was having trouble making payroll due to not enough people buying their appcoin, so they've created a passthrough company to buy up the unsold tokens:

http://blog.factom.org/post/122941176349/factom-inc-factom-foundation-partnership

I honestly think the term "decentralized" has been ruined and I'd rather avoid it as much as possible.

I'd rather express Bitcoin security in terms of:

• What are the adverse behaviors a user might experience?
• How does an attacker benefit from bringing about those adverse behaviors, and how much does it cost them to perform the attack?
• What actions can users take to reduce their risk?

...then express hypothetical changes to Bitcoin in terms of how they affect the answers to the following three questions.

I'm actually fairly annoyed that I have to be the one to create and publish a realistic and accurate Bitcoin threat model, because trying to create a privacy threat model is enough work on its own, and there are plenty of #bitcoin-wizards who could do as well or a better of a job.

Plenty of people have the ability put out accurate and objective information that could clear away the FUD and let us have a rational debate, but nobody else is apparently willing to do so.

From the perspective of a Bitcoin user, every possible thing that can go wrong with Bitcoin can be categorized into one of two failure modes:

• A payment you belive to be valid, isn't (double spend)
• You are unable to perform a payment that you want to perform (denial of service)

All a user cares about how certain they can be that their balance is valid, and that they are able to spend their coins.

Before we can talk intelligently about how an attacker might reduce the number of miners and/or the number of nodes, we first need to establish why the attacker would do this, i.e. the ways in which an attacker can benefit from performing double spending or denial of service attacks.

Take selfish mining as an example. This is not an attack that directly affects Bitcoin users.

It may be possible for an attacker to solve more blocks than their share of the hashing power would initially suggest, but that in and of itself doesn't make your balance invalid or prevent you from spending your coins. It only affects Bitcoin users indirectly, to the extent that double spending or DoS attacks are easier if the attacker successfully reduces its competition.

You just described a version of the "denial of service" attack already mentioned.

Here are some attacks which are affected by the number of nodes and/or miners and/or hashrate:

Attacker: Miners
Attack: Double spending. A miner can spend bitcoins on a product or service, then produce a block which invalidates the spend
Probability of success: 100% when the hash rate of the attacker exceeds the hash rate of the rest of the network
Severity: Number of bitcoins controlled by the attacker * number of attacks performed

Attacker: Miners
Attack: Denial of service. A miner can engage in selective censorship of transactions
Probability of success: 100% when the hash rate of the attacker exceeds the hash rate of the rest of the network
Severity: % success rate of censor identifying transactions they wish to block * value of the blocked transactions

Attacker: Nodes
Attack: Double spending. An attacker can defraud a target who is using an SPV wallet by providing them with invalid block headers which allow the attacker to pay the target with a transaction which references non-existant inputs
Probability of success: 0% unless the attacker can prevent the target from communicating with any honest nodes
Severity:  Number of bitcoins controlled by the attacker * number of attacks performed

One of the things that's missing from the block size debate is a usable threat model that would allow us to make objective and rational risk assessments of the various threats loosely defined as "centralization".

Before we know how worried we should be about larger blocks (potentially) reducing the number of nodes, we need to know exactly how an attacker benefits from this situation and what kinds of mitigating factors and/or countermeasures are applicable to each attack.

I haven't heard any kind of analysis along those lines yet.

Can an observer prove that a given public key is the n^th hardened child of a given xpub without access to any of the associated private keys if they know n?

Alternately, can the owner of the private keys create such a proof?

Serious question: are certain developers trying to get pushed out of their position? Is this all an elaborate warrant canary?

Employing those kinds of tactics means they become the damage around which the rest of Bitcoin will route.

Yes.

Why would you think that?

Do people use central bank money because of free choice, or because the central banks benefit from State-granted monopoly privileges?

The fundamental divide is between those whose goal is to create a wall of separation between money and State, and those do oppose that goal.

That is the risk - the scheme relies on the security of ECDSA to protect the currency supply.

We're already relying on ECDSA to protect our balances from overt theft, so I'm not sure how much it actually changes the security model to also rely on it to protect our balances from covert theft via counterfeiting.

The reason I'm interested in amount blinding is that my current project is working out a multi-step plan to kill graph analysis. With the right plan and without blinded amounts we can kill graph analysis, but with blinded amounts we can drive a stake through its heart to make sure it stays dead.

I think it would be a tragedy for them to miss that lesson, and then lose the ability to make beneficial contributions to Bitcoin in the future.

I'd love to see the blinded output amounts from Confidential Transactions make it into Bitcoin, but I don't think their current approach to this debate is a viable way of ensuring they'll be in a position to advocate for that in the future.

Quoted for truth:

https://www.reddit.com/r/Bitcoin/comments/3bajai/by_expecting_a_few_developers_to_make/cskk0vq

A fixed size increase as a way to buy time before the measures needed to make the limit unnecessary can be put into place is a very reasonable and practical solution.

The long term solution is to have no magic constants for transaction rate limits, but getting there will take time.