Maaku, I take your silence to indicate either that you believe I am wrong but do not (for whatever reason) want to explain why you think so.

Or... well, actually that's my only hypothesis.

For my part, I do not see how you can be right, and I provided my reasons for why I think that. As far as I can tell, once the leaves have all been fetched, miners can safely mine on the blockchain without having to download the histories of all those coins.

Full stop. I have never advocated that. If you believe that, then you never understood the rolling root proposal.

I agree it's best to keep the threads separate. If you have questions about how rolling root works feel free to ask in the other thread.

Sticking to UTXO though, I don't believe you answered my question. UTXO is not SPV either, so it is still not clear to me why you say they don't know whether they're on a valid chain or not. They downloaded the headers from genesis (SPV), but in addition to that they downloaded the entire UTXO meta chain which they can then use to verify any txn and build the merkle/btree or w/e the latest data structure is.

It's time for a hard fork anyway:

http://hackingdistributed.com/2014/06/13/time-for-a-hard-bitcoin-fork/
http://hackingdistributed.com/2014/06/18/how-to-disincentivize-large-bitcoin-mining-pools/


There are opinions, and there is data. The latter impresses me more and is linked in the first post.

Looks like rolling-root is still needed for new nodes to be brought online reliably because UTXO, according to maaku, requires you "to download and process every single block since Genesis": https://bitcointalk.org/index.php?topic=88208.msg7391152#msg7391152

Can you explain why that is?

If what you're saying is true, then the rolling root is still needed for Bitcoin's future feasibility and safety: http://hackingdistributed.com/2014/06/18/how-to-disincentivize-large-bitcoin-mining-pools/#comment-1442133143

maaku made an interesting reply in that thread in response to my request for confirmation of understanding.

Here is that reply along with my follow-up question, you might want to follow along in the UTXO thread:

Interesting point. Hope you don't mind if I mention your reply in that other thread as well.

So, what is the takeaway from that then? That new lite-nodes can use UTXO to validate arbitrary queries, but they cannot participate in securing the network until they have all the transactions for the leaf nodes of the entire UTXO tree?

Actually, I'm not sure about that. What's the incentive for nodes to mine on that meta-chain? There doesn't seem to be one, and without a compelling incentive a denial-of-service attack might be possible against UTXO. Since mining on the meta-chain decreases the rewards a miner can expect (if there were to mine only on BTC), they wouldn't mine on it, and that might make it easier for someone to get 51% control over it... I'm not sure how that would play out.

I see that the UTXO thread has some discussion about this issue, but it's too late in the day for me to spend more time on this (work calls!): https://bitcointalk.org/index.php?topic=88208.msg971762#msg971762

Could somebody here knowledgeable about the details of UTXO please confirm whether my understanding of how it would work in practice is correct?

Copying a reply I posted there which I am copying here because if my now (possibly complete) understanding of UTXO is correct, then UTXO is a superior solution to my rolling-root idea:


I welcome replies here too as to whether or not I understood UTXO correctly.

At the request of "HoboJerk", I've revived this thread.

That is complete nonsense. I replied to every single unique point that I saw you (and others) make.

That you say I "ignored all criticism" can be verified to be a lie by anyone who reads the thread.


This mantra of yours too, received a reply from me in that thread.

That "if clients demand proof-of-honesty" is a very big IF that seems to go against the spirit of the original bitcoin paper (demanding an algorithmic answer, not a human one).

A related concern is that full nodes are disappearing as the cost of both running, and *especially* bringing online a new node, increases.

I made a proposal to address this issue that I called a rolling root, but even though nobody found a flaw in it, it was unpopular because it would require changing the protocol in some significant ways. I still think it should be done FTW.

(The following comments are not directed entirely at you, mot7, but at everyone who keeps bringing this issue up.)

It baffles me how this thread got so derailed over this philosophical point.

Bitcoins both exist and don't exist. The word "Bitcoin", "balance", etc. exist in a quantum superposition of linguistic masturbation. They are a mechanism through which the universe gratifies the sexual urges of nerdy nit-pickers. The way it works is that one party has Concept A in mind when they say "Bitcoin" (or some other word), while the nit-picker insists on using Concept B for the same term. Concept B does not exist, so it is somewhat unclear why the nit-picker chooses said non-existent interpretation, but perhaps it is because it gives the nit-picker a way to attack another party and derail a thread.

What did Satoshi have to say about the "existence" of "Bitcoins"?


That is what a Bitcoin is. Here you can see where the wave function collapsed to a value that actually does exist. If you have difficulty with the word, just substitute "input and output" or whatever other term you fancy. The English language is abundant with diverse words that all refer to the same concept.

It is a waste of everyone's time to derail this thread arguing about these semantics, especially when the other party (me) demonstrated that they know what an "input and output" is, what a "bitcoin" is, etc. The same is true for the word "balance".


Using confirmation count to determine the window size is interesting.

However, whatever the metric ends up being, it should probably be based on percentages, not absolute values (unless some absolute value can be demonstrated to be useful regardless of network size and transaction volume).

Thank you for bringing this thread back on topic mot7!  

I'm sure that's also true of the people who run blockchain.info, you should go tell them that.

They could write, instead of "Final Balance", "the summation of all of the bitcoins sent to this public key fingerprint (successful "transactions") minus the summation of the bitcoins sent by the private key for this public key fingerprint to another public key fingerprint that resulted in successful transactions that made their way into a block that was accepted by the network", but that would be silly. Likewise, for ever instance that I've said the word "balance" in reference to an "address", I could have defined what those words really mean and how they are calculated, but that would be ridiculous too. It is assumed that people like you who claim to understand how bitcoin works know what those words refer to.

