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

LOL I should read the whole thread rather then skimming it.  You guys were already talking about the UTXO hash!   But its easy to miss stuff when multiple conversations are interleaved and you are only interested in one of them :-).  

Note if you make it a UTXO merkle tree whose root is stored in the block (not a flat hash) then a light client could verify that certain UTXOs exist without downloading the entire UTXO set.

EDIT:  And what do you think of the idea of just doing it (as data in a txn), and then if people use it we can incorporate it into every block so that it is trustless?

Open questions;
i) UTXO hash in blockchain is vulnerable to re-orgs, so it needs to be >120 or 288 blocks deep or w/e your 'trust' level is ...

ii) Also some UTXO could discard/prune long unspent dust/spam or other 'bad' TX so not all UTXO sets will be created equal ...

I didn't say it's not practical to relax any of these trustlessness assumptions, just different. Peter R explained more or less the same thing a bit more clearly, I think.

You don't need to trust a central party to have light wallets though, just the collective good behavior of the miners and at least one of the nodes you connect to has to be honest (but you don't have to know ahead of time which one).

Yup and maybe as Smooth says its not practical to create lite wallets which are entrusted by the foundation or some other globally known trustful entity because it may cause havoc if that node(s) was hacked. However in order to do some kind of SPV to save bandwidth when syncing (something we will need) we have to give up some sort of trust somewhere.. so problems still there.. and that is the major problem I have with the bloat, storage is a non issue imo.

People throw this word trustless around a lot. It doesn't mean what you think it means. If you are relying on a committed UTXO then you are trusting whoever created and verified that UTXO (meaning the miners for the most part) to have done so faithfully. That may be a reasonable or even entirely necessary trade off to avoid needing to process petabytes of data, but you can't wish away that it is indeed a trade off.

Justus is correct that there could conceivably be a zero knowledge proof that the UTXO is the result of only valid bitcoin transactions which could be trustless. (Maybe, but only if there isn't a trusted setup, not even a distributed one.) Just committing any old UTXO doesn't do that.

You still have to download the full chain and verify the full chain in order to be able to trust that your state is correct. When the blockchain reaches many petabytes that will be an issue.

Hashing, verifying and committing the UTXO set to blocks enables a node to only download headers and the current UTXO set, and still operate in a trustless manner. That is a massive savings in bandwidth, and one that will be needed.

The current update simply reduces the amount of storage and node requires to operate, it does not reduce the amount of bandwidth a node needs to join the P2P network. Even with the update, you still have to download the full blockchain.

Add solar cells and a mesh network.

Oh yeah, don't forget to build in a  miner. 

Imo, the volatility we're starting to get to the upside, OKcoin last week and BTC-e  today,   is a bullish sign. 

Here's an idea for some young entrepreneur that will greatly expand the number of  network nodes.

Instead of using a USB adapter to power these small compute sticks, use an AC adapter to power them. Load in the pruned 1.3GB block chain and connect them to a nearby open wifi in some obscure outlet. I know I have access to lots of open and closed wifi systems.

Actually, I wasn't agreeing with his whole concept of just depending on headers and a hash of the UTXO set for a full node. I still think it's important for every new full node to download the entire block chain initially to build a valid UTXO set before discarding  any blocks. But I do like the idea of adding a  hash of the UTXO set into each block to ensure it's integrity.

So it seems like there are two approaches:
  
The "strong" validation model allows anyone at any time (T) to validation the entire history.
The "weak" validation model allows anyone to validate T to T-N back in history.  We assume that at any time T1 that is currently unavailable there were people validating it.  

I like the strong model but in practice I think the weak one works fine and could be very useful for a micropayment sidechain.  To explain, consider this thought experiment:  Tomorrow somebody reveals that they've been mining all along and releases a competing blockchain starting from the genesis block that is longer than the current one and gives them all the coins.  Do you REALLY think all the people involved in Bitcoin would just be like "OK" we'll use your chain?  No way.  We'd issue a patch to the client that prefers "our" chain and probably create some hopefully temporary and unfortunately-centralized solution where Gavin or someone periodically stamps what he thinks is the valid chain.  The point is that the fact that the chain is globally accepted today, yesterday and last year actually makes it stronger than the math.


Here's an alternate idea:

create a hash of the UTXO sorted set (ok a Merkle tree of hashes would be better) and periodically issue it in a dummy txn.  Today, that can be done via the extra bytes.  Now anyone can use your published, hashed UTXO set (presumably its shared P2P), if they trust you.  

If the above is useful, next we create a soft-fork new op code that identifies this as a hash of the UTXO and miners don't accept block with an invalid UTXO.  Miners must put this UTXO hash in every (block number%31 ==0).  Clients don't use the most recent UTXO hash but the prior one.

So now we can have a very small client that is also trustless (well, a single miner would have to find 32 blocks in a row or 51% the network to fool a client).  Small clients could use even older UTXO sets if they are less trusting of the diversity of the miner network.  

The only problem with the above is that today 51%ing the network only lets you get all the newly minted coins and deny the ability of others to spend.  This is a pretty cool feature

But with the above a 51% miner could "mint" new coins (at least from the perspective of the small clients) and remove existing ones by creating a fake UTXO set.  You'd have to remove existing UTXOs or the # of coins would not match the coinbase issue rate.  But if a 51%er ever did this, the non-small clients would see it instantly and so there would presumably be a huge PSA.  So this idea is acceptable within the "weak" validation model...

Yes I'm just making a point about terminology more than anything else. Previously we just had full nodes and clients. Now we have another category of nodes to consider. I don't think its bad that people can run nodes on smaller hardware.

Yes there are some interesting divergences between what it is reasonable to do as an individual (especially when the rest of the network does not take shortcuts) and what you want the network to do as a whole. I smell a bit of a free rider problem here.

Agreed. But let me give you a practical consequence of what has happened.

I look at this situation and think instead of converting my current full nodes to pruned  nodes, I am thinking of how i will add at least a dozen or more new pruned nodes on those little compute sticks from Intel to every open, free wifi connection I can get my hands on.

Right, and now we're back to one of Smooth's points that a network full of nodes that don't personally verify every transaction in each block back to the genesis block (e.g., by relying on UTXO commitments instead) doesn't offer the same level of trustlessness than one that does.

Again we are going to disagree a bit about what a "full node" means. To be full full node, you have to be able to serve blocks to peers who need them. When people talk about running full nodes to support the network, that is one form of support they are providing. Relaying is another. A pruned node only does the latter, not the former.

Yes, thanks for bringing this up; I was gonna say. I think that makes great sense as well.

A couple things. Iirc, the UTXO set was not part of the original Satoshi design; which is why he proposed a slightly different means of trimming down the blockchain. It was added only later by the current core dev team.

Also, the block chain of a full node is never accessed except to serve blocks  to new nodes coming online or for reorgs; which is why the new proposal makes you save at least the last 288 blocks. So once you've verified your download, you can prune away yet still function completely as a full node would otherwise do.

Personally I like the concept of adding a hash of the current UTXO set to each block. This would enable a new node to only download headers and the UTXO set as of the last block, and that would be enough to start operating as a full node.

It does reduce the trustless aspect, but only slightly. With this you'd have to trust that the P2P network rejected any attempts to insert an invalid UTXO hash (which has the effect of being able to arbitrarily change unspent outputs). But to attack this, you essentially would have to take over the P2P network. Plus given how visible the blockchain is, I'd say any attempts to do this would be noticed and rejected in real time.

As the total blockchain gets very very large, I think we are going to need something like this. A UTXO hash would enable full nodes to operate without ever downloading past blocks, you'd only need headers (which is small) and the UTXO set. Otherwise we are forced to have new nodes download petabytes of data they'll never keep. Network BW is still a limited resource, so this aspect of bitcoin will become more and more of an issue.