Topic: Gold collapsing. Bitcoin UP. - page 398. (Read 2032286 times)

The thing to remember is you don't need to hold the full chain to participate as a full node. That is why pruning works.

Once you have a valid node state as of xxx block, you only need the header chain and the UTXO set to FULLY validate the next block. Assuming your node's state is correct, you do not need the full history to validate the next block. Again this is why pruning works.

A UTXO set offers a faster method to reach a valid state as of xxx block.

Today the only method to reach a valid state is to download & validate the complete history. But once your node has done so, your node can delete that history and just save the UTXO set, and still validate all future transactions and blocks. This is exactly what nodes that prune do. But this method is very inefficient, it is not a problem today, but it will be if bitcoin succeeds.

As another example, with pruning it is possible that all nodes on the P2P network prune their history, and NO nodes on the network have a complete history individually. But each one would still be able to independently validate transactions and blocks. This is because they still have the valid UTXO set, the pruned history is not necessary.

The p2p network can't verify them if it doesn't have the full chain, which is exactly what we were talking about: lightweight nodes that run an ARM thumb or something. You have a bootstrapping problem.

Yes archival nodes would (or at least could) verify the whole thing, but there is nothing forcing them to, or at present not even any incentive to run an archival node at all. What happens if no one realizes that the last archival node shut down, or is malicious?

To be clear, I'm not arguing "against" UXTO commitments, just pointing out that there is a reduction in trustlessness if everyone isn't verifying everything, and added risks when the incentives to verify are aligned with letting "someone else" do it. These can probably be fixed, or at least controlled, I agree with what you said about the third party trust creeping in regardless.

Last arguments for UTXO hashes, then I'll stop on it.

The reason I think bitcoin is going to have to add UTXO hashes at some point at simple, without them new nodes at some point will be forced to use centralized services that require trust to get going. In that scenario UTXO hashes strengthen bitcoin by providing a trustless mechanism for new nodes to get started.

In 30 years when Bitcoin has fully taken over, eliminated all fiat and gold, and ALL of mankind's transactions are on the blockchain (including machine-to-machine micropayments), the blockchain will be 100 Exabytes in size and grow by 10 Exabytes per year. Even if a new node is able to download this volume of data, processing the full history takes several CPU years. (I'm making up the numbers to make a point)

In such an environment starting a new node is both too costly and takes too long.

To fix this, centralized services appear that offer services to help new nodes start. These services will provide a node state for download that is valid as of xxxx block. This node state will have the full header history, the current UTXO set, and some number of random blocks to serve to others. With this download anyone can start a new node in minutes, instead of years.

Some of these centralized services are run by entities we like (such as blockchain.info) but others are run by entities we don't or shouldn't (such as the Bitcoin Foundation). But in either case, the practicality of starting a new node forces most people to trust some 3rd party entity .

UTXO hashes would eliminate this trust and enable new nodes to quickly start in a manner where they only have to trust the integrity of the blockchain (which is all you should need to trust). As argued in the above posts, I haven't seen a valid attack on them, even with a 51% miner attack.

UTXO hashes would be verified by both the P2P network and full (archival) nodes that maintain full history. I'd consider them as strong as a regular chain.

Another way to look at it is, why can't a 51% miner reward themselves with larger than allowed coinbase transactions and increase the supply of coins beyond 21M? They do after all have the power to create the longest chain. The reason is such blocks are invalid and would be rejected as an invalid chain. Same with UTXO hashes, any attempt to insert an invalid UTXO hash is an invalid block and rejected by the P2P network. It is the exact same protection mechanism.

Not if people are trusting them. Only if people are constructing them or verifying them. So you have a tragedy of the commons where if you have this nice little hash you can use to cheaply verify transactions without processing all the data, while expecting "someone else" to do the heavy lifting, the network as a whole gets weaker.

I have to qualify that by saying I haven't looked that closely at the UXTO commitment proposals so my analysis may be slightly off, but I don't think so.

There is a reason  that we find the 'average' person to be stupid.  It is not an illusion.  It is merely perspective.  Most people are not suited to academic learning.  They are suited (in wool?) to following, and we can't have a trend until they do (follow), regardless of right/wrong/need/want.  The truth is, they HAVE been 'educated'. It is just that our little minority disagrees with the particular indoctrination with which they were so easily placated.

We do need to get larger transaction volume capability into Bitcoin before there's a legacy financial system meltdown.

Right now the infrastructure isn't capable of scaling to pick up the slack, and nobody's interested in fixing the resource allocation problem in a comprehensive way such that we could be ready for sudden, massive growth.

Apparently building appcoins based on MMT is more fun, or pays better, or something.

The network will keep operating and you will still have control of your private keys.

What is depressing is it has taken the prospect of negative nominal rates to start this. Negative real rates are what really matter, that is financial repression. We have had negative real rates for years, but most people seem OK with that. It is only when the nominal rate goes negative and people see that their balances will go down, that all of a sudden it's an issue.

An educated populace would have balked at negative real rates. That fact that we collectively didn't says a lot.

