💬 sipa commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1669281468)
Fixed.
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1669281468)
Fixed.
💬 sipa commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1669282068)
I've added a short comment to the docstring of the function instead.
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1669282068)
I've added a short comment to the docstring of the function instead.
💬 sipa commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1669283836)
Done, good idea. Avoiding a separate copy `m_todo` in `Linearize` forced me to rewrite some of the code, which turned out to simplify the LIMO logic slightly.
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1669283836)
Done, good idea. Avoiding a separate copy `m_todo` in `Linearize` forced me to rewrite some of the code, which turned out to simplify the LIMO logic slightly.
💬 sipa commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1669288946)
@glozow Indeed. Even if this function was changed to return an explicit `optimal`, it would remain quite possible that it returns the optimal without *knowing* it's optimal (because it's possible that the `best` passed in for example was already optimal, but it requires a ton of iterations to exhaust the search space to prove nothing better exists).
@instagibbs Well I think we may want to cache in the mempool clusters whether or not the linearization for them is known to be optimal too, so th
...
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1669288946)
@glozow Indeed. Even if this function was changed to return an explicit `optimal`, it would remain quite possible that it returns the optimal without *knowing* it's optimal (because it's possible that the `best` passed in for example was already optimal, but it requires a ton of iterations to exhaust the search space to prove nothing better exists).
@instagibbs Well I think we may want to cache in the mempool clusters whether or not the linearization for them is known to be optimal too, so th
...
💬 instagibbs commented on pull request "policy: Add PayToAnchor(P2A), `OP_TRUE <0x4e73>` as a standard output script for spending":
(https://github.com/bitcoin/bitcoin/pull/30352#issuecomment-2215368575)
@achow101 `wallet_backwards_compatibility.py --legacy` failure seems spurious? can you check?
(https://github.com/bitcoin/bitcoin/pull/30352#issuecomment-2215368575)
@achow101 `wallet_backwards_compatibility.py --legacy` failure seems spurious? can you check?
🤔 stickies-v reviewed a pull request: "fuzz: bound some miniscript operations to avoid fuzz timeouts"
(https://github.com/bitcoin/bitcoin/pull/30197#pullrequestreview-2163854874)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/30197#pullrequestreview-2163854874)
Concept ACK
💬 stickies-v commented on pull request "fuzz: bound some miniscript operations to avoid fuzz timeouts":
(https://github.com/bitcoin/bitcoin/pull/30197#discussion_r1668972900)
It's not obvious to me why we need/prefer to iterate in reverse, here?
(https://github.com/bitcoin/bitcoin/pull/30197#discussion_r1668972900)
It's not obvious to me why we need/prefer to iterate in reverse, here?
💬 stickies-v commented on pull request "fuzz: bound some miniscript operations to avoid fuzz timeouts":
(https://github.com/bitcoin/bitcoin/pull/30197#discussion_r1668971771)
note: with #30263 merged, you can now use `std::reverse::views` again (see #28687)
<details>
<summary>git diff on 178a1da9c4</summary>
```diff
diff --git a/src/test/fuzz/util/descriptor.cpp b/src/test/fuzz/util/descriptor.cpp
index 1ead54f254..d0ed6ee94c 100644
--- a/src/test/fuzz/util/descriptor.cpp
+++ b/src/test/fuzz/util/descriptor.cpp
@@ -3,8 +3,8 @@
// file COPYING or http://www.opensource.org/licenses/mit-license.php.
#include <test/fuzz/util/descriptor.h>
-#include <r
...
(https://github.com/bitcoin/bitcoin/pull/30197#discussion_r1668971771)
note: with #30263 merged, you can now use `std::reverse::views` again (see #28687)
<details>
<summary>git diff on 178a1da9c4</summary>
```diff
diff --git a/src/test/fuzz/util/descriptor.cpp b/src/test/fuzz/util/descriptor.cpp
index 1ead54f254..d0ed6ee94c 100644
--- a/src/test/fuzz/util/descriptor.cpp
+++ b/src/test/fuzz/util/descriptor.cpp
@@ -3,8 +3,8 @@
// file COPYING or http://www.opensource.org/licenses/mit-license.php.
#include <test/fuzz/util/descriptor.h>
-#include <r
...
💬 stickies-v commented on pull request "fuzz: bound some miniscript operations to avoid fuzz timeouts":
(https://github.com/bitcoin/bitcoin/pull/30197#discussion_r1669371925)
Is this correct? I'd expect something like:
<details>
<summary>git diff on 178a1da9c4</summary>
```diff
diff --git a/src/test/fuzz/util/descriptor.cpp b/src/test/fuzz/util/descriptor.cpp
index 1ead54f254..434df93994 100644
--- a/src/test/fuzz/util/descriptor.cpp
+++ b/src/test/fuzz/util/descriptor.cpp
@@ -108,12 +108,10 @@ bool HasTooManyWrappers(const FuzzBufferType& buff, const int max_wrappers)
auto count{0};
// We iterate in reverse order to start counting when we enc
...
(https://github.com/bitcoin/bitcoin/pull/30197#discussion_r1669371925)
Is this correct? I'd expect something like:
<details>
<summary>git diff on 178a1da9c4</summary>
```diff
diff --git a/src/test/fuzz/util/descriptor.cpp b/src/test/fuzz/util/descriptor.cpp
index 1ead54f254..434df93994 100644
--- a/src/test/fuzz/util/descriptor.cpp
+++ b/src/test/fuzz/util/descriptor.cpp
@@ -108,12 +108,10 @@ bool HasTooManyWrappers(const FuzzBufferType& buff, const int max_wrappers)
auto count{0};
// We iterate in reverse order to start counting when we enc
...
💬 stickies-v commented on pull request "fuzz: bound some miniscript operations to avoid fuzz timeouts":
(https://github.com/bitcoin/bitcoin/pull/30197#discussion_r1668978835)
nit: `HasTooManySubFrags` seems like a more accurate name?
```suggestion
bool HasTooManySubFrags(const FuzzBufferType& buff, const int max_subs = MAX_SUBS);
```
(https://github.com/bitcoin/bitcoin/pull/30197#discussion_r1668978835)
nit: `HasTooManySubFrags` seems like a more accurate name?
```suggestion
bool HasTooManySubFrags(const FuzzBufferType& buff, const int max_subs = MAX_SUBS);
```
💬 andrewtoth commented on pull request "Don't empty dbcache on prune flushes: >30% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1669602373)
Done.
(https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1669602373)
Done.
💬 andrewtoth commented on pull request "Don't empty dbcache on prune flushes: >30% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/28280#issuecomment-2216328752)
Added a `CoinsViewCacheCursor` struct to encapsulate the iteration of the linked list when passed up to `BatchWrite`.
(https://github.com/bitcoin/bitcoin/pull/28280#issuecomment-2216328752)
Added a `CoinsViewCacheCursor` struct to encapsulate the iteration of the linked list when passed up to `BatchWrite`.
📝 mzumsande opened a pull request: "rpc, rest: Improve getblock error when only header is available"
(https://github.com/bitcoin/bitcoin/pull/30410)
Fixes #20978
If a block was pruned, `getblock` already returns a specific error: "Block not available (pruned data)".
But if we haven't received the full block yet (e.g. in a race with block downloading after a new block was received headers-first, or during IBD) we just return an unspecific "Block not found on disk" error and log
`ERROR: ReadBlockFromDisk: OpenBlockFile failed for FlatFilePos(nFile=-1, nPos=0) `
which suggest something went wrong even though this is a completely normal an
...
(https://github.com/bitcoin/bitcoin/pull/30410)
Fixes #20978
If a block was pruned, `getblock` already returns a specific error: "Block not available (pruned data)".
But if we haven't received the full block yet (e.g. in a race with block downloading after a new block was received headers-first, or during IBD) we just return an unspecific "Block not found on disk" error and log
`ERROR: ReadBlockFromDisk: OpenBlockFile failed for FlatFilePos(nFile=-1, nPos=0) `
which suggest something went wrong even though this is a completely normal an
...
💬 mzumsande commented on issue "RPC `getblock` resulted in 500 and ReadBlockFromDisk: OpenBlockFile failed for FlatFilePos(nFile=-1, nPos=0)":
(https://github.com/bitcoin/bitcoin/issues/20978#issuecomment-2216427835)
see #30410
(https://github.com/bitcoin/bitcoin/issues/20978#issuecomment-2216427835)
see #30410
💬 TheCharlatan commented on pull request "rpc, rest: Improve getblock error when only header is available":
(https://github.com/bitcoin/bitcoin/pull/30410#issuecomment-2216485352)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/30410#issuecomment-2216485352)
Concept ACK
💬 melvincarvalho commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2216495066)
I've been running this for about a month, observing the blocks closely. For the most part I have found it to work really well. Much easier to work with than testnet3. There is a strange occurrence that happens, not sure I would call it an "attack" but someone is shifting timestamps by exactly 20 minutes 1 second. Sometimes several times in a row. Generally it is up to 6 blocks at most. I am not sure what the exact trigger is, but it doesnt happen too often.
I've been running this for about a month, observing the blocks closely. For the most part I have found it to work really well. Much easier to work with than testnet3. There is a strange occurrence that happens, not sure I would call it an "attack" but someone is shifting timestamps by exactly 20 minutes 1 second. Sometimes several times in a row. Generally it is up to 6 blocks at most. I am not sure what the exact trigger is, but it doesnt happen too often.
![image](https://github.com/b
...
📝 sidhujag opened a pull request: "Governanceupdate"
(https://github.com/bitcoin/bitcoin/pull/30411)
(https://github.com/bitcoin/bitcoin/pull/30411)
✅ sidhujag closed a pull request: "Governanceupdate"
(https://github.com/bitcoin/bitcoin/pull/30411)
(https://github.com/bitcoin/bitcoin/pull/30411)
💬 Sjors commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2216695796)
> someone is shifting timestamps by exactly 20 minutes 1 second
This lets them produce blocks at difficulty 1, i.e. with a CPU instead of an ASIC.
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2216695796)
> someone is shifting timestamps by exactly 20 minutes 1 second
This lets them produce blocks at difficulty 1, i.e. with a CPU instead of an ASIC.
💬 jsarenik commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2216737254)
> > someone is shifting timestamps by exactly 20 minutes 1 second
>
> This lets them produce blocks at difficulty 1, i.e. with a CPU instead of an ASIC.
@Sjors, how can I do that, too? What tools could be used to produce a block header with a particular shifted timestamp so that in the next step one could use `bitcoin-util grind` to perform proof of work on hex header string (i.e. CPU-mine such a block)?
What conditions need to be met to cause a blockchain reorg this way?
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2216737254)
> > someone is shifting timestamps by exactly 20 minutes 1 second
>
> This lets them produce blocks at difficulty 1, i.e. with a CPU instead of an ASIC.
@Sjors, how can I do that, too? What tools could be used to produce a block header with a particular shifted timestamp so that in the next step one could use `bitcoin-util grind` to perform proof of work on hex header string (i.e. CPU-mine such a block)?
What conditions need to be met to cause a blockchain reorg this way?