Yes, and that doesn't prevent the MITM attack that I mentioned.


What language do you speak then? Special forum language?

Here is an address: 18uvwkMJsg9cxFEd1QDFgQpoeXWmmSnqSs

Click on that link and you will see on the resulting page a label that says Final Balance, indicating what I think is a "balance", at an "address".


... Maybe I will take the time, or maybe I won't. It doesn't much matter in the end does it? If you don't see the potential usefulness of the idea at this point, I don't think you'll see it even if I write the code for it, so why waste my time?

Sometimes I'm not super sharp with vocabulary that I don't use on a daily basis, sorry.

Just like people who say "ATM machine" or "HTTP protocol" though, it doesn't mean that I don't know what these things are.


Although you did not explain how this proposal is inferior to SPV, I'll try my best to show why it provides stronger security than SPV:

SPV clients can't do block-height verification, whereas rolling-root clients do. Because of this, SPV clients can be fooled by a MITM double-spending attack:


Rolling-root clients that have downloaded the blockchain of height W (the window size) cannot be fooled by this.


Sorry, I'm not sure I understand you, what are you accusing me of throwing away? I'm pretty sure I'm not throwing away block-depth verification if that's what you mean.


Don't think that's true, as I've pointed out multiple times.

A protocol that requires a new node to potentially download hundreds of terabytes seems like it already has problems significant enough to threaten its future existence.

If that absurd requirement can be removed at the tiny expensive of decreasing the "trustlessness" from 100% to ~99%, then it seems like an improvement to the protocol.

There is nothing stopping some nodes from serving as archival nodes (and potentially competing with one another). There are probably a bunch of ways to restore the trustlessness of the system (or notify nodes that they need to look farther back in time) if needed.

For example, say the window size is 1TB, and the total legit blockchain is 100TB. Rolling-root nodes as well as archive nodes could help with the verification of the current rolling root. They could include in the current rolling root a hash of some data that is representative of the rest of the 99TB. If the rolling-root clients discover a discrepancy in this hash, they'll know immediately that something is up. At that point they could initiate additional verification until they resolve the conflict.


That is not true.


Nobody could abuse it. The ancient unspent coins are signed by a private key that only their owner (hopefully) has. The balance isn't being modified. All that's happening is that balances are being carried forward so that they stay within the window.

There are two things that can be done with old coins:

1. If the idea of a "lost coin" is to be supported as a method of data-compression, then nodes would be responsible for ensuring that old coins are moved forward periodically. They could send a special transaction to do this and wait for it to be confirmed by the network.

2. If that sounds scary, coins can be kept forever regardless of age. The transactions containing them can simply be moved automatically according to some strict rules that I don't care enough to come up with (but am pretty sure exist). The private key is not needed to do this. The history of that transaction will be verified by the rolling-root clients up to the last known root that they have.

Also, the rolling-root clients can locally store (via pruning) the blockchain past the blockchain window size (for as long as they've been running).


Well this conversation is also about addressing the bandwidth requirement for new nodes to come online, and not specifically local storage requirements (pruning works for that, as you point out here, and as I pointed out earlier and in the edit to the OP).

DeathAndTaxes, replies to your constructive comments are inlined below:


Thank you, I understand that but it's helpful to emphasize that.


How?

You can state that as much as you want, but without a "because ..." it's a "just-so comment" without a leg to stand on.

The relationship indeed becomes no longer 100% trustless as I've acknowledged multiple times.

But for the sake of a tiny increase in trust, you get a network where new full nodes can be brought online without having to download several hundred terabytes of data. EDIT: that still retain their ability to verify all the way back to the original root, on their own time.

If Bitcoin gets to that point, you will come back to this proposal, and you will see it in a different light all of a sudden.

You see, as I've mentioned, I have read the Bitcoin paper. Several times. I understand it well.

The Bitcoin paper points out this interesting property of the blockchain: that the longer it gets, the harder it gets to fake. Impossibly harder.

You don't need to download a blockchain that is 200TB in size to become pretty darn sure that what you're seeing is the Real McCoy. 1TB will probably do just fine (depending on the volume of transactions of course).

So, if you're going to reply again (and you want a response from me), please reply to one of the points that I've made, and avoid doing any of the following:

- Calling me a troll (because I am not trolling) or resorting to other forms of ad hominem
- Making "just-so" statements like I "don't understand", without showing what I am misunderstanding
- Telling me to go read the paper that I have read several times.
- Telling me to go read the wiki. I have done that. I've even quoted it here recently.
- Lying.

Yes, I try to be. I also try to be a "sophisticated consumer" of public forum comments.


On IRC I agreed that it's not 100% trustless, and frankly you weren't very helpful, just like you're not being helpful here. sipa was the one who actually gave meaningful help and explanations. (None of which, btw, showed that this proposal "lacks security" or anything of the sort.)

So far, this is what has happened here (as far as I can tell):

Me: blah blah blah
Someone: that won't work because of X
Me: That's incorrect because of Y
Realpra: Sugarpuff, your proposal had this other name (indication of agreement).
gmaxwell: "You haven't really addressed _any_ of the objections here"
DannyHamilton: ad hominem attack directed at sugarpuff

OK, if this is how you guys discuss ideas, no thank you, I've had enough. I'll reply to constructive comments that actually address the merits of the proposal only.