|
Title: Excluding Transaction Inputs Post by: SapphireSpire on November 12, 2019, 09:47:55 PM The blockchain is way too big. Why do we need all this information? Outputs are required for the confirmation of new transactions but inputs and spent outputs are not. The only reason this data can't be deleted from the blockchain is because they are part of the data set that was originally used to generate the merkle root and the block hash.
What if we exclude input data from new blocks before they are hashed? Nodes can still validate transactions in new blocks using input data in their mempools and we can discard that data whenever we want. The problem, however, is that utxos in the blockchain cannot be re-confirmed after the input data is discarded. An attacker with enough hash power can chose any old block for which he believes no input data exists and generate an alternative chain segment that, under current consensus rules, can later be used to orphan it and every block above it. Instead of blocks becoming more secure with each confirmation, they become more vulnerable. The simplest solution to this is to make blocks immutable as soon as they become part of the main chain. That's when the network can safely discard the transaction data and prune the outputs that have been spent. Now the blockchain is much smaller and even more secure than before. Title: Re: Bitcoin Unchained Post by: DooMAD on November 12, 2019, 10:07:26 PM If the solution was that simple, do you honestly not think someone would have done it by now?
How is the network supposed to arrive at consensus if there's no longest chain to follow? How do you validate a transaction with no inputs? What happens to all the inputs and outputs we've already made? What's to stop miners altering the data in these so-called super-blocks? //EDIT: I'm just going to refer you back to this post (https://bitcointalk.org/index.php?topic=5197065.msg52930361#msg52930361) made in your last topic attempting to "fix" Bitcoin. I'm impressed that you managed to come up with an even worse idea than that one. It's like saying you can take out the hard drive from your PC and just use the memory to do everything you need. It's not going to work like you think it does. Title: Re: Bitcoin Unchained Post by: Deathwing on November 12, 2019, 10:24:10 PM Go ahead, feel free to fork and code it yourself if you believe this is the right way. Good luck on establishing a history for all payments though, good luck on preventing 51% attack, good luck on actually giving a mining reward, good luck on rewarding miners based on TX fees. Overall, it's going to be a very, very interesting to see how it would play out. Spoiler, it would not, at all.
Title: Re: Bitcoin Unchained Post by: Balthazar on November 13, 2019, 04:02:56 AM As a payee, I don't care about verifying past ownership, I only care about verifying the current owner which means I only care about this one signature. To validate the coin itself, I don't need to know it's history, I only No, you've made a wrong assumption. That would be correct for account-based chains, but not for UTXO-based chain like bitcoin.need proof that it ultimately originated from a genuine coinbase transaction, which is also what the signature proves. With UTXO chain, a full validation of transaction history is necessary to ensure that all of UTXO entries are valid. Including the one which was used for your incoming payment. Otherwise it would be possible to inject fake coins through the protocol implementation issues. Title: Re: Bitcoin Unchained Post by: NeuroticFish on November 13, 2019, 01:24:24 PM However, as long as the majority of miners are working to protect the network OK, so instead of having a chain of blocks you propose "replacing" one "current state" object. But sync doesn't happen for everybody in the same time. That's why the mined blocks in a shorter fork will become orphaned. Yes, I know, you wrote that the best "state" is the one saved with the highest difficulty, but this wold mean that you force the network difficulty increase continuously, which will not happen always, it just cannot happen - the new "states" will be mined slower and slower until the process will stop (that's why Bitcoin has difficulty adjustment). I think that this is one of the flaws of your logic for now. Title: Re: Bitcoin Unchained Post by: Balthazar on November 13, 2019, 05:41:25 PM To create fake coins, an attacker would need to overcome two obstacles: I guess you didn't dedicate enough time to read my message.1. The network of honest peers who only relay valid data 2. The total hashrate of honest miners To overcome honest peers, an attacker needs to circumvent them with his own network of dishonest peers that relay his false data. Synced nodes can't be fooled by this so his only potential victims are nodes that are currently trying to sync with the network. They go by the rule that the genuine superblock is updated at the highest average difficulty, therefore, the attacker needs to control one or more mining nodes that possess more CPU power than the honest network. Thus the hashrate of the honest network is what prevents forgery, not transaction history. The only thing you need to validate a transaction is a valid signature. Otherwise it would be possible to inject fake coins through the protocol implementation issues. Nothing will save you from bugs if you have no history log. Not even 99% of network hashrate in your ultimate posession. It already happened before (https://en.bitcoinwiki.org/wiki/Value_overflow_incident), and it may happen again in the future. Hundreds of bugs are sleeping in every project and there is no way to remove them all. Title: Re: Transaction Inputs Are Unnecessary Post by: odolvlobo on November 18, 2019, 06:19:25 PM Once a node has validated the entire chain, it can discard everything but the most recent block and the UTXO set. However, if the most recent block were subsequently orphaned, then the node could no longer function without a reorg, so it is advantageous to keep a recent history of blocks. I believe that is how a "pruned" Bitcoin Core node currently works.
One problem with every node being pruned is that it makes it impossible for any new node to start up, or any node that has been offline to catch up, or any node to recover from a corrupted database, since the blocks needed to get to the current state have been forgotten by the network. Title: Re: WTF edited much? This was the "Bitcoin Unchained" topic. Post by: DooMAD on November 25, 2019, 11:14:34 AM Why would you edit and completely rewrite the OP to discuss an entirely different concept? It's only going to confuse people reading the topic. The early replies now don't follow logically. This thread was originally discussing only having one block that gets constantly updated.
Title: Re: Excluding Transaction Inputs Post by: achow101 on November 25, 2019, 10:01:16 PM Don't vandalize or "reuse" threads.
|