Bitcoin Forum
September 23, 2021, 09:58:16 PM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Replacing old UTXOS with new one in place: an idea/suggested complexity reductio  (Read 424 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
Shymaa-Arafat
Member
**
Offline Offline

Activity: 157
Merit: 84


View Profile
May 17, 2021, 03:00:12 AM
 #21

Getting back to the main topic, I think I should add this in reply (like it is there)
.
Neglecting the effect on the proof size (which depends on the tree height)at least for now,  I think replacement reduces the size/amount of "change" in proofs. When less branches r modified, less internal nodes change their concatenated hashes. This could be helpful, especially when u r caching some of them.
.
For example in the run results we were discussing, the numbers suggest an av of +9 (165251/180000) insertions, 6-7 deletions per block (surely this is a small test data), resulting in 2-3 increase in the no of UTXOs per block.
When inserting then deleting u change 15-17 branches along with the corresponding internal nodes hashes, while if u modified when possible u only mess with 9-10 branches.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1632434296
Hero Member
*
Offline Offline

Posts: 1632434296

View Profile Personal Message (Offline)

Ignore
1632434296
Reply with quote  #2

1632434296
Report to moderator
1632434296
Hero Member
*
Offline Offline

Posts: 1632434296

View Profile Personal Message (Offline)

Ignore
1632434296
Reply with quote  #2

1632434296
Report to moderator
Shymaa-Arafat
Member
**
Offline Offline

Activity: 157
Merit: 84


View Profile
June 12, 2021, 07:25:51 AM
 #22

Quote
They finally replied
Quote
he -> Hashes ever. All the hashing ever done.
.
.
Yesterday when I was checking if they answered my issue, I found this
https://github.com/mit-dci/utreexo/issues/276
I think, my understanding that could be wrong I don't mind reading other should, could be the real reason for the output "he" having that unexplained/not logical value in the run...

Line 84 in the function that keeps running forever (probably meaning till the end of the run, manually as u did)

  84  curHeight++

This value is probably added to "height" in  line 99 here

 99 for ; height <= knownTipHeight && !stop; height++ {

 "he" when u stop the run
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!