IMHO a debt-driven deflationary meltdown would keep the BTC price depressed (as with gold) because billions of electronic dollars/euros etc are vanishing from the economy when debts are defaulted on.
BTC would spike (like gold) afterwards when central banks react with unprecedented money printing, far beyond any QE so far, but eventually they are caught out when the velocity of money ramps up causing an overcompensation for the debt-deflationary effects, and 1970s-style high-inflation is revisited, but worse. Then BTC and gold rockets.

BTC is a censorship-free refuge which will help it, plus 2/3rds are already mined, so it may front-run the above mess.

I know a lot of people think it would mean down. I, otoh, think it would mean a massive UP for Bitcoin. Just the way the charts are aligned right now tells me this. We've had an inexplicable 1.5 year decline in the price despite all sorts of good news. Yet we're down 90% or so while the stock market is way up at all time highs from money pumping and what looks like a top to me.

There's no doubt in my mind that Bitcoin is an alternative to everything fiat.

What would a meltdown mean for Bitcoin?

I disagree, what is novel here is a mainstream financial editor/writer willing to threaten the centralbank mind-control mantra and say specifically, "This is really, really, f$#%ed up". Fiat money is based purely on perception and Keynesians write papers on "behavioral economics" that fuel the manipulations, jaw-boning, market operations, etc that target price controls. If the illusion begins to dissolve it is over, that is how fragile the current situation is.

nothing new, it seems at this point the reality could simply go beyond the fiction. at least for quite a while. just look at varoufakis exiting negociations by the small door.

I don't see why it would have to be. The header is really only for things a node has to have for each block, which is the linkage to the previous block and linkage to it's data package.

You could put it in the block's tree structure. Then if a node needs it, the node could request and verify it. But if the node does not need it (i.e. an SPV client) the node could skip it (along with that block's other info such as the coinbase and transactions).

I don't think this is true. UTXO hashes would be verified the same as transactions.

For example, today if a 51% attacker tried to insert invalid transactions into a block to create coins, or double spend past transactions, the P2P network would reject such blocks. This is why a 51% attacker can really only attack by selecting specific transactions or refusing to confirm specific transactions.

UTXO hashes would be the same. If a 51% attacker tried to create an invalid UTXO hash, that block would be rejected by the network. It is no different than a 51% attacker inserting an invalid transaction into a block. Both are rejected and a 51% attacker can't do this.


I also don't think this is true. As of each block, the bitcoin protocol has a specific and known UTXO set. This isn't an implementation detail but an inherent property of the bitcoin protocol. Future transactions are limited to those in the UTXO set, it is part of the protocol.

The negative interest rate hall of mirrors is screwing with people's minds enough to wake them up from the Central Bank manipulated price-perception fantasy dream. The monetary CONfidence game may be coming to an end ... feels to me like the Rubicon has been crossed.
http://www.telegraph.co.uk/finance/comment/jeremy-warner/11569329/Jeremy-Warner-Negative-interest-rates-put-world-on-course-for-biggest-mass-default-in-history.html

To expand on this, adding a UTXO hash set simply provides nodes a new additional method to engage with the P2P network. The full history still exists and is independently verifiable to anyone who wishes to do so.

With UTXO hashes, a node can optionally decide what level of trust it requires, and can optionally trust that the P2P network has correctly verified the UTXO set up to a given point to save bandwidth, or not if it wants the full history.

We'd end up with 3 types of nodes (vs. 2 types of nodes today):

1) SPV clients - Thin & lightweight nodes that do not contribute to the network. These need to trust their P2P peers to some degree.

2) Full nodes without full history (i.e. UTXO nodes) - Fully functional nodes that are able to fully participate in the P2P network and validate transactions and new blocks. These need to trust that miners and the P2P network correctly verified their starting UTXO point.

3) Archival nodes with full history (i.e. today's nodes) - Fully functional nodes that are able to fully participate in the P2P network and validate transactions and new blocks. They also valid the fully history of a given chain.

Type 3 nodes (I'm calling archival nodes here) would still exist and verify for everyone that a given chain is valid. Given how public this is, I can't imagine and attack were either the P2P network or the full archival nodes wouldn't be able to flag the attack and kick off the invalid chain. What UTXO hashes provide is the option for nodes to save bandwidth by trusting the longest chain, I'd imagine this trade off is OK for some subset of nodes.

Yes, like I was saying above, it is an optimization.  It transforms the block chain from one that must be processed in one direction (beginning to end) into one that can be read in either direction.  So full clients can still read from beginning to end, but "light" clients can read from end to beginning and essentially make its own tradeoff between confidence level and data storage overhead.   A light client could even read the entire blockchain end to beginning and by doing so gradually become a full client...

What I like most about it is that we could do it today in independent transactions as a proof of concept (but you'd have to trust "us" to not lie about the hash).  However "us" could be multiple independent validators... it could later be turned into a required element in every block to make the trust model similar to what we have with miners today (i.e. not very much trust)...

If you put the hash of the UTXO set in the block header, then light clients can obtain a copy of the set from an untrusted source and use the block header to verify that it is correct.