Topic: A rolling root to solve Bitcoin's scalability problem? (Read 7368 times)

Hmm.. myopia from the outset is not a good sign for the project, especially when such assumptions have been proven demonstrably false already.


"Some" or "all" wish to remain anonymous? If "some", then why aren't you mentioning the names of those who don't wish to be anonymous?


Ah, that's good to hear.

Well I'll keep that in mind but we already have a lot on our plate and I don't feel like pools pose a significant threat. People tend to leave pools when they become too large anyway.

There were several people involved in the development of the scheme and I have two developers working on the implementation. Some of them would prefer to remain anonymous so I refrain from mentioning names when possible.

No, that is a test thread where the client must run in testnet mode. Any coins mined in those tests will be lost, we've already had to reset the blockchain one or two times due to changes we made in the protocol.

What do I not understand? Be specific, otherwise you're wasting everybody's time.

In research papers the passive voice is often used. Likewise the royal we is often used even with one author (e.g. In a dissertation) despite Mark Twain's comment on the matter.

It does depend on the publication guidelines and local custom.

I thought you might answer something like "do arithmetic"... I hate to say it but I think that I must agree with some of the other members who have posted here when they say that I think you lack quite a lot of understanding regarding bitcoin: the protocol.

NB. I'm not saying that I think that you don't understand bitcoin: the idea.

bitfreak: your paper is on my reading list and I have already read part of it. I'd like to get back to you soon on it with my impressions. Your paper will be the ... 3rd or 4th alternative consensus/blockchain proposal that I've reviewed, and it looks promising. Here are some preliminary comments since I suspect that my full review won't come for a while due to deadlines:

- One of the few important things that you're missing is the recent 51% solution to mining pools. Add that to your protocol/software and you'll go a long way to have a altcoin/altchain of major significance.

- You use "we" frequently in your writings but it sounds like you mean to say "I". If you have multiple people working on this you should make that clear by mentioning their names.

- Your other thread seems to indicate that you're already mining and giving away coins? There are good ways and bad ways of doing this, and depending on which method you choose it can make or break your coin. More fair = more chances of success for the coin (and you). I recommend doing a *lot* of reading on this and seeing how other coins approached the task (and what the end result was). And if you're too lazy to do that, just do whatever Ethereum is doing (Vitalik is a bright guy).

Now, to answer e4xit:


The balance is calculated from the inputs and outputs to that address. You would need to know how to do arithmetic to figure it out (or have your computer or friend do it for you).

Could you show me the lines from the blockchain (not the website) which show the 'balance' for this address you have selected as I can't find them and I have been searching for hours, thanks.

(reminder of your selected address 18uvwkMJsg9cxFEd1QDFgQpoeXWmmSnqSs)

There is no such thing as "spent" and "unspent" transactions in the mini-blockchain scheme, and you're right, it's not the same as a "rolling root" design. The transactions simply perform operations on the account tree (the balance sheet). So you see, the inputs and outputs in our transactions do not point to other transactions, they simply point to addresses in the account tree, so the transactions aren't linked together the same way they are in bitcoin, and we can discard all transactions after a safe amount of time has elapsed (enough to make the Secret Chain Attack infeasible). In our implementation nodes will be able to delete all transactions older than a week, but they can choose to store as much history as they want. I'm sure many people will even choose to store the full blockchain for historic reasons. But for new nodes who don't have any of the blockchain, they wont need to download the full blockchain to synchronize with the network and become a full node, they only need the last weeks worth of transactions and the account tree. Of course the account tree will grow over time as new non-empty addresses come into existence but the level of compression and scalability this system offers is virtually unbeatable.

Sounds like "bitfreak!" might have implemented something not quite the same as a rolling root... I'm not sure why he's getting rid of unspent transactions after 1 week though (sounds like a bad design choice, but maybe I misunderstood when I skimmed it).

However, I am now getting more and more convinced that UTXO accomplishes the same goals as rolling root, just in a different manner. Since someone appears to be involved in implementing it, that seems like the way to go.

See this post and the replies that come after it: https://bitcointalksearch.org/topic/m.7423013

Then fork it and implement the changes - unless that is what you've been working on since March and are ready to release some alpha or beta code, which would be cool.

Code will give some very good data as to how it works, potential issues etc.  Discussing it here will do little, but since it is open source, implementing will do a lot.

As mentioned, it's not really possible to do that with Bitcoin due to the way inputs and outputs work. But I do have a project underway right now where we are designing an alt coin which works in essentially this way, it stores the balance of all non-empty addresses in a structure we call the "account tree", enabling us to delete ALL transactions after a certain period of time passes (1 week in our implementation). We have removed the entire idea of interlocking transactions and replaced it with a much simpler concept where transactions perform basic operations on the account tree such as "subtract coins from balance of address A and add to balance of address B". Obviously without any type of script system our coin is less flexible, but we've already got support for multi-signature transactions, and many other cool features that aren't really possible without a balance sheet scheme. When you get down to it, people really just want simple types of transactions to perform simple banking functions. If we want this extreme level of scalability we're going to have to give up some flexibility, and that's not such a bad trade off considering that Bitcoin already has pretty strict rules about what transactions are considered standard format.

The other trade off, which seems to be more concerning for most people, is that deleting all the old transactions could lead to a situation where no one has them, since no one is required to have them, and that opens the door for someone with 51% or more of the hashing power to pull off an attack we call "The Secret Chain Attack". In our implementation it would require the attacker to maintain the majority of the hashing power for more than a week (in secret), since all transactions can be discarded after a week. But we believe even if this attack does happen it wont be catastrophic because 1) the attack will only affect nodes who haven't synced with the network in more than a week, all other nodes can detect the attack and reject the fake chain and 2) a possible Secret Chain Attack underway can be detected by new nodes, although they cannot know which chain is the real one. Based on settings specified by the user the new node will either refuse to participate in the network until one chain wins, or stick with the first chain it received, or wait for the release of a "community checkpoint" which would point them to the correct chain in the off chance this attack did happen.

Test thread:
[TEST RELEASE] Cryptonite binary for linux (mini-blockchain implementation)

Project Wiki:
Mini-Blockchain Project Wiki

More on Secret Chain Attack:
Weaknesses and attack vectors

In the UTXO thread, I modified the "7 steps" in the previous posts here with my current understanding of how UTXO can be used to quickly boot up "full-security new lite-nodes":

https://bitcointalksearch.org/topic/m.7423013

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.

OP, It seems like the bottom line is you would need massive changes to bitcoin (with hard fork) to do what you want to do....and really the scalability problem is quite manageable so that's why it doesn't make sense.

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://bitcointalksearch.org/topic/m.7391152

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:

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://bitcointalksearch.org/topic/m.971762

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.

When DeathAndTaxes says there's no such thing as a bitcoin balance, he's not making a philosophical point. He's saying that full nodes do not have balances, or the information necessary to efficiently calculate them in their working memory. Adding capabilities based on balances would require either adding this information to the working set (thereby increasing resource usage for all full nodes), or switching to using balances only which has drastic implications for bitcoin in terms of its low-level functionality. It would be a hard-fork that breaks all infrastructure out there for dubious benefit.