4 ms·

I believe the point of segwit is more than accounting. Essentially these signatures /spend-scripts are pruneable once the blocks they are in are old enough. Af

by rocqua 6y ago

I believe the point of segwit is more than accounting. Essentially these signatures /spend-scripts are pruneable once the blocks they are in are old enough. After all, if a transaction had an invalid spend script, it would not have gotten 100 blocks worth of confirmations.

csomar 6y ago
Bitcoin has checkpoints: https://bitcoin.stackexchange.com/questions/1797/what-are-checkpoints https://bitcoin.stackexchange.com/questions/1797/what-are-ch... even for normal P2PK transactions.
- nullc 6y ago
  Checkpoints don't do what you think they do. They only exist today as a mechanism to prevent nodes from being flooded by low difficulty fork blocks, forking off back before height 230k, because the initial difficulty of Bitcoin (2^32 hash operations per block) is too low relative to multiple TH/s asic mining devices.
  - keymone 6y ago
    is there any ongoing work to have utxo set commitments? if not - why?
    - nullc 6y ago
      I'm not sure, I haven't been actively involved in development for a couple years. There were a couple distinct activities. One is the rolling utxo hashes, which has no major engineering hurdles, and can allow a compromised security "bootstrap from a utxo set". The other are schemes that allow nodes to not have the utxo set but still validate-- these have historically had unfavorable IO costs, and the bandwidth storage tradeoff hasn't seemed that appealing-- e.g. would you find reducing storage from 10 GB to 1MB but at a cost for increasing bandwidth 10x to be appealing? In some applications it would be, not others. I believe work related to both has been ongoing, however.
      - keymone 6y ago
        > compromised security "bootstrap from a utxo set" could you elaborate what's compromised about including a sha256 of utxo set in every block and allowing users to choose how far back they want to bootstrap from? isn't it strictly better than current situation with assumevalid?
        nullc 6y ago
        Depending on a utxo state in blocks is effectively the SPV security model, -- it's an utter blind trust in miners to set the value honestly. Something which is only theoretically sound on the assumption that someone else is checking. If you're happy with the spv security model-- perhaps you should be using SPV? :) This is a little trite I know, because it's not quite identical because of the "past": but the vast majority of the sync time is in the last two years in any case, and practical considerations mean you wouldn't be able to just arbitrarily choose how far to sync from (as you need to be able to get the utxo set as of that height). In the ethereum world effectively almost all synchronization is done using 'fast sync' which is essentially the committed utxo blindly trust miners model. Performance and storage considerations mean you can't go back more than a tiny amount of time (I believe its normally 4 hours). Many commercial entities operate with multiple nodes and if they detect they've fallen behind they just auto-restart and fast sync to catch back up. Effectively this means that if miners commit invalid state they'll just blindly accept it after a couple hours outage. All assumevalid is doing is asserting that the ancestors two weeks back and further of a specific block hash all have valid signatures. When you get a setting there as part of the software you're running you're assuming that the software isn't backdoored (e.g. because of a public review process, or your own review). Assumevalid is strictly easier to review than pretty much any other aspect of the software integrity. E.g. there are 100 places where a one character change would silently bypass validation completely. Reviewing AV simply requires checking that the value set in it is an accepted block in some existing running node. AV as implemented also requires the blockchain to agree and have two weeks of work ontop of it, so it's just in every way harder to undermine validation by messing with it than changing the code some other way. On a technically pedantic point. It takes a minute or so to sha256 the UTXO set, so doing literally what you suggest would utterly obliterate validation performance. (fortunately rolling hashes accomplish what you mean without the huge performance hit.)

by rocqua 6y ago

csomar 6y ago

Bitcoin has checkpoints: https://bitcoin.stackexchange.com/questions/1797/what-are-checkpoints https://bitcoin.stackexchange.com/questions/1797/what-are-ch... even for normal P2PK transactions.

nullc 6y ago
Checkpoints don't do what you think they do. They only exist today as a mechanism to prevent nodes from being flooded by low difficulty fork blocks, forking off back before height 230k, because the initial difficulty of Bitcoin (2^32 hash operations per block) is too low relative to multiple TH/s asic mining devices.
- keymone 6y ago
  is there any ongoing work to have utxo set commitments? if not - why?
  - nullc 6y ago
    I'm not sure, I haven't been actively involved in development for a couple years. There were a couple distinct activities. One is the rolling utxo hashes, which has no major engineering hurdles, and can allow a compromised security "bootstrap from a utxo set". The other are schemes that allow nodes to not have the utxo set but still validate-- these have historically had unfavorable IO costs, and the bandwidth storage tradeoff hasn't seemed that appealing-- e.g. would you find reducing storage from 10 GB to 1MB but at a cost for increasing bandwidth 10x to be appealing? In some applications it would be, not others. I believe work related to both has been ongoing, however.
    - keymone 6y ago
      > compromised security "bootstrap from a utxo set" could you elaborate what's compromised about including a sha256 of utxo set in every block and allowing users to choose how far back they want to bootstrap from? isn't it strictly better than current situation with assumevalid?
      - nullc 6y ago
        Depending on a utxo state in blocks is effectively the SPV security model, -- it's an utter blind trust in miners to set the value honestly. Something which is only theoretically sound on the assumption that someone else is checking. If you're happy with the spv security model-- perhaps you should be using SPV? :) This is a little trite I know, because it's not quite identical because of the "past": but the vast majority of the sync time is in the last two years in any case, and practical considerations mean you wouldn't be able to just arbitrarily choose how far to sync from (as you need to be able to get the utxo set as of that height). In the ethereum world effectively almost all synchronization is done using 'fast sync' which is essentially the committed utxo blindly trust miners model. Performance and storage considerations mean you can't go back more than a tiny amount of time (I believe its normally 4 hours). Many commercial entities operate with multiple nodes and if they detect they've fallen behind they just auto-restart and fast sync to catch back up. Effectively this means that if miners commit invalid state they'll just blindly accept it after a couple hours outage. All assumevalid is doing is asserting that the ancestors two weeks back and further of a specific block hash all have valid signatures. When you get a setting there as part of the software you're running you're assuming that the software isn't backdoored (e.g. because of a public review process, or your own review). Assumevalid is strictly easier to review than pretty much any other aspect of the software integrity. E.g. there are 100 places where a one character change would silently bypass validation completely. Reviewing AV simply requires checking that the value set in it is an accepted block in some existing running node. AV as implemented also requires the blockchain to agree and have two weeks of work ontop of it, so it's just in every way harder to undermine validation by messing with it than changing the code some other way. On a technically pedantic point. It takes a minute or so to sha256 the UTXO set, so doing literally what you suggest would utterly obliterate validation performance. (fortunately rolling hashes accomplish what you mean without the huge performance hit.)