Topic: A rolling root to solve Bitcoin's scalability problem? - page 2. (Read 7369 times)

(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!  

There is no such thing as "balance at an address" that is merely an abstraction.  The only thing which exists is input and outputs.   A transactions references as it inputs the unspent outputs of prior transactions.  The transaction destroys (or "spends") those referenced output(s) and creates new outputs (which will become the inputs of future txs).

All spent outputs can already be pruned from the blockchain.  Of the ~18GB only ~4GB of that is usnpent outputs.

Random comment in here by a noob at this kind of thing, but I'm not quite seeing why this wouldn't work:

Every client keeps some kind of a record with a balance for each address, right (Or at least, a record with the balance of its own addresses).

At some point, its going to become more efficient to store the balance of each address, rather than the entire blockchain.

At that point, why not start encoding this balance of each address directly into blocks, and have it be verified by proof of work, just like every other transaction? After some number of confirmations (you can "work backward" from block N's balance table to that of block N-1 by looking at all of the transactions in block N) that transaction table is taken down and stored on your hard drive. Only addresses with balances need be stored.

Could it be that simple? Or is it useless as then the size would grow proportionate to the number of addresses with balances, instead? Still, seems number of addresses with balances < total number of transactions in the long run.

Unspent outputs are only a transactionID and an output number.   In other words , any spending of a Bitcoin requires this sha256 hash and a number referring to the output and the script therein.

Bitcoins dont exist. Inputs and outputs do.

What a rolling root should be (based on my understanding so far) is a pointer to that transaction.  

So how about this formula:

Agree on a confirmation count that provides zero trust guarantees.  Say 100,000

Find the lowest target in the blockchain (remember difficulty can decrease due to a split or other reasons).  If that is less than 100,000 (selected above) then choose the candidate purge point to start at current-100,000 blocks.  If it is more than 100,000 blocks away from the current block, candidate purge point starts at that location.

Change the block version number to "4" (versions 3 are already assigned) and include a special spot for old unspent transactions.  Transactions in this special part of the block would look like double spends if placed in the regular part of the block therefore special handling is needed.  Miners and full nodes will need to validate that the full txid hash ( no matter what normalized form it's in) is identical to the old tx.   

The transaction will then live in two blocks, but with the same txid and same outputs.  During the sunset period all clients and miners should verify that the old tx and new tx do have matching ids and content.  This protects from an exploit in sha256 as the current Tx is added to the trusted merkle tree.

After a sunset period of 100,000 blocks the old block can be purged.  

If someone attempts to modify the transaction, the SHA256 hash will be different.  All full nodes who see an altered transaction should reject the Tx, and if it's included in a block, reject the block.


Yes someone probably thought of this. Yes there are probably errors and inefficiencies but it seems logical.

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.

I meant even the remaining tx info they wouldn't care to have removed.

Those anonymizing techniques are interesting specifically because the records of transfer are not kept on-chain.

People insist on retaining a full copy of blockchain locally, supposedly for the purpose of protecting the interest of every Bitcoin user, nevertheless, if the anonymization of coins through Coinjoin/CoinSwap/Stealth payment...becomes widespread in the future, those who participate in such txs will have absolutely no interest in you keeping a record of them and couldn't appreciate you more for pruning them.

Well, this farce has gone on long enough.  By now it should be perfectly clear to anyone stumbling across this thread that you are a moron with no interest in how bitcoin actually works.

Sounds to me like I'm going to need a bigger hard disk. Still I have every faith some smart lad or lass will come up with a solution. Seems bitcoins come so far it would be a shame for it to fall apart because of the block size. I just cant see it happening or maybe I just don't want to see it.

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?

There really is no more point in discussing it because you simply lack the proper understand of how bitcoin works.  It doesn't work the way you think it does and you can't fix something you don't understand.

I will leave you wish
a) SPV clients have copy of all block headers

b) there is no such thing as "balances" at an address.  Bitcoin works on the concept of inputs and outputs.

c) you say you will "carry forward" the balance into a new block but what happens when an attacker simply publishes a chain which contains unspent outputs that nobody has the historical records to validate anymore.  can you say unlimited minting?  With the current trust model an attacker with >51% hashrate is limited in what they can do.  Under your system they could simply extend the blockchain far enough that most nodes no longer have the historical records to validate a "old" tx placed in a new block ever existed.  The attacker could destroy Bitcoin through unauthorized minting.  

d) "The transactions containing them can simply be moved automatically according to some strict rules that I don't care enough to come up with"  That is why you have no proposal.  "Um yeah we can do this stuff but it will require some stuff but I don't really fill like saying the stuff but if you don't agree with me you are jerks and just trolling.  We can fill in the stuff later and stuff."

I won't be responding again, you can't provide a proposal when you can't even speak the language.   At appeared at one time you were interested in actually learning how Bitcoin really works but that is obviously not the case.  If you have no interesting in actually learning how the system you are trying to "fix" works then don't be surprised when nobody takes you seriously.

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:


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.


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).

Saying "searching is hard" is not the same as doing research.

Satoshi already created a 100% trustless solution to this called SPV.  It allows lite nodes to be instantly online and download from peers only the portions of the blockchain they need in real time. Install client and you are instantly ready to start transacting.  Your "solution" doesn't work but even if it did would be inferior to SPV which is something Satoshi came up with before the blockhain even started.


No you don't or you wouldn't make mistakes like saying "transactions which are spent" or the one you just repeated below.  You also would have realized the SPV clients exist.


This isn't in a vacuum that property only applies because for a given tx, the tx, and everything that is needed to validate that tx is also deeper in the blockchain.  You can't throw that away and then assume the same dynamic is in play.

Any system which is not 100% trustless is inferior to the system we have now.   Why would you want to make the protocol worse.  The only way space ever becomes a concern is if Bitcoin becomes many magnitudes larger which means an economy valued in the hundreds of billions if not trillions.   Any amount of trust when the payoff is that large will be at risk of compromise.

If Bitcoin "gets to that point" true proposals for a ledger system will be given more weight but true proposals actually address the risks rather than just pretend they don't exist.   You haven't proposed anything other than drop all method of verifiy a transaction, throw it into a new block at the head of the chain and hope nobody abuses that.  That isn't a proposal, that is nonsense.

Pruning is very likely to keep the storage requirements modest.  It is likely Bitcoin will never need a ledger snapshot system but if it did it would require more thought that what you propose.  Still the true bottlenecks to transaction volume are node bandwidth and memory.  You are trying to "fix" the bottleneck which isn't a bottleneck while consuming resources on the actual bottleneck.

False.

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.

We don't need to show shit.  You need to show that your proposal has merit.  We've tried to suggest that you'd do well to find the extensive literature on this exact idea, but you've refused to do that basic research*.

As I said on IRC:


Option 1 is that you had a new and amazing insight that no one has ever had before*, and the world is waiting to beat a path to your door.
Option 2 is that other people have also thought of it, and yet it hasn't happened, quite possibly because it has flaws that you should acquaint yourself with*.

* This has come up many times in the last 3 years (I've personally seen it).  It probably came up a few times in the two years before then.  I bet that if you look closely, you'll find the basic outline of the general problem come up on crypto mailing lists back into the 90s.

No you just lack the knowledge to understand what you are reading.

As pointed out the wiki is simply public docs.  It is one possible way to deal with scalability.  Anything in the wiki which goes beyond the actual current protocol should be treated as an opinon.

However even if the cited section was implemented it would still be trustless.   Full nodes would still maintain a pruned copy of the blockchain going all the way back to the genesis block.  An unpruned copy (the archive node) is not required to validation transactions or create new blocks.   Nobody needs to trust the archive nodes.  

Your "solution" (and I use the term lightly) would break that trustless relationship between nodes.  

So either you are trolling for trolling sake or you are genuinely interested but lack the basic knowledge.  It would be like someone without any higher mathematics trying to understand how public key cryptography works and coming up with "enhancements".   If you aren't trolling, or just looking to debate to feel important ... then stop trying to fix Bitcoin before you undertstand Bitcoin.  Take a couple weeks starting with the whitepaper, the wiki and then the source code.  

Nobody is saying a ledger type system is impossible but it a non-trivial problem.  If you think you found a trivial solution to a non-trivial problem in a few minutes ... you haven't.


You haven't provided a proposal.

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.