Topic: Replacing old UTXOS with new one in place: an idea/suggested complexity reductio - page 2. (Read 511 times)

Reposting the images:



I think I understand what's going on here now. You want the spent inputs located on an address to be replaced by UTXOs on the same height, right?

Example: An address 1abcdef has 2BTC at input #20, also sometimes written as 1abcdef:20.

And there's a receiving address somewhere called 3abcdef that has 10 total spent and unspent inputs (so numbering would continue at 3abcdef:11).

Let's say 1abcdef:20 is used as an input to the output 3abcdef:11 in a transaction.

So technically what I think you're saying is, instead of having several different 3abcdef:1,2,3,4,... on the blockchain records, each successive input overwrites the previous one?

One problem I can think of this change is that if the historic inputs are overwritten on blockchain data (which is how you'd implement something like this since verification involves reading all the blocks from the disk), then it becomes impossible to verify previous transactions with the overwritten input numbers like 3abcdef:1,2,3 and so on.

This is a suggestion that, I think, will introduce a significant complexity reduction in the process of adding/removing UTXOS from the proofs Merkle Tree...
.
Intuition/ Rationale:
Since any transaction somehow follows the Energy Law from the point that SUM of inputs = SUM of outputs, a lot of unnecessary overhead could be avoided if deletions & insertions happened simultaneously in a replacement manner.
.
Summary:
When processing a transaction, replace the old TXOs that became input with the new ones; ie if they're the same number there will be no actual deletions/a and thus no tree swaps.. just modify the corresponding values& hashes along the proof path.
-If one old TXO led to more than one change the value of the old leaf node to be the root of a corresponding subtree of the new TXOs.

-Only if n1 inputs created  n2 outputs where n1>n2 u will have to choose (n1-n2) leaves to delete according to some criteria/heuristics
-Then deletions will this way definitely happen much less often, and a suitable heuristic could be thought of later according to some data analysis of existing blocks.
.
Examples:
I traced some inputs and outputs in 2 consecutive blocks Block 1973321,1973322 from the site:
https://blockstream.info/testnet/block/000000000000001eedf8cd0e358a0ca6144e82f5c3da263769f7ad208b8e07ba

You will find that
57.64177548 tBTC=⟩
0.01322037 tBTC
+ 57.62838604 tBTC
Then in the next block
57.62838604 tBTC=⟩
57.61015944 tBTC
+ 0.01322037 tBTC

-So, in my method a subtree evolves in place of the original leaf that represented the UTXO 57.64177548 tBTC, and no other branch of the tree get modified.
(-If the images didn't upload correctly since I'm new here, u can find them in this Facebook link
https://m.facebook.com/story.php?story_fbid=1414790592208718&id=100010333725264
Or here in this twitter link
https://mobile.twitter.com/ArafatShymaa/status/1389000211998117888)
.
-If u traced a number of blocks u'll find that the situation where the number of inputs n1 is larger than the number of outputs n2 (n1›n2) is a very rare event. Even if it is not, we still guaranteed to have less deletions  
.
That's all I have for now, thanks
.
Ps. I came from somewhat the theory not the developers community, so pls. feel free to correct me if I'm wrong & apologies for any waste of ur time