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

then it seems that there is no need to hash the UTXO set into the current block.  we aren't doing that now and it works.

No. The state of the Bitcoin ledger as of each Bitcoin block corresponds to exactly one correct UTXO set.

The UTXO set merkle hash is created out of confirmed transactions.

how is this practical?  don't UTXO sets differ slightly just like the mempools unconfirmed tx's?

Security researchers are reporting a trend for cybercriminals to go directly after financial institutions instead of their customers. In February, researchers from Kaspersky Lab reported that a gang called Carbanak stole up to $1 billion from banks and other financial institutions in 25 countries after infecting their systems with malware and carefully learning their internal procedures. The primary attack vector used was spear phishing, targeted emails containing malicious attachments.

http://www.pcworld.com/article/2915112/police-breaks-up-cybergang-that-stole-over-15-million-from-banks.html

huh.  we got the $DXY and the TLT turning down on top of the Dow Theory non-confirmation we still have in place.  this, plus the break of the RUT below it's support of it's ascending wedge all equals "heads up".  or, i could just be needlessly concerned:

Yes, it only applies to thin clients.  A full client calculates the UTXO set and Merkle hash from the complete history, compares it to a new block's UTXO hash and rejects the block if they don't match.

A 51% attack could create a longer chain of malicious UTXO sets than the longest valid chain.  But the full nodes reject the chain because it is not correct (incorrect UTXO hash).  However "light" clients (I'm not calling them SPV because SPV refers to a specific algorithm), can't validate the UTXO hash so they assume that it is correct and therefore use the longest (and incorrect) chain. 

Honestly in practice you would simply code up "light" client that refuses to do any TXNs if there are 2 competing chains that forked > 64 (for example) blocks ago.  Bitcoin's natural forks resolve quickly...

Note that it doesn't have to be all or none either... a client could keep X years of back revision history and just assume if the coin is older than that then it is valid.  This might be very important when Bitcoin is 20+ years old.


Once upon a time revision control systems stored each revision as the difference between the prior rev and the next one.  This is bitcoin today.  As files changed hundreds of times it took a long time to "check out" the file because all the revs had to be read and applied.  Then people realized that there is a better way: store the current file and the reverse difference -- that is the changes needed to get BACK to the prior rev.  This made a lot more sense because the current file is what is used 99% of the time.

This idea to store the UTXO Merkle tree hash is the evolution of the network to the back-revision method -- we only need the "current state" because blocks are symmetric.  So technically you are correct; this is redundant data.  But what it actually is a smooth transformation from one structure/protocol to another.

I think the security of committed UTXO sets might depend on how they are actually implemented.

Maybe it's better to think of a set of transactions which create unspent outputs.

Each transaction in that set can be accompanied by the hashes needed to prove that it was included in the merkle tree of a particular block.

Each bitcoin block that contains a committed set becomes independently verifiable - almost.

If one accepts that they know the hash of the previous block represents a valid block, then any observer can verify that the next block is a valid transformation of the set of transactions which create unspent outputs without knowing any more history than what is contained in the block itself (and its committed set).

In this model, an attacker can not add false transaction to the set without being detected by any client (light or otherwise) which has managed to obtain a correct set of block headers, otherwise the hashes won't match (unless the attacker can also trivially break SHA256).

Now now we're right back to "if an SPV client can manage to connect to a single peer that will tell it the truth, it can't be fooled".

Because each block + committed set is a self-contained proof, even if an attacker with a majority hashpower produces a chain with longer proof of work any honest node can broadcast the proof that one of the links in the attacker's chain is invalid and therefore the entire branch is invalid.

yes. I hope I'm using the term correctly.


thezerg explained an approach and I think the implications are valid here (bolding mine):


I'm really no sure about this point after re-reading what thezerg said. If it only applies to SPV clients, then it doesn't make much difference because these have to trust the miners anyways. I might be slightly confused.


yes, that. That's not a very strong reason, though.

looks to me like the $DJI is starting to get dragged down by the $DJT:



also, RUT has broken down below the support line of the ascending wedge, depending on how you draw it:

Wouldn't the UTXO hash have to be in the header since otherwise it could get pruned?

Until yesterday I thought UTXO commitments were a good idea. After the discussion here I oppose it for 2 reasons:

• It gives additional capabilities to a 51% attacker
• Since the UTXO set is actually an implementation detail, making it part of the bitcoin protocol seems inelegant and uneccessarily cluttering

The way I've envisioned it is the UTXO hash becomes a part every block's structure (just as the coinbase transaction) and it serves as a marker for the UTXO set as of the current block. This enables nodes to optionally ask for: a) all prior blocks, or b) the UTXO set only.

If there is a re-org, then the new chain's blocks simply have their own UTXO hash in each block and provide a valid reference for the UTXO set on that branch. Each separate chain would have their own UTXO hash that is valid at every block. The cost is adding 256 bits to each block, but this doesn't even have to be a part of the header structure and instead is part of the block itself.

During a re-org a node could ask for either: a) all new blocks since the branch or b) the UTXO set of the latest block on the new chain. Both would be valid options to function on the new branch.

What I like about this is it allows each node to make optimal decisions that alleviate bandwidth pressure on the network. Every time a node restarts after x number of days, it could quickly determine which is the fastest method to catch-up, a) download the newest block or b) download the UTXO set, whichever is smaller. This would allow nodes to minimize their download requests.

As stated in my original post, you'd have to trust the P2P network to reject blocks with invalid UTXO hashes. So yes you are relying on that processes work correctly, which requires more trust than we have today (i.e. from fully trustless to trusting the P2P network) and does introduce a potential attack vector.

However given how visible the blockchain is, I find it difficult to imagine a scenario where someone effectively pulls off the attack. It would be flagged immediately and all honest miners would reject it and go to a valid chain.

I think attacking a UTXO hash will prove to be as plausible as a 51% attack, which is not likely.

So we have people who want a service and they aren't sure how they are going to get it. What a tough problem.

If only there was this technology that could help people cooperate to get what they want more effectively than direct barter. Something that people could exchange but not consume directly, in order to help them keep track of whose turn it is to consume the products and services being produced. Wouldn't that be a great invention?

You know what would be even better? What if anyone who wanted to provide a service was free to do so, and the people who wanted to consume the service were free to choose any provider which which they could come to a mutual agreement, or no provider at all?

I wonder how good of a job such a mechanism might do at making sure that the number of suppliers was sufficient to meet the demand for the service? Could that improved barter trading thing maybe play role? Perhaps there's some kind of signal that might be passed through it that could be useful.

It feels like we're so close to having all the technology we need to solve problems of how people are going to be able to get what they want via mutual trade. Perhaps in some far off future utopia a more advanced civilization just might finally crack this Enigma.

You are taking the situation to its extremes.

The reality is that in a decent sized Bitcoin economy there will be thousands of businesses who will always run full nodes. Individuals who want to use pruning *should* have the option of storing a percentage of the full blockchain. Even if it is 5% or 1%, as mentioned earlier, the whole blockchain can be rebuilt from segments held by many nodes with this variation of pruning.

Also, storage is not really the problem, in 10 years time petabyte storage should be available to consumers, let alone to high-end users. 3D (even 5D) glass storage has huge potential.
Bandwidth is the real limiting factor, and fortunately there are major efficiencies to be had there.

for one, you'll be able to get it from me.

and you don't seem to get that if we increase the # of nodes by orders of magnitude larger than what we have now, even if just pruned nodes, that Bitcoin's exchange value will likely increase along with it making it much easier financially for those of us to continue committing to providing full blockchain server nodes.  it also will help decentralize mining.

The dollar is a digital currency pretty much, so what he appears to be suggesting is the status quo and this technology is pointless.    A problem with education is its biased to government, partly from the funding and many other cross overs.    Bitcoin fail or suceeds, it was never pointless and it is very much something new and never seen in this world before.  Whether we need it Im not sure yet

You don't seem to quite get it.

From who do you suppose you will "download" the entire block chain initially.?

I don't care if you stick "validating" nodes on every USB key you can get your hands on. This does not improve the number of COMPLETE copies of the transaction log from which nodes can sync on the network.

Did you bother reading the last link I posted? To quote


So much for inclusion and "nodes" propagation when only people who can afford petabytes of storage can run the only nodes that matters and that are foundation to the Bitcoin network