deploy: 94ab290

Author: adamjonas

bitcoin-core-dev-tech/2015-02/research-and-development-goals/index.html

@@ -8,4 +8,4 @@
 &lt; <a href=/bitcoin-core-dev-tech/>Bitcoin Core Dev Tech
 </a>&lt; <a href=/bitcoin-core-dev-tech/2023-09/>Bitcoin Core Dev Tech 2023 (Sept)
 </a>&lt; AssumeUTXO Update<h1>AssumeUTXO Update</h1><p><i>Date: September 20, 2023</i></p><p>Tags:
-<a href=/tags/bitcoin-core>Bitcoin core</a>, <a href=/tags/assumeutxo>Assume utxo</a></p><ul><li><p>One remaining PR</p><ul><li><a href=https://github.com/bitcoin/bitcoin/pull/27596>#27596</a></li><li>Adds loadtxoutset and getchainstate RPC, documentation, scripts, tests</li><li>Adds critical functionality needed for assumeutxo validation to work: net processing updates, validation interface updates, verifydb bugfix, cache rebalancing</li><li>Makes other improvements so pruning, indexing, -reindex features are compatible with assumeutxo and work nicely</li><li>Adds hardcoded assumeutxo hash at height 788,000<ul><li>Probably this should be moved to separate PR?</li></ul></li></ul></li><li><p>Questions about initial next steps (unanswered):</p><ul><li>Which release is this PR targeted for?</li><li>Does it make sense to merge code changes first, then hash later?</li><li>Maybe staged rollout makes sense? First merge code changes, then merge hash, then distribute snapshots?<ul><li>Assumeutxo is a new feature which needs testing.</li><li>Start by merging functionality but require modifying source to actually use it.</li><li>Then add hardcoded hash and let binary users create snapshots, verify snapshots, and load snapshots.</li><li>Later work on distributing snapshot files, making the feature more accessible.</li></ul></li></ul></li><li><p>Longer term questions</p><ul><li>Should snapshots hash be configurable, allowed to be specified on command line?<ul><li>Potentially risky to allow but not allowing might incentivize using unofficial builds</li></ul></li><li>Should other hashes by added or supported?<ul><li>Muhash would make it a easier for someone running a node to verify snapshot hashes hardcoded in source code are correct, because no it will no longer require rolling back chainstate</li><li>Bittorrent infohash could be distributed outside of source so user can know they are using the right torrent without having to download the whole thing and try to load it with the RPC</li></ul></li><li>Should hashes eventually be removed from source code?<ul><li>Having snapshot hashes could be considered a regression, since we are in the process of removing checkpoint hashes</li><li>Having snapshot hashes potentially incentivizes modified Bitcoin Core binaries that provide more recent snapshots that could be malicious</li></ul></li><li>Should source code contain only one snapshot hash, or historical snapshots?</li><li>Concerns about no one validating the hash<ul><li>Future Bitcoin developers could provide invalid hashes</li><li>The attack would be a public, non stealth attack</li><li>Switching to muhash could make it easier for more people to verify the hash</li></ul></li><li>P2P way of distributing snapshots and hashes separate from source distribution<ul><li>Have a new hash every 50,000 block</li><li>Or some other fixed N blocks</li><li>Release would have the most recent one</li><li>One of the original ideas was distributing over the P2P network</li></ul></li></ul></li><li><p>Misc</p><ul><li>Reliability of stop at height</li><li>Jameob’s makesnapshot script resolves this</li></ul></li></ul><div class=row></div></div></div></div><script src=https://btctranscripts.com/lib/jquery.min.js></script><script src=https://btctranscripts.com/lib/popper.min.js></script><script src=https://btctranscripts.com/js/bootstrap.min.js></script><script type=text/javascript src=/plugins/lunr.min.js></script><script type=text/javascript src=/plugins/auto-complete.js></script><link href=/plugins/auto-complete.css rel=stylesheet><script type=text/javascript>var baseurl="https://btctranscripts.com/"</script><script type=text/javascript src=/plugins/search.js></script><script type=text/javascript src=https://btctranscripts.com/js/custom.js></script><script type=text/javascript src=/plugins/clipboard.js></script><script>new ClipboardJS(".btn")</script></body></html>
+<a href=/tags/bitcoin-core>Bitcoin core</a>, <a href=/tags/assumeutxo>Assumeutxo</a></p><ul><li><p>One remaining PR</p><ul><li><a href=https://github.com/bitcoin/bitcoin/pull/27596>#27596</a></li><li>Adds loadtxoutset and getchainstate RPC, documentation, scripts, tests</li><li>Adds critical functionality needed for assumeutxo validation to work: net processing updates, validation interface updates, verifydb bugfix, cache rebalancing</li><li>Makes other improvements so pruning, indexing, -reindex features are compatible with assumeutxo and work nicely</li><li>Adds hardcoded assumeutxo hash at height 788,000<ul><li>Probably this should be moved to separate PR?</li></ul></li></ul></li><li><p>Questions about initial next steps (unanswered):</p><ul><li>Which release is this PR targeted for?</li><li>Does it make sense to merge code changes first, then hash later?</li><li>Maybe staged rollout makes sense? First merge code changes, then merge hash, then distribute snapshots?<ul><li>Assumeutxo is a new feature which needs testing.</li><li>Start by merging functionality but require modifying source to actually use it.</li><li>Then add hardcoded hash and let binary users create snapshots, verify snapshots, and load snapshots.</li><li>Later work on distributing snapshot files, making the feature more accessible.</li></ul></li></ul></li><li><p>Longer term questions</p><ul><li>Should snapshots hash be configurable, allowed to be specified on command line?<ul><li>Potentially risky to allow but not allowing might incentivize using unofficial builds</li></ul></li><li>Should other hashes by added or supported?<ul><li>Muhash would make it a easier for someone running a node to verify snapshot hashes hardcoded in source code are correct, because no it will no longer require rolling back chainstate</li><li>Bittorrent infohash could be distributed outside of source so user can know they are using the right torrent without having to download the whole thing and try to load it with the RPC</li></ul></li><li>Should hashes eventually be removed from source code?<ul><li>Having snapshot hashes could be considered a regression, since we are in the process of removing checkpoint hashes</li><li>Having snapshot hashes potentially incentivizes modified Bitcoin Core binaries that provide more recent snapshots that could be malicious</li></ul></li><li>Should source code contain only one snapshot hash, or historical snapshots?</li><li>Concerns about no one validating the hash<ul><li>Future Bitcoin developers could provide invalid hashes</li><li>The attack would be a public, non stealth attack</li><li>Switching to muhash could make it easier for more people to verify the hash</li></ul></li><li>P2P way of distributing snapshots and hashes separate from source distribution<ul><li>Have a new hash every 50,000 block</li><li>Or some other fixed N blocks</li><li>Release would have the most recent one</li><li>One of the original ideas was distributing over the P2P network</li></ul></li></ul></li><li><p>Misc</p><ul><li>Reliability of stop at height</li><li>Jameob’s makesnapshot script resolves this</li></ul></li></ul><div class=row></div></div></div></div><script src=https://btctranscripts.com/lib/jquery.min.js></script><script src=https://btctranscripts.com/lib/popper.min.js></script><script src=https://btctranscripts.com/js/bootstrap.min.js></script><script type=text/javascript src=/plugins/lunr.min.js></script><script type=text/javascript src=/plugins/auto-complete.js></script><link href=/plugins/auto-complete.css rel=stylesheet><script type=text/javascript>var baseurl="https://btctranscripts.com/"</script><script type=text/javascript src=/plugins/search.js></script><script type=text/javascript src=https://btctranscripts.com/js/custom.js></script><script type=text/javascript src=/plugins/clipboard.js></script><script>new ClipboardJS(".btn")</script></body></html>

bitcoin-core-dev-tech/2019-06/2019-06-06-noinput-etc/index.html

@@ -6,4 +6,4 @@
 &lt; <a href=/bitcoin-core-dev-tech/>Bitcoin Core Dev Tech
 </a>&lt; <a href=/bitcoin-core-dev-tech/2024-04/>Bitcoin Core Dev Tech 2024 (Apr)
 </a>&lt; assumeUTXO Mainnet Readiness<h1>assumeUTXO Mainnet Readiness</h1><p><i>Date: April 10, 2024</i></p><p>Tags:
-<a href=/tags/bitcoin-core>Bitcoin core</a>, <a href=/tags/assumeutxo>Assume utxo</a></p><ul><li>Conceptual discussion about the point raised by Sjors in the Tracking issue: <a href=https://github.com/bitcoin/bitcoin/issues/29616#issuecomment-1988390944>https://github.com/bitcoin/bitcoin/issues/29616#issuecomment-1988390944</a></li><li>The outcome is pretty much the same as in the issue: Some people think it’s better to keep the params, and the rest agree that at least it’s better to keep them for now</li><li>A perspective on the options: With the params, it puts more responsibility (and potentially pressure) on the maintainers, if they are removed the users have to do much more due diligence which snapshot is ok to use. But the thread to the users is a much more practical attack, at least it seems like it shortly.</li><li>Removing the params takes away the chance for users to skip the background sync entirely in the future (launching into a pruned node state). Not everyone agrees that this would be a useful feature any time soon. In its current state, this would also screw up nchaintx.</li><li>Discussion of open PRs on the tracking issue: <a href=https://github.com/bitcoin/bitcoin/issues/29616#issue-2177880415>https://github.com/bitcoin/bitcoin/issues/29616#issue-2177880415</a></li><li><a href=https://github.com/bitcoin/bitcoin/pull/29612>https://github.com/bitcoin/bitcoin/pull/29612</a><ul><li>Needs response to the latest comments</li><li>General agreement the requested changes are good ideas</li></ul></li><li><a href=https://github.com/bitcoin/bitcoin/pull/29519>https://github.com/bitcoin/bitcoin/pull/29519</a><ul><li>Not as critical as originally believed but since it’s a bug it should still be fixed before the mainnet params</li><li>Needs review</li></ul></li><li><a href=https://github.com/bitcoin/bitcoin/pull/29726>https://github.com/bitcoin/bitcoin/pull/29726</a><ul><li>Potentially ready for merge already</li></ul></li><li><a href=https://github.com/bitcoin/bitcoin/pull/28553>https://github.com/bitcoin/bitcoin/pull/28553</a><ul><li>There will be a new PR once #29612 is merged</li><li>Probably adding a mainnet checkpoint for the halving and another params can be added before the next release as well</li></ul></li></ul><div class=row></div></div></div></div><script src=https://btctranscripts.com/lib/jquery.min.js></script><script src=https://btctranscripts.com/lib/popper.min.js></script><script src=https://btctranscripts.com/js/bootstrap.min.js></script><script type=text/javascript src=/plugins/lunr.min.js></script><script type=text/javascript src=/plugins/auto-complete.js></script><link href=/plugins/auto-complete.css rel=stylesheet><script type=text/javascript>var baseurl="https://btctranscripts.com/"</script><script type=text/javascript src=/plugins/search.js></script><script type=text/javascript src=https://btctranscripts.com/js/custom.js></script><script type=text/javascript src=/plugins/clipboard.js></script><script>new ClipboardJS(".btn")</script></body></html>
+<a href=/tags/bitcoin-core>Bitcoin core</a>, <a href=/tags/assumeutxo>Assumeutxo</a></p><ul><li>Conceptual discussion about the point raised by Sjors in the Tracking issue: <a href=https://github.com/bitcoin/bitcoin/issues/29616#issuecomment-1988390944>https://github.com/bitcoin/bitcoin/issues/29616#issuecomment-1988390944</a></li><li>The outcome is pretty much the same as in the issue: Some people think it’s better to keep the params, and the rest agree that at least it’s better to keep them for now</li><li>A perspective on the options: With the params, it puts more responsibility (and potentially pressure) on the maintainers, if they are removed the users have to do much more due diligence which snapshot is ok to use. But the thread to the users is a much more practical attack, at least it seems like it shortly.</li><li>Removing the params takes away the chance for users to skip the background sync entirely in the future (launching into a pruned node state). Not everyone agrees that this would be a useful feature any time soon. In its current state, this would also screw up nchaintx.</li><li>Discussion of open PRs on the tracking issue: <a href=https://github.com/bitcoin/bitcoin/issues/29616#issue-2177880415>https://github.com/bitcoin/bitcoin/issues/29616#issue-2177880415</a></li><li><a href=https://github.com/bitcoin/bitcoin/pull/29612>https://github.com/bitcoin/bitcoin/pull/29612</a><ul><li>Needs response to the latest comments</li><li>General agreement the requested changes are good ideas</li></ul></li><li><a href=https://github.com/bitcoin/bitcoin/pull/29519>https://github.com/bitcoin/bitcoin/pull/29519</a><ul><li>Not as critical as originally believed but since it’s a bug it should still be fixed before the mainnet params</li><li>Needs review</li></ul></li><li><a href=https://github.com/bitcoin/bitcoin/pull/29726>https://github.com/bitcoin/bitcoin/pull/29726</a><ul><li>Potentially ready for merge already</li></ul></li><li><a href=https://github.com/bitcoin/bitcoin/pull/28553>https://github.com/bitcoin/bitcoin/pull/28553</a><ul><li>There will be a new PR once #29612 is merged</li><li>Probably adding a mainnet checkpoint for the halving and another params can be added before the next release as well</li></ul></li></ul><div class=row></div></div></div></div><script src=https://btctranscripts.com/lib/jquery.min.js></script><script src=https://btctranscripts.com/lib/popper.min.js></script><script src=https://btctranscripts.com/js/bootstrap.min.js></script><script type=text/javascript src=/plugins/lunr.min.js></script><script type=text/javascript src=/plugins/auto-complete.js></script><link href=/plugins/auto-complete.css rel=stylesheet><script type=text/javascript>var baseurl="https://btctranscripts.com/"</script><script type=text/javascript src=/plugins/search.js></script><script type=text/javascript src=https://btctranscripts.com/js/custom.js></script><script type=text/javascript src=/plugins/clipboard.js></script><script>new ClipboardJS(".btn")</script></body></html>