Blockchains are a pain

Don’t get me wrong. I love blockchains. I think they are ingenious, there are some things that they do very well. I see them having a place for a long time to come. That’s not what I want to talk about though. They’re great but they’re a pain to deal with. By necessity, you must start at the beginning and download every bit of it in order to verify that the coins that you have are verified.

I’ve been involved in a few blockchain related crowdsales and finally decided to get the coins on my local system. They have all been systems built on Etherium. My internet connection is not slow by any means, yet its still going to take me at least 9 hours to suck down all this data, and etherium is only about a year old. Its going to get prohibitively large, even for people with huge pipes. Without getting in soon and being able to pull down data as it comes in (installment method) you wont be able to get in in another year or so.

Yes, you can download a massive zip or something like that, however, you still have to verify every single transaction from the start, and if you’re smart, you’ll check them against someone else’s transactions to make sure they’re the same (only if you go the download en-mass route) so you might as well have downloaded them in the first place.


You don’t need to download the entire blockchain though unless you are planning on mining. However the whole getting verified process in order to begin purchasing crypto currencies can be a pain.

You may be pleased to know that the SAFE network doesn’t use a blockchain.


In order to use the mist wallet for etherium you need the whole blockchain. They haven’t made light wallets yet. None that can directly interact with contracts anyway, which is what I plan to do. So for that, I do need the whole etherium blockchain. At least for now until something else gets developed.

I know safe doesn’t use blockchains. I guess I didn’t do a good enough compare and contrast in my post. I’m glad safe will pretty much just “work”. “You don’t have access? It doesn’t belong to you. You have access? Its yours” at least as far as coins go anyway.

1 Like

Oh my bad I guess Bitcoin got stuck in my head. Yes a light client would be nice for Ethereum. I think a decent implementation of an alternative to a block chain would be good to see on the SAFE network so that we can have access to secure transactions.

I agree with your sentiments.

Ethereum is a flaky system at the moment - if I don’t sync in a while, it regularly fails to catch up & I need to re-download the entire blockchain, which is slow & annoying.

For future reference, if downloading the Ethereum blockchain from scratch with Mist, use geth fast sync: go to the folder where geth is installed (Mist runs on top of geth) & from the command line run geth with the additional command ‘-- fast’ & it’ll sync significantly faster.

I hope safe can replace the functionality of blockchains in abway that makes it far easier & faster!

1 Like

lol yeh. I completely agree dude! Actually i just posted about the same thing. The blockchain is awesome, BUT…it’s starting to feel more like a ‘ball and chain’. I really hope that maidsafe cuts the ribbon soon :wink:


Blockchains are just the first distrubuted public ledger, I’m sure there will be more.

1 Like

Here’s an idea: a blockchain that is segmented according to the age of a block, with older segments kept in increasingly slower, but larger and cheaper, storage.

I read somewhere that Bitcoin blocks can contain up to 1MB of data, and they are being added every ten minutes (don’t take those figures as gospel). So on that basis I’ll construct the following scenario:

Segment A is kept in RAM and is 512MB, and goes back about 3.5 days.
Segment B is kept on SSD and is 8GB, and goes back about 2 months.
Segment C is kept on a harddisk and is 128GB, and goes back 2.5 years.
Segment D is kept online and in a datacentre somewhere, and goes back 40 (or 400) years.

The key observation (my guess) is that the lifespan of contracts drops off over time, like this, so nearly everyone is satisfied with such an arrangement going forward:

At the far left of the curve you have daily, retail commerce, and at the far right are such things as mortgages and inheritance.

This would be a scheme well suited to implementation on SAFE, if there is sufficient incentive for vaults to have a varying trade-off between speed and size. So some vaults might specialize in catering to the “long tail” type of GETs: not just old, open contracts but information of an increasingly obscure or minority interest. They can afford to do this because their storage is huge, but slow.

I would hope that contracts would build on one another over time, and perhaps this is a misconception on my part. Consider the idea of lower level languages verses higher level. The higher level languages use libraries of the lower level language and we might not even be aware of it. Those early contracts might be building blocks that need to be accessed more and more over time for efficiencies sake… Just a thought.

Well, you don’t need to keep ephemera: things that are thrown away after use: bus tickets, theater passes, grocery receipts that you only need until you have walked out the door, expired passports and drivers licences, expired insurance contracts, past agreements for paid off loans, tax returns from seven years ago. As you can see, what is called ephemeral varies with the time scale. On the scale of a human lifespan, that’s 99.9% of your contracts. On the scale of a century - three or four generations - 99.999%

It never reaches 100%.

There are quirky people who save literally everything. I once encountered an idiot who had a room full of floppy disks containing every e-mail or usenet conversation he had ever been a part of. God knows whether they would be readable by now.

1 Like

This idea of temporal segmentation is interesting. My initial thought was that the genesis block would be a problem but you could segment in a way that always preserved the initial genesis, a sort of mini blockchain.

Genesis A (Segment D)
Genesis A -> Genesis B (Segment C)
Genesis A -> Genesis B -> Genesis C (Segment B)

Then there is the problem that segments A, B and C are moving windows over time and thus eventually segment D must hold all of the generated genesis blocks for the upper echelons rather than limit it to a certain number of years. Also, what is acceptably verifiable for consensus? Segment A alone or Segment D? This may have unwarranted implications on security.

Just some random thoughts.