Topic: rolling blockchain (Read 229 times)

Either you don't, or you aren't paying attention to what you are saying...


PROBLEM 1: There are no addresses in the blockchain.

PROBLEM 2: Not every possible script has a matching address.  What will you do with scripts that can't be converted to any of the standard address formats?

PROBLEM 3: A transaction that is confirmed AFTER this blob is added, but which refers to an earlier transaction that no longer exists?  How will that transaction be verified?

Those are the first three issues that immediately come to mind.


But his transaction doesn't provide an address.  It specifies an earlier transaction output.  However, you've eliminated that output. Therefore, how will the miners know what the public key was at that earlier output which is now gone?


This does nothing to increase the transaction rate.


There are other solutions for that.  If you want a trustless solution, use Lightning Network.  If you are willing to have a trusted third party, then off-chain accounts will work.


Transaction history is already compressed pretty well.  If you don't need the history, you can run a pruned node.  You don't need to keep the history unless you want to help others start up new nodes.


No thanks.  Take your TheftCoin scam system elsewhere. I don't want anybody deleting my money.


Go for it.  Create an altcoin with your system.  See how it works out.  By the time you've worked out all the problems, you'll probably find that you end up with something that looks a lot like Bitcoin.

Thanks, I know already the basics of Bitcoin and that no balances are stored so far on the blockchain. This is why I proposed a new kind of data blob to save in blocks (I think "transaction" is the wrong name for it), which does exactly that: it stores a public address and the amount for it on the blockchain. I know that all transactions before the blockchain pruning will be lost. Nevertheless the owner can still transfer his Bitcoins, because he has the private key to his public key. And the miners can accept such transactions, because they know the amount for this public address.

The reason for my proposal is to support a very high transaction rate, like the 50k per second of VISA, and a very short block time, like 1 second. This would make crypto money usable for fast small payments, like when you buy a coffee. The downside would be that the transaction history gets lost. But maybe this could be saved in a compressed way as well.

Think of it as a replacement for physical coins. This would allow the idea of deleting unused coins after a year as well. I know it is against the philosophy of Bitcoin, but while Bitcoin is some kind of gold, my coin would be just some euros and cents which you use regularly for small payments.

You are right, this makes it a bit more complicated, but I don't think this is a problem. The initial block of the truncated blockchain has to be downloaded from some other client. But then the client could wait again a few blocks to make sure that it is on the right blockchain, and not on some fork, or some created blockchain from the client from which it loaded the initial blockchain. Once it is running and new blocks are successfully added from multiple clients, it can be sure to be on the right blockchain (assuming it has some mean to determine that the blocks indeed came from multiple clients). It wouldn't make sense for other clients to send wrong initial blocks, unless they want to create a competing blockchain, and I don't see any way how this could be used maliciously.

I've assigned 2 Merit to your post, NOT because I think it's a good idea (it isn't), but because I can see that you are trying to learn and to understand.

You are missing a lot of information about how a blockchain works at all (and especially the Bitcoin blockchain).  I suggest you do some reading.

To start with, there are NO addresses in the blockchain.  There are no balances in the blockchain.

There are only transactions, and each transaction has 2 parts:

1. References to outputs of earlier transactions (along with data that meets the output's requirements) to provide value to the transaction.

2. New outputs which are encumbered with a requirement which must be met to use the value of the output.

If you try to remove old blocks (old transactions) and provide an address and a balance, then any reference to the original transaction will become useless.  It will become impossible to determine how much value is being spent or what the requirements were for spending it.

Note, that Bitcoin Core already has a "pruning" mode. It accomplishes this by maintaining a list of all the unspent transaction outputs (UTXO).  It builds this list by processing through ALL blocks from the beginning, and then removing a block after it has finished updating its own UTXO with the information from that block.

So, every new FULL node needs access to the entire historical blockchain so that it can build up its own UTXO without needing to TRUST ANY OTHER NODE, but once it has built its own UTXO, it doesn't need ANY of the old blocks anymore at all.  Keeping them is just a way to be helpful for other users that might want to start up a new FULL node.

Let me stop you right there! The only reason to store and keep the whole blockchain is to be absolutely sure it's the longest chain since the genesis block. Without the genesis block, which is hardcoded in any full client, you suddenly have to trust third parties again!
Think about this for a while, as what you're suggesting goes against Bitcoin's fundamentals.

What is it about oxymorons and bitcoin? On the one hand we're told to HODL, on the other hand not a day goes by where some poster suggests we should STEAL all the bitcoins 'neglected' ( in COLD HODL STORAGE ); Funny how people want it both ways,

1.) Don't sell your btc, HODL and keep the price rising

2.) If you do HODL, and don't churn your BTC daily, yearly, monthly ( just like a gov bank ), then some good MINER ( +90% china ) has the right to re-claim,aka steal that btc

An outside observer would tell you that the Powers that Be, want to have it both ways, they don't want you to sell, but they also reserve the right to steal from you, that what they told you to HODL

In summary, that's why this request will always get shutdown, the notion of BURYING your GOLD for ten+ years and returning to the same site and digging up your GOLD is the very reason why BTC was created. The idea that some jackass (MINER) can reclaim your public 'gold' cuz you weren't around is just PROOF that most ppl in the BTC community don't care one nil about the original SATOSHI PLAN for btc.

...

Lastly, roll your own BTC block chain, that's why there is already +2,000 BTC clones,.... DO-IT, do it today and frequently;

lots of good papers written on the limitations of BTC blockchain, and they all say the same thing, if you want to be de-centralized, then you can never hope to have more than 30 trans/sec ( currently 7 ), or a block larger than 4MB; or a clip short than 10 seconds ( currently 10 minutes )

[ VISA does what 10k trans/sec?? BTC will never be a VISA, BTC is a bank for rich ppl just accept it ]

It's probably GOOD that BTC can never support high transaction rate, this means it can NEVER be a back-bone for 'TRADING', which means that day-traders will have to find another racket

BTC is already HIGHLY-COMPRESSED, there is not much more that can be squeezed out of a block;

My shame in all it's glory https://bitcointalksearch.org/topic/m.26890922

Thanks, do you have references where this idea for reducing the blockchain was proposed? I've found this thread:

https://nxtforum.org/general/why-isn't-blockchain-trimming-this-easy/

and looks like doing something with the UTXO table is a bit what I wrote. But I couldn't find an example implementation, or e.g. a test with the bitcoin transaction data so far to see how much it can be reduced by using this concept.

Would be interesting to see the responses where you where bashed for the other idea as well, to learn from the arguments.

Idea of reducing blockchain size is not something new and circulating for a long time. Solution you suggest or somewhat similar was proposed before. It is tempting to ditch all spent output and forget about them, replacing big part of blockchain with single hash, but it affects historical integrity (i.e. with time history of transaction will be inevitably lost unless preserved). At the current blockchain growth rate it's size is the least of the concerns and scaling solution should not impair any of Bitcoin features (namely immutability of complete history of transactions).


Regarding your second Idea - it directly contradicts principals of BitCoin. I was unwise to propose somewhat similar but naturally was bashed by the community for this proposal.

I was thinking of a way to reduce the blockchain size (e.g. for bitcoin, but could be used for other altcoins as well), for a higher number of transactions per second. Would it be possible to use some kind of rolling blockchain? By this I mean that only the last x blocks are saved in the blockchain (x sufficient high to be sure there are no forks). To get the value of an address, all transactions for this address until block x are accumulated, and added to a new block, with a special information transaction, which is not signed, but just specifies the public address and the amount. Every client and miner can verify that it is valid before the old blocks are removed, assuming it all starts at block 0. This would mean some overhead for new blocks, because of many addresses with this info transactions, but this would be roughly limited to the number of users on the net, because even if someone uses multiple addresses, all addresses with 0 coins on it, would be deleted.

The concept needs some more details, tests, analysis etc., like it might be a good idea to add the special amount transaction x/2 number of blocks after the last transaction or amount transaction happened, to make it more secure. But I wonder if this concept is already known, or discussed somewhere, or even implemented for some altcoin.

Another idea: if for one year no transaction happened on an address, the amount could be automatically transferred to a pool from which the miners gets paid. This would require that the user sends some update transaction regularly to reset the one year counter, but would prevent that too many lost addresses accumulate over a long time. And wallet software could automate this. Only for cold storage it needs to be done manually once a year.