Excluding Transaction Inputs | Bitcointalksearch.org

SapphireSpire

jr. member

Activity: 49

Merit: 38

Quote from: DooMAD on November 25, 2019, 06: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.

Ya, I know. Well, the old concept wasn't great and the 'delete' button at the top says "user are not allowed to delete their own topics"
so I figure it's more polite to reuse it and not clutter up the forums.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Don't vandalize or "reuse" threads.

DooMAD

legendary

Activity: 3948

Merit: 3191

Leave no FUD unchallenged

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.

odolvlobo

legendary

Activity: 4522

Merit: 3426

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.

Balthazar

legendary

Activity: 3108

Merit: 1359

Quote from: ?? on ??

To create fake coins, an attacker would need to overcome two obstacles:
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.

I guess you didn't dedicate enough time to read my message.

Quote from: Balthazar on November 12, 2019, 11:02:56 PM

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, 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.

NeuroticFish

legendary

Activity: 3668

Merit: 6382

Looking for campaign manager? Contact icopress!

Quote from: SapphireSpire on November 12, 2019, 04:47:55 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.

Balthazar

legendary

Activity: 3108

Merit: 1359

Quote from: SapphireSpire on November 12, 2019, 04:47:55 PM

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.

Quote from: SapphireSpire on November 12, 2019, 04:47:55 PM

To validate the coin itself, I don't need to know it's history, I only
need proof that it ultimately originated from a genuine coinbase transaction,
which is also what the signature proves.

No, you've made a wrong assumption. That would be correct for account-based chains, but not for UTXO-based chain like bitcoin.
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.

Deathwing

legendary

Activity: 1638

Merit: 1329

Stultorum infinitus est numerus

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.

DooMAD

legendary

Activity: 3948

Merit: 3191

Leave no FUD unchallenged

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 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.

SapphireSpire

jr. member

Activity: 49

Merit: 38

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.

Topic: Excluding Transaction Inputs (Read 354 times)