Topic: I got an idea: THROW AWAY THE BLOCKCHAIN (Read 412 times)

As said, you've eliminated the trustless aspect of Bitcoin if you do implement this. You need to be able to link each of the transactions into blocks which have generated the coins. Else, it won't be as difficult for attackers to create coins out of thin air.

Who is going to be the "historical node" when storing the entire copy of the Blockchain? Big corporations? How are you going to count on them as it gets centralised and trust them? How difficult would it to attack those limited number of nodes?

The BTC block-chain now comes in at 200gb in size and the ball has only just stated rolling

That's a big number in any database or file system folders and remember we have only just stated.

To process a transaction to see if a wallet has the money to spend you have to trace each part of
a coin back down the chain to the date it was originally mined so you cannot just jump to the top of the
data and need to pull data from all over the place, leafs in a database or ledgers on the file system.

Unless "everyone" has an I7 machine running 16gb or ram and large fast disk drives then we are already past
"Everyone" and you want to see what happens to a database than has an index on a field and the index won't
fit into ram and it keeps getting paged in and out of memory because this is where we are going and believe me it's slow.

We been sold a duff one, hope your starting to see it and want to be part of the solution like I do.

This would be impossible without also implementing coins ageing. If what you propose implemented I wouldn't be able to spend coins dated before the point where you decided to cut block chain (because proof of those coins being spendable will cease to exist). I.e. what you say could be possible if after cetrain number of blocks coins that were unspent before automatically moved to coinbase. That would also effectively return forever lost coins to the coinbase, eliminate Satoshi's stash and upset a lot of long-term hodlers, who for some reason was ignorant of this implementation.

This happened once seven years ago. When the bad transaction was discovered everyone started over from the block before it was confirmed, and so that bad transaction no longer exists.

so it'll run separate node, and the main chain just for transaction(transfer) then "historical nodes" will record it ?

Special "historical nodes" could be the keeper of that history.

and with the idea like this, you can't see your transaction history from years ago isn't it ?

I guess the thought could be that we reverse the current order.  Instead of the miners keeping the whole blockchain and pruned nodes compressing it, the miners would be running on a compressed blockchain and some nodes would be preserving it to be searched with block explorers (which block explorers I predict will be the next google once we start leveraging op_return more).

I have a question, say a miner figures out that a transaction was fraudulent yet it has been fully confirmed.  Could that miner alter that transaction in the future to reflect his view of reality and would other miners have the choice to accept his edit?

Besides the technical problems you will face, you will have to convince the community (miners) to adopt your solution.
Moreover, your idea completely contradict the concept of blockchain where each block is related to the previous one.
May I also ask where will you save the old blockchain (you can't just throw it away)? It must be saved somewhere (to know if a wallet have enough funds) and thus there will be no more decentralization.
This will make the network more vulnerable.

You could say, replace the blocks after 1000 confirmations, but don't actually delete them until 2000. That way everyone can see that your generation transaction has all the same outputs as the transactions 1000 blocks ago, and by the time the old blocks are deleted this one will be deeply confirmed.

The "first mover advantage" doesn't matter if it's a valid transaction. If it's valid, it can be confirmed, and the blockchain is not a judge of if a key was stolen or used by the wrong person. It is only a judge of the keys, and getting rid of old blocks isn't going to change anything about that - if you steal a bitcoin key, and get a transaction confirmed paying you the stolen money, there's already basically nothing anyone can do but ask for it back.

A new challenge is that the transaction ID of those outputs that get transferred over is going to change. Some programs are going to have a hard time keeping track of that. Also, a transaction signed 2000 blocks ago but not broadcast is suddenly invalid and has to be recreated from scratch.

This kind of already exists in bitcoin - you can choose to "prune" the blockchain on your client, meaning delete blocks after so many confirmations, but keep track of the unspent outputs in those blocks. Then the other nodes still keep a full copy as normal and you can still function as a wallet.

Is that much simple in practical?  It may not be possible as the blocks are connected each other only by matching with digital signature. Finally where will be our transactions history for future reference because now a day we started dealing with shopping and other things what we are doing with fiat.
Someone may not required their old transaction but why do people who are dealing with huge. Archive process will not work here.

I think that would work.  We could call it a "Parsed Blockchain", a node would discard the history of a transaction chain, or at least the signature/witness data after some arbitrarily determined number of confirmations.  The only question I have is lets say a transaction is fraudulent, do the first few confirmations pretty much increase the odds that other nodes don't catch it?  The question is; is there a "first mover advantage" to getting the first few confirmations even if ultimately 1000 are needed to prune it?

Someone could still run a "Historical Node" which doesn't confirm transactions but maintains a full, un-parsed, history of the blockchain so it can be searched for posterity.

If it were done that way, in theory you could discard blocks continuously as they reach that very high number of confirmations, instead of waiting to make a new chain from scratch. Then the outputs created in the discarded block that haven't been spent yet would go in the new one as part of the generation transaction.

Blockchain has to be as distributed as possible. It's easy to attack a few nodes/places to effective deny anyone access of the information and it gets harder the more nodes there is. Who is to keep the official copy? What guarantee is there that they're not working in cahoots with the government/any rogue entity?
It has to be hard coded into the client for which everyone runs for it to be irreversible. Even with that, it would cause problem with the consensus.

It is. Transparency is one of the fundamental feature of Blockchain. To be fair, when you are loading the client for the first time, you cannot assume that the genesis block that you've received is legitimate. Each client has to individually verify that the balance of each and every of the address is exactly what it says in the new genesis block. We can't remove the trustless part in Bitcoin.

Yeah, with the propagation and the verification. Most node would crash, considering most are ran in VPS and Raspberry Pis.

That's right you wouldn't be able to reference the old chain at all anymore after the new genesis block is confirmed.  But you could require a very high number of confirmations required on the genesis block to be accepted that way the whole blockchain has the opportunity to vote on the validity of the new genesis block and hence the compression of the blockchain.

How will new nodes verifying the first block of the new chain know what all the starting balances are? They can't just check the last chain because they aren't going to download a copy of it in the first place. What if someone makes a first block of a new chain giving themselves a million extra coins? How will the nodes know that they are or aren't rightfully entitled to those coins without seeing transaction history?

Maybe.  Yes it would have to have an entirely new set of confirmation protocol.  Like require 1000 confirmations or something.  You may be on to something.  But it would be a real huge event and wow what a spectacle to get people interested in bitcoin .

It may take weeks or months to confirm this block!    Depending on how many people are trying to attack it.

Lots of people propose compressing the blockchain; what you are proposing here is the only real way to accomplish that.  But man it is kinda risky!  But exciting and I think it deserves serious consideration.

Maybe this can be solved with a hash related in a strong way to the old blockchain and all the new coinbase outputs, all incorporated into the new block? Like the mother of all merkle trees would have to built. Maybe the consensus function for to validate this particular block would have to be very special and robust.
 

Ok you don't really know that a house was bought, or that person x paid person y amount x on a certain tx, in order to keep on transacting and for the network to keep functioning. It's a genesis block on a whole new blockchain, just like the first one. So it still works. If you need to prove something that happened before the new genesis block, then you can parse the old blockchain. I guess there should be "official" copies somehow, and maybe me saying "throw away" was just colorful (and accurate) hyperbole used to show how liberating it would be for 99.9% of everybody.


In the 1,000,000 block it would be the coinbase issuing the balance of every address that has a balance. I'm thinking attacks by miners have same obstacles as any other block.




We are definitely not better off going to the traditional banking system.
While I disagree that "for everyone to see the transactions in the address" is the whole point of a blockchain, I do agree that it is a feature of them. But if you have a valid genesis block with values assigned to addresses and you don't care about the history, then you wouldn't need to care about the old blockchain. If you do care, the point is solved by the fact the old blockchain is perusable and still pertains to the addresses in the new blockchain.



Ah i did not know that. But it does seem like there has got to be some computational overhead somewhere with the 25,000,000+ addresses getting coins from the coinbase. If not, then all the better!

Problem is this event, the mining of the new genesis block, would be RIPE for attack.  Its like saying "all of fort knox gold is going to be moved on such and such a date".  All the thieves set their alarms.  Getting those first 6 confirmations will be key and if the same player can get all six then he could rewrite the history of the entire blockchain.

Good thinking though, keep up the thought process.  Good work.