Bitcoin Forum
January 20, 2020, 08:55:34 AM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: UTXO-based blocks  (Read 128 times)
garlonicon
Newbie
*
Offline Offline

Activity: 3
Merit: 3


View Profile
October 29, 2019, 08:37:04 PM
Merited by LoyceV (2), ETFbitcoin (1)
 #1

What do you think about creating UTXO-based blocks? I mean, instead of including single transactions, having a block format like this: output (base-58 160-bit hash or anything else accepted by current protocol) + amount of unspent coins + rest needed info...; next output, next amount, etc.

1A...1 1.23456789 BTC
1A...2 0.56789012 BTC
...
1Z...9 8.90123456 BTC

In this way the most recent block will contain the state of the whole system. Of course, it would be huge, so we can organize it in some kind of tree-like structure (for example binary tree, but not necessary). All addresses will be always sorted to improve updating. Every entry could be 512-bits aligned (or any else "nice" size for hashing functions like SHA-256). Then, we could use hash of such huge block for mining.

What are advantages of this model? Firstly, we would have the whole system state in the latest block "out of the box", without processing some redundant information. Latest block hash would be based on simple hash of all entries, so we could easily download this latest huge block and have everything we need if running full node. Also we could start cutting some earlier blocks at some point of time, because it would be pointless to change some block mined 5 years ago or earlier. In this way we could preserve for example last N blocks and delete earlier information as changing it after many years (or many confirmations) will never be accepted by miners.

Secondly, it is true for all blocks, so all such blocks hashes would be made in the same way. But we would not need to upload and download everything, we could optimize identical fragments by sending hash starting with given IV and ending with given hash for any continuous amount of entries. So if we want for example to change two entries, we could do it in this way:

IV and exit hash for entries from 1 to 999
1m...x 0.54321098 BTC
IV and exit hash for entries from 1001 to 2345
1s...w 0.22223333 BTC
IV and exit hash for entries from 2347 to the end

This would be enough to calculate correct hash of the new block without knowing every unspent transaction output. In this way we could send diffs between blocks without sending the same info over and over again. And full node would need only one huge block and diffs between this block and other blocks. Light nodes also could optimize it further and download only selected outputs and keep an eye on hashes between them.

Of course for completeness all amount of coins should match, so we also need all input addresses and all signatures in such block, but we would need them once, because next block would probably contain another input addresses and of course different signatures.

Any ideas, improvements and suggestions are welcome.
1579510534
Hero Member
*
Offline Offline

Posts: 1579510534

View Profile Personal Message (Offline)

Ignore
1579510534
Reply with quote  #2

1579510534
Report to moderator
1579510534
Hero Member
*
Offline Offline

Posts: 1579510534

View Profile Personal Message (Offline)

Ignore
1579510534
Reply with quote  #2

1579510534
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Balthazar
Legendary
*
Offline Offline

Activity: 2758
Merit: 1245


Worship the Eru


View Profile WWW
October 29, 2019, 08:40:49 PM
 #2

Congratulations, you've just invented Ripple. Tongue

https://twitter.com/tuurdemeester/status/1028262924987637760

This is what you will get as the result.

Eä developer (work in progress) | ETC.HVPPS.NET (100 GH/s, PoT) | EtherDig.Ru (DGM) | Cкaжи "HET!" пoдпиcнoй пpocтитyции.
ETH/ETC: 0x8d35067233605bef6069191ae0922d134ff80d48 BTC: 33SFo5G24cp7ZKevuqc8xjKmKJyq5eWrvW
jackg
Copper Member
Legendary
*
Offline Offline

Activity: 1624
Merit: 1425


https://bit.ly/387FXHi ← a fortnight of the


View Profile
October 29, 2019, 09:23:46 PM
 #3

Can I suggest the current blockchain as an improvement? Grin

It's trustless so you can verify everything for yourself you can provably still download the chain online and parse it but you should be able to run your own node (if you want to) and have it sync within 200 hours (200 hours is based on my 10 year old computer, newer machines are much faster).

Bitcoin isn't worth so much because Ripple is better... Look at the market cap comparisons.

SapphireSpire
Member
**
Offline Offline

Activity: 125
Merit: 22


View Profile
October 29, 2019, 10:58:49 PM
 #4

I don't understand your idea but something definitely needs to be done
about the oversized blockchain. Is it really necessary to retain all this
junk? Is there any reason to trace every input in a transaction through
the history of old transactions to all of the coinbase transactions
needed to account for it? Does any wallet do that, besides maybe
Bitcoin Core? Would miners even bother with all that?
jackg
Copper Member
Legendary
*
Offline Offline

Activity: 1624
Merit: 1425


https://bit.ly/387FXHi ← a fortnight of the


View Profile
October 29, 2019, 11:26:12 PM
 #5

Miners do download the full transaction history and it's expected that they'd want to keep pools going. But it's not just mines, many people keep nodes running, you don't have to store the whole chain either, you can prune the chain but in order to keep a trustworthy source of data and remain connected to the network, you have to validate the blocks you accept from miners/other nodes.

xoyi
Newbie
*
Offline Offline

Activity: 5
Merit: 4


View Profile
November 01, 2019, 04:10:18 PM
Merited by gmaxwell (1), ETFbitcoin (1)
 #6

Is it really necessary to retain all this
junk? Is there any reason to trace every input in a transaction through
the history of old transactions to all of the coinbase transactions
needed to account for it?

How else can you be sure that no coins outside of the schedule were introduced (e.g. due to a bug)? How else can you be sure that there wasn't any double spend throughout history? Most importantly, how else you can keep an account of how much coins each address has (without depending on a trusted 3rd-party)?
Balthazar
Legendary
*
Offline Offline

Activity: 2758
Merit: 1245


Worship the Eru


View Profile WWW
November 01, 2019, 10:06:28 PM
 #7

I don't understand your idea but something definitely needs to be done
about the oversized blockchain. Is it really necessary to retain all this
junk? Is there any reason to trace every input in a transaction through
the history of old transactions to all of the coinbase transactions
needed to account for it? Does any wallet do that, besides maybe
Bitcoin Core? Would miners even bother with all that?
Bitcoin Core is a foundation of the network. And you're right, a full validation of transaction history is necessary to ensure that all of UTXO entries are valid. You don't need to actually store this data, but you have to validate it.

Otherwise you'll be forced to trust some third party, which is not acceptable. Just look at Ripple, most of p2p nodes aren't bothering to perform full validation of history. They're simply verifying few hundred of most recent blocks and the rest part of blockchain is not even downloaded. Instead, they're trusting the Ripple Labs and Ripple Labs approved set of validators.

Is this what you want for bitcoin?

Eä developer (work in progress) | ETC.HVPPS.NET (100 GH/s, PoT) | EtherDig.Ru (DGM) | Cкaжи "HET!" пoдпиcнoй пpocтитyции.
ETH/ETC: 0x8d35067233605bef6069191ae0922d134ff80d48 BTC: 33SFo5G24cp7ZKevuqc8xjKmKJyq5eWrvW
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!