Commit graph

24940 commits

Author SHA1 Message Date
Andrew Chow
04265ba937
Merge bitcoin/bitcoin#26331: Implement CCoinsViewErrorCatcher::HaveCoin and check disk space periodically
ed52e71176 Periodically check disk space to avoid corruption (Aurèle Oulès)
7fe537f7a4 Implement CCoinsViewErrorCatcher::HaveCoin (Aurèle Oulès)

Pull request description:

  Attempt to fix #26112.

  As suggested by sipa in https://github.com/bitcoin/bitcoin/issues/26112#issuecomment-1249683401:
  > CCoinsViewErrorCatcher, the wrapper class used around CCoinsViewDB that's supposed to detect these problems and forcefully exit the application, has an override for GetCoins. But in CheckTxInputs, HaveInputs is first invoked, which on its turn calls HaveCoin. HaveCoin is implemented in CCoinsViewDB, but not in CCoinsViewErrorCatcher, and thus the disk read exception escapes.
  > A solution may be to just add an override for HaveCoin in CCoinsViewErrorCatcher.

  I implemented `CCoinsViewErrorCatcher::HaveCoin` and also added a periodic disk space check that shutdowns the node if there is not enough space left on disk, the minimum here is 50MB.

  For reviewers, it's possible to saturate disk space to test the PR by creating large files with `fallocate -l 50G test.bin`

ACKs for top commit:
  achow101:
    ACK ed52e71176
  w0xlt:
    Code Review ACK ed52e71176
  sipa:
    utACK ed52e71176

Tree-SHA512: 456aa7b996023df42b4fbb5158ee429d9abf7374b7b1ec129b21aea1188ad19be8da4ae8e0edd90b85b7a3042b8e44e17d3742e33808a4234d5ddbe9bcef1b78
2023-10-09 14:52:00 -04:00
fanquake
3003861e78
Merge bitcoin/bitcoin#28591: kernel: chainparams updates for 26.x
bd71f03df7 doc: update example pulls in release-process.md (fanquake)
b2ede22395 headerssync: update params for 26.x (fanquake)
f12f92b813 kernel: update m_assumed_* chain params for 26.x (fanquake)
a8c2e5e556 kernel: update chainTxData for 26.x (fanquake)
a9d070a6f8 kernel: update nMinimumChainWork & defaultAssumeValid for 26.x (fanquake)

Pull request description:

  Update chainparams pre `26.x` branch off.

  Note: Remember that some variance is expected in the m_assumed_* sizes.

  Closes #28572.

ACKs for top commit:
  Sjors:
    re-ACK bd71f03df7
  ajtowns:
    reACK bd71f03df7
  darosior:
    re-ACK bd71f03df7 for assumevalid and minchainwork params.

Tree-SHA512: c586b82711477bfc1fd9ac4c9c1130ccde29f75d652492c66ef5730f4a49b7da822a3ad2d9090468ea0c9f0e77d00c25f6a800600c81878d8141ce2ffb3724af
2023-10-09 14:54:08 +01:00
fanquake
66f8ee2969
Merge bitcoin/bitcoin#28611: Adjust Gradle properties to fix apk build
5f50406554 Adjust Gradle properties (Hennadii Stepanov)

Pull request description:

  On the master branch @ d2b8c5e123, building the `apk` target fails:
  ```
  $ make -C src/qt apk
  ...
  > Task :compileDebugJavaWithJavac FAILED
  /home/hebasto/git/gui/src/qt/android/src/org/qtproject/qt5/android/QtActivityDelegate.java:690: error: cannot find symbol
                  Display display = (Build.VERSION.SDK_INT < Build.VERSION_CODES.R)
                                                                                ^
    symbol:   variable R
    location: class VERSION_CODES
  /home/hebasto/git/gui/src/qt/android/src/org/qtproject/qt5/android/QtActivityDelegate.java:692: error: cannot find symbol
                          : m_activity.getDisplay();
                                      ^
    symbol:   method getDisplay()
    location: variable m_activity of type Activity
  /home/hebasto/git/gui/src/qt/android/src/org/qtproject/qt5/android/QtActivityDelegate.java:833: error: cannot find symbol
          float refreshRate = (Build.VERSION.SDK_INT < Build.VERSION_CODES.R)
                                                                          ^
    symbol:   variable R
    location: class VERSION_CODES
  /home/hebasto/git/gui/src/qt/android/src/org/qtproject/qt5/android/QtActivityDelegate.java:835: error: cannot find symbol
                  : m_activity.getDisplay().getRefreshRate();
                              ^
    symbol:   method getDisplay()
    location: variable m_activity of type Activity
  /home/hebasto/git/gui/src/qt/android/src/org/qtproject/qt5/android/QtLayout.java:95: error: cannot find symbol
          Display display = (Build.VERSION.SDK_INT < Build.VERSION_CODES.R)
                                                                        ^
    symbol:   variable R
    location: class VERSION_CODES
  /home/hebasto/git/gui/src/qt/android/src/org/qtproject/qt5/android/QtLayout.java:97: error: cannot find symbol
                  : ((Activity)getContext()).getDisplay();
                                            ^
    symbol:   method getDisplay()
    location: class Activity
  /home/hebasto/git/gui/src/qt/android/src/org/qtproject/qt5/android/ExtractStyle.java:418: error: cannot find symbol
              if (Build.VERSION.SDK_INT < Build.VERSION_CODES.Q)
                                                             ^
    symbol:   variable Q
    location: class VERSION_CODES
  /home/hebasto/git/gui/src/qt/android/src/org/qtproject/qt5/android/ExtractStyle.java:421: error: cannot find symbol
                  numStates = stateList.getStateCount();
                                       ^
    symbol:   method getStateCount()
    location: variable stateList of type StateListDrawable
  Note: Some input files use or override a deprecated API.
  Note: Recompile with -Xlint:deprecation for details.
  8 errors

  FAILURE: Build failed with an exception.

  * What went wrong:
  Execution failed for task ':compileDebugJavaWithJavac'.
  > Compilation failed; see the compiler error output for details.

  * Try:
  Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

  * Get more help at https://help.gradle.org

  Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
  Use '--warning-mode all' to show the individual deprecation warnings.
  See https://docs.gradle.org/6.6.1/userguide/command_line_interface.html#sec:command_line_warnings

  BUILD FAILED in 827ms
  ...
  ```

  Fixing it by updating the Gradle tool's properties.

ACKs for top commit:
  fanquake:
    ACK 5f50406554 - seems fine.

Tree-SHA512: 52e59fe1c69841370ce2eb670f3618182bf2843582074af4895b8ecb6e5f70dc3fe4eecbffa212efaa534b423ced5b75020f6f09917b52f452121c1e55fbcaac
2023-10-09 14:12:00 +01:00
Hennadii Stepanov
5c9513ece9
qt: Update translation source file for v26.0 string freeze
The diff is produced by running `make -C src translate`.
2023-10-09 10:08:52 +01:00
Hennadii Stepanov
5f50406554
Adjust Gradle properties
This change fixes the `apk` target build after bumping Qt version from
5.15.5 to 5.15.10.
2023-10-08 14:01:59 +01:00
Antoine Poinsot
ec0fc14a22
miniscript: remove P2WSH-specific part of GetStackSize doc comment 2023-10-08 02:43:27 +02:00
Antoine Poinsot
117927bd5f
miniscript: have a custom Node destructor
To avoid recursive calls in shared_ptr's destructor that could lead to a
stack overflow.
2023-10-08 02:43:26 +02:00
Antoine Poinsot
4f473ea515
script/sign: Miniscript support in Tapscript
We make the Satisfier a base in which to store the common methods
between the Tapscript and P2WSH satisfier, and from which they both
inherit.

A field is added to SignatureData to be able to satisfy pkh() under
Tapscript context (to get the pubkey hash preimage) without wallet data.
For instance in `finalizepsbt` RPC. See also the next commits for a
functional test that exercises this.
2023-10-08 02:43:24 +02:00
Antoine Poinsot
febe2abc0e
MOVEONLY: script/sign: move Satisfier declaration above Tapscript signing
We'll need the Miniscript satisfier for Tapscript too.
2023-10-08 02:43:23 +02:00
Antoine Poinsot
8571b89a7f
descriptor: parse Miniscript expressions within Taproot descriptors 2023-10-08 02:43:22 +02:00
Antoine Poinsot
8ff9489422
descriptor: Tapscript-specific Miniscript key serialization / parsing
64-hex-characters public keys are valid in Miniscript key expressions
within a Tapscript context.

Keys under a Tapscript context always serialize as 32-bytes x-only
public keys (and that's what get hashed by OP_HASH160 on the stack too).
2023-10-08 02:43:22 +02:00
Antoine Poinsot
5e76f3f0dd
fuzz: miniscript: higher sensitivity for max stack size limit under Tapscript
In order to exacerbate a mistake in the stack size tracking logic,
sometimes pad the witness to make the script execute at the brink of the
stack size limit. This way if the stack size is underestimated for a
script it would immediately fail `VerifyScript`.
2023-10-08 02:43:21 +02:00
Antoine Poinsot
6f529cbaaf
qa: test Miniscript max stack size tracking 2023-10-08 02:43:21 +02:00
Antoine Poinsot
770ba5b519
miniscript: check maximum stack size during execution
Under Tapscript, due to the lifting of some standardness and consensus
limits, scripts can now run into the maximum stack size during
execution. Any Miniscript that may hit the limit on any of its spending
paths must be marked as unsafe.

Co-Authored-By: Pieter Wuille <pieter@wuille.net>
2023-10-08 02:43:20 +02:00
Antoine Poinsot
574523dbe0
fuzz: adapt Miniscript targets to Tapscript
We introduce another global that dictates the script context under which
to operate when running the target.

For miniscript_script, just consume another byte to set the context.
This should only affect existing seeds to the extent they contain a
CHECKMULTISIG. However it would not invalidate them entirely as they may
contain a NUMEQUAL or a CHECKSIGADD, and this still exercises a bit of
the parser.

For miniscript_string, reduce the string size by one byte and use the
last byte to determine the context. This is the change that i think
would invalidate the lowest number of existing seeds.

For miniscript_stable, we don't want to invalidate any seed. Instead of
creating a new miniscript_stable_tapscript, simply run the target once
for P2WSH and once for Tapscript (with the same seed).

For miniscript_smart, consume one byte before generating a pseudo-random
node to set the context. We have less regard for seed stability for this
target anyways.
2023-10-08 02:43:20 +02:00
Antoine Poinsot
84623722ef
qa: Tapscript-Miniscript unit tests
Adapt the test data and the parsing context to support x-only keys.
Adapt the Test() helper to test existing cases under both Tapscript and
P2WSH context, asserting what needs to be valid or not in each.
Finally, add more cases that exercise the logic that was added in the
previous commits (multi_a, different resource checks and keys
serialization under Tapscript, different properties for 'd:' fragment,
..).
2023-10-08 02:43:19 +02:00
Antoine Poinsot
fcb6f13f44
pubkey: introduce a GetEvenCorrespondingCPubKey helper
We'll need to get a compressed key out of an x-only one in other places.
Avoid duplicating the code.
2023-10-08 02:43:19 +02:00
Antoine Poinsot
ce8845f5dd
miniscript: account for keys as being 32 bytes under Taproot context 2023-10-08 02:43:18 +02:00
Antoine Poinsot
f4f978d38e
miniscript: adapt resources checks depending on context
Under Tapscript, there is:
- No limit on the number of OPs
- No limit on the script size, it's implicitly limited by the maximum
  (standard) transaction size.
- No standardness limit on the number of stack items, it's limited by
  the consensus MAX_STACK_SIZE. This requires tracking the maximum stack
  size at all times during script execution, which will be tackled in
  its own commit.

In order to avoid any Miniscript that would not be spendable by a
standard transaction because of the size of the witness, we limit the
script size under Tapscript to the maximum standard transaction size
minus the maximum possible witness and Taproot control block sizes. Note
this is a conservative limit but it still allows for scripts more than a
hundred times larger than under P2WSH.
2023-10-08 02:43:17 +02:00
Antoine Poinsot
9cb4c68b89
serialize: make GetSizeOfCompactSize constexpr 2023-10-08 02:43:17 +02:00
Antoine Poinsot
892436c7d5
miniscript: sanity asserts context in ComputeType 2023-10-08 02:43:16 +02:00
Antoine Poinsot
e5aaa3d77a
miniscript: make 'd:' have the 'u' property under Tapscript context
In Tapscript MINIMALIF is a consensus rule, so we can rely on the fact
that the `DUP IF [X] ENDIF` will always put an exact 1 on the stack upon
satisfaction.
2023-10-08 02:43:16 +02:00
Antoine Poinsot
687a0b0fa5
miniscript: introduce a multi_a fragment
It is the equivalent of multi() but for Tapscript, using CHECKSIGADD
instead of CHECKMULTISIG.

It shares the same properties as multi() but for 'n', since a threshold
multi_a() may have an empty vector as the top element of its
satisfaction. It could also have the 'o' property when it only has a
single key, but in this case a 'pk()' is always preferable anyways.
2023-10-08 02:43:15 +02:00
Antoine Poinsot
9164c2eca1
miniscript: restrict multi() usage to P2WSH context
CHECKMULTISIG is disabled for Tapscript. Instead, we'll introduce
a multi_a() fragment with the same semantic as multi().
2023-10-08 02:43:15 +02:00
Antoine Poinsot
91b4db8590
miniscript: store the script context within the Node structure
Some checks will be different depending on the script context (for
instance the maximum script size).
2023-10-08 02:43:14 +02:00
Antoine Poinsot
c3738d0344
miniscript: introduce a MsContext() helper to contexts
We are going to introduce Tapscript support in Miniscript, for which
some of Miniscript rules and properties change (new or modified
fragments, different typing rules, different resources consumption, ..).
2023-10-08 02:43:14 +02:00
Antoine Poinsot
bba9340a94
miniscript: don't anticipate signature presence in CalcStackSize()
It's true that for any public key there'll be a signature check in a
valid Miniscript. The code would previously, when computing the size of
a satisfaction, account for the signature when it sees a public key
push. Instead, account for it when it is required (ie when encountering
the `c:` wrapper). This has two benefits:
- Allows to accurately compute the net effect of a fragment on the stack
  size. This is necessary to track the size of the stack during the
  execution of a Script.
- It also just makes more sense, making the code more accessible to
  future contributors.
2023-10-08 02:43:13 +02:00
Antoine Poinsot
a3793f2d1a
miniscript: add a missing dup key check bypass in Parse()
This was calling the wrong constructor.
2023-10-08 02:43:13 +02:00
Hennadii Stepanov
d2b8c5e123
Merge bitcoin-core/gui#764: Remove legacy wallet creation
b442580ed2 gui: remove legacy wallet creation (furszy)

Pull request description:

  Fixes #763

  Preventing users from creating a legacy wallet prior to its deprecation in the upcoming releases.

  Note:
  This is still available using the `createwallet` RPC command.

  Future Note:
  Would be nice to re-write this modal as a wizard. And improve the design.

  <details><summary> Pre-Changes Screenshot </summary>
  <img width="611" alt="Screenshot 2023-10-06 at 11 30 14" src="https://github.com/bitcoin-core/gui/assets/5377650/ca10c97d-46e8-4aed-82da-068f2afbe25c">
  </details>

  <details><summary> Post-Changes  Screenshot </summary>
  <img width="729" alt="Screenshot 2023-10-06 at 11 32 58" src="https://github.com/bitcoin-core/gui/assets/5377650/f6bdcb57-646a-43d8-86a7-476e3cca683f">
  </details>

ACKs for top commit:
  achow101:
    ACK b442580ed2
  hebasto:
    re-ACK b442580ed2
  pablomartin4btc:
    tACK b442580ed2

Tree-SHA512: f5d26ffbb0962648b9edf273b325e89425a318e136df26a26acb21b88730fd7d6499c68a705680539dc1b40862fbf413a1e0c8572436a0cfc665e2d08a3cf97d
2023-10-07 11:53:16 +01:00
furszy
b442580ed2
gui: remove legacy wallet creation 2023-10-06 17:20:54 -03:00
Fabian Jahr
5d227a6862
rpc: Use Ensure(Any)Chainman in assumeutxo related RPCs 2023-10-06 19:43:32 +02:00
Fabian Jahr
710e5db61b
doc: Drop references to assumevalid in assumeutxo docs 2023-10-06 19:43:32 +02:00
Fabian Jahr
a482f86779
chain: Rename HaveTxsDownloaded to HaveNumChainTxs
Co-authored-by: MarcoFalke <falke.marco@gmail.com>
2023-10-06 19:43:32 +02:00
Fabian Jahr
82e48d20f1
blockstorage: Let FlushChainstateBlockFile return true in case of missing cursor
Co-authored-by: Ryan Ofsky <ryan@ofsky.org>
2023-10-06 19:43:32 +02:00
Fabian Jahr
73700fb554
validation, test: Improve and document nChainTx check for testability
Co-authored-by: Ryan Ofsky <ryan@ofsky.org>
2023-10-06 19:43:31 +02:00
Fabian Jahr
2c9354facb
doc: Add snapshot chainstate removal warning to reindexing documentation 2023-10-06 19:43:29 +02:00
Fabian Jahr
a47fbe7d49
doc: Add and edit some comments around assumeutxo
Co-authored-by: Ryan Ofsky <ryan@ofsky.org>
2023-10-06 18:12:31 +02:00
Fabian Jahr
0a39b8cbd8
validation: remove unused mempool param in DetectSnapshotChainstate 2023-10-06 18:11:24 +02:00
Andrew Chow
54bdb6e074
Merge bitcoin/bitcoin#27609: rpc: allow submitpackage to be called outside of regtest
5b878be742 [doc] add release note for submitpackage (glozow)
7a9bb2a2a5 [rpc] allow submitpackage to be called outside of regtest (glozow)
5b9087a9a7 [rpc] require package to be a tree in submitpackage (glozow)
e32ba1599c [txpackages] IsChildWithParentsTree() (glozow)
b4f28cc345 [doc] parent pay for child in aggregate CheckFeeRate (glozow)

Pull request description:

  Permit (restricted topology) submitpackage RPC outside of regtest. Suggested in https://github.com/bitcoin/bitcoin/pull/26933#issuecomment-1510851570

  This RPC should be safe but still experimental - interface may change, not all features (e.g. package RBF) are implemented, etc. If a miner wants to expose this to people, they can effectively use "package relay" before the p2p changes are implemented. However, please note **this is not package relay**; transactions submitted this way will not relay to other nodes if the feerates are below their mempool min fee. Users should put this behind some kind of rate limit or permissions.

ACKs for top commit:
  instagibbs:
    ACK 5b878be742
  achow101:
    ACK 5b878be742
  dergoegge:
    Code review ACK 5b878be742
  ajtowns:
    ACK 5b878be742
  ariard:
    Code Review ACK  5b878be742. Though didn’t manually test the PR.

Tree-SHA512: 610365c0b2ffcccd55dedd1151879c82de1027e3319712bcb11d54f2467afaae4d05dca5f4b25f03354c80845fef538d3938b958174dda8b14c10670537a6524
2023-10-05 19:08:19 -04:00
Andrew Chow
cf553e3ab7
Merge bitcoin/bitcoin#28597: wallet: No BDB creation, unless -deprecatedrpc=create_bdb
fa071aeb61 wallet: No BDB creation, unless -deprecatedrpc=create_bdb (MarcoFalke)

Pull request description:

  With BDB being removed soon, it seems confusing and harmful to allow users to create fresh BDB wallets going forward, as it would load them with an additional burden of having to migrate them soon after.

  Also, it would be good to allow for one release for test (and external) scripts to adapt.

  Fix all issues by introducing the `-deprecatedrpc=create_bdb` setting.

ACKs for top commit:
  Sjors:
    tACK fa071aeb61
  achow101:
    ACK fa071aeb61
  furszy:
    utACK fa071aeb

Tree-SHA512: 37a4c3e4ba659e0ebe2382e71d9c80e42a895d9ad743f5dda7c110fbbb7d2a36f46769982552a9ac0c3a57203379ef164be97aa8033eb7674d6b4da030ba8f9b
2023-10-05 15:35:54 -04:00
Andrew Chow
0b2c93bc56
Merge bitcoin/bitcoin#28590: assumeutxo: change getchainstates RPC to return a list of chainstates
a9ef702a87 assumeutxo: change getchainstates RPC to return a list of chainstates (Ryan Ofsky)

Pull request description:

  Current `getchainstates` RPC returns "normal" and "snapshot" fields which are not ideal because it requires new "normal" and "snapshot" terms to be defined, and the definitions are not really consistent with internal code. (In the RPC interface, the "snapshot" chainstate becomes the "normal" chainstate after it is validated, while in internal code there is no "normal chainstate" and the "snapshot chainstate" is still called that temporarily after it is validated).

  The current `getchainstates` RPC is also awkward to use if you to want information about the most-work chainstate, because you have to look at the "snapshot" field if it exists, and otherwise fall back to the "normal" field.

  Fix these issues by having `getchainstates` just return a flat list of chainstates ordered by work, and adding a new chainstate "validated" field alongside the existing "snapshot_blockhash" field so it is explicit if a chainstate was originally loaded from a snapshot, and whether the snapshot has been validated.

  This change was motivated by comment thread in https://github.com/bitcoin/bitcoin/pull/28562#discussion_r1344154808

ACKs for top commit:
  Sjors:
    re-ACK a9ef702a87
  jamesob:
    re-ACK a9ef702
  achow101:
    ACK a9ef702a87

Tree-SHA512: b364e2e96675fb7beaaee60c4dff4b69e6bc2d8a30dea1ba094265633d1cddf9dbf1c5ce20c07d6e23222cf1e92a195acf6227e4901f3962e81a1e53a43490aa
2023-10-05 14:19:34 -04:00
Andrew Chow
6e5cf8e953
Merge bitcoin/bitcoin#28587: descriptors: disallow hybrid public keys
c1e6c542af descriptors: disallow hybrid public keys (Pieter Wuille)

Pull request description:

  Fixes #28511

  The descriptor documentation (`doc/descriptors.md`) and [BIP380](https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki) explicitly require that hex-encoded public keys start with 02 or 03 (compressed) or 04 (uncompressed). However, the current parsing/inference code permit 06 and 07 (hybrid) encoding as well. Fix this.

ACKs for top commit:
  darosior:
    ACK c1e6c542af
  achow101:
    ACK c1e6c542af

Tree-SHA512: 23b674fb420619b2536d12da10008bb87cf7bc0333ec59e618c0d02c3574b468cc71248475ece37f76658d743ef51e68566948e903bca79fda5f7d75416fea4d
2023-10-05 11:58:07 -04:00
MarcoFalke
fa071aeb61
wallet: No BDB creation, unless -deprecatedrpc=create_bdb 2023-10-05 15:47:44 +02:00
Ryan Ofsky
a9ef702a87 assumeutxo: change getchainstates RPC to return a list of chainstates
Current getchainstates RPC returns "normal" and "snapshot" fields which are not
ideal because it requires new "normal" and "snapshot" terms to be defined, and
the definitions are not really consistent with internal code. (In the RPC
interface, the "snapshot" chainstate becomes the "normal" chainstate after it
is validated, while in internal code there is no "normal chainstate" and the
"snapshot chainstate" is still called that temporarily after it is validated).

The current getchainstatees RPC is also awkward to use if you to want
information about the most-work chainstate because you have to look at the
"snapshot" field if it exists, and otherwise fall back to the "normal" field.

Fix these issues by having getchainstates just return a flat list of
chainstates ordered by work, and adding new chainstate "validated" field
alongside the existing "snapshot_blockhash" so it is explicit if a chainstate
was originally loaded from a snapshot, and whether the snapshot has been
validated.
2023-10-05 09:41:43 -04:00
fanquake
52c6904c78
Merge bitcoin/bitcoin#28558: Make PeerManager own a FastRandomContext
4cafe9f176 [test] Make PeerManager's rng deterministic in tests (dergoegge)
fecec3e1c6 [net processing] FeeFilterRounder doesn't own a FastRandomContext (dergoegge)
47520ed209 [net processing] Make fee filter rounder non-global (dergoegge)
77506f4ac6 [net processing] Addr shuffle uses PeerManager's rng (dergoegge)
a648dd79e5 [net processing] PushAddress uses PeerManager's rng (dergoegge)
87c706713e [net processing] PeerManager holds a FastRandomContext (dergoegge)

Pull request description:

  This lets us avoid some non-determinism in tests (also see #28537).

ACKs for top commit:
  MarcoFalke:
    re-ACK 4cafe9f176  🕗
  glozow:
    concept && light code review ACK 4cafe9f176

Tree-SHA512: 3c18700773d0bc547ccb6442c41567e6f26b0b50fab5b79620da417ec91b9c0ae1395d15258da3aa4a91447b8ce560145dd135e39fbbd0610749e528e665b111
2023-10-05 14:06:39 +01:00
fanquake
b2ede22395
headerssync: update params for 26.x 2023-10-05 11:36:03 +01:00
fanquake
f12f92b813
kernel: update m_assumed_* chain params for 26.x 2023-10-05 11:29:42 +01:00
fanquake
a8c2e5e556
kernel: update chainTxData for 26.x 2023-10-05 11:29:41 +01:00
fanquake
a9d070a6f8
kernel: update nMinimumChainWork & defaultAssumeValid for 26.x 2023-10-05 11:29:41 +01:00
fanquake
2eacc61ad7
Merge bitcoin/bitcoin#25970: Add headerssync tuning parameters optimization script to repo
3d420d8f28 Add instructions for headerssync-params.py to release-process.md (Pieter Wuille)
53d7d35b58 Update parameters in headerssync.cpp (Pieter Wuille)
7899402cff Add headerssync-params.py script to the repository (Pieter Wuille)

Pull request description:

  Builds upon #25946, as it incorporates changes based on the selected values there.

  This adds the headerssync tuning parameters optimization script from https://gist.github.com/sipa/016ae445c132cdf65a2791534dfb7ae1 to the repository, updates the parameters based on its output, and adds release process instructions for doing this update in the future.

  A few considerations:
  * It would be a bit cleaner to have these parameters be part of `CChainParams`, but due to the nature of the approach, it really only applies to chains with unforgeable proof-of-work, which we really can only reasonably expect from mainnet, so I think it's fine to keep them local to `headerssync.cpp`. Keeping them as compile-time evaluatable constants also has a (likely negligible) performance impact (avoiding runtime modulo operations).
  * If we want to make sure the chainparams and headerssync params don't go out of date, it could be possible to run the script in CI, and and possibly even have the parameters be generated automatically at build time. I think that's overkill for how unfrequently these need to change, and running the script has non-trivial cost (~minutes in the normal python interpreter).
  * A viable alternative is just leaving this out-of-repo entirely, and just do ad-hoc updating from time to time. Having it in the repo and release notes does make sure it's not forgotten, though adds a cost to contributors/maintainers who follow the process.

ACKs for top commit:
  ajtowns:
    reACK 3d420d8f28

Tree-SHA512: 03188301c20423c72c1cbd008ccce89b93e2898edcbeecc561b2928a0d64e9a829ab0744dc3b017c23de8b02f3c107ae31e694302d3931f4dc3540e184de1963
2023-10-05 11:28:29 +01:00