💬 glozow commented on pull request "MiniMiner: use FeeFrac in AncestorFeerateComparator":
(https://github.com/bitcoin/bitcoin/pull/30412#discussion_r1670835969)
done
(https://github.com/bitcoin/bitcoin/pull/30412#discussion_r1670835969)
done
💬 dergoegge commented on pull request "Stratum v2 Template Provider (take 3)":
(https://github.com/bitcoin/bitcoin/pull/29432#issuecomment-2218139440)
> And compared to Bitcoin Core no one runs these things
Because not everyone needs to run these things but if they want to they can. Cramming everything into one software project is not sustainable.
> Indeed, it is absolutely a maintenance burden, but we've seen time and time and time again - nearly every project in Bitcoin outside of Bitcoin Core has not been sustainable and eventually turns into abandonware.
If it would end up unmaintained outside of Bitcoin Core, then it'd also end u
...
(https://github.com/bitcoin/bitcoin/pull/29432#issuecomment-2218139440)
> And compared to Bitcoin Core no one runs these things
Because not everyone needs to run these things but if they want to they can. Cramming everything into one software project is not sustainable.
> Indeed, it is absolutely a maintenance burden, but we've seen time and time and time again - nearly every project in Bitcoin outside of Bitcoin Core has not been sustainable and eventually turns into abandonware.
If it would end up unmaintained outside of Bitcoin Core, then it'd also end u
...
⚠️ VojtechMyslivec opened an issue: "Send RPC calls performance"
(https://github.com/bitcoin/bitcoin/issues/30416)
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Current behaviour
I want to report performance changes of `sendmany` and `sendtoaddress` RPC calls.
We use fresh-new wallet for more than an year. There are 24 descriptors in the wallet from which 12 were imported from about a month older wallet. We generated circa 300 k addresses from these imported descriptors and hundreds of addresses from the new ones. We had send about 1500 transactions from this wa
...
(https://github.com/bitcoin/bitcoin/issues/30416)
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Current behaviour
I want to report performance changes of `sendmany` and `sendtoaddress` RPC calls.
We use fresh-new wallet for more than an year. There are 24 descriptors in the wallet from which 12 were imported from about a month older wallet. We generated circa 300 k addresses from these imported descriptors and hundreds of addresses from the new ones. We had send about 1500 transactions from this wa
...
💬 VojtechMyslivec commented on issue "Send RPC calls performance":
(https://github.com/bitcoin/bitcoin/issues/30416#issuecomment-2218170930)
#26008 may relate? I am not sure if it was included in 27.0 release
(https://github.com/bitcoin/bitcoin/issues/30416#issuecomment-2218170930)
#26008 may relate? I am not sure if it was included in 27.0 release
📝 ryanofsky opened a pull request: "assumeutxo: Remove translated strings added in 30267"
(https://github.com/bitcoin/bitcoin/pull/30417)
maflcko pointed out in https://github.com/bitcoin/bitcoin/pull/30267#pullrequestreview-2155603386 that some error strings were being translated unneccessarily and incorrectly in #30267.
Switch them to untranslated for now. In the future if we add a GUI feature for loading snapshots, and it seems like it could be possible to trigger some of the errors, they could be translated at that point.
Also remove a newline in a thrown RPC exception.
(https://github.com/bitcoin/bitcoin/pull/30417)
maflcko pointed out in https://github.com/bitcoin/bitcoin/pull/30267#pullrequestreview-2155603386 that some error strings were being translated unneccessarily and incorrectly in #30267.
Switch them to untranslated for now. In the future if we add a GUI feature for loading snapshots, and it seems like it could be possible to trigger some of the errors, they could be translated at that point.
Also remove a newline in a thrown RPC exception.
💬 fanquake commented on pull request "assumeutxo: Remove translated strings added in 30267":
(https://github.com/bitcoin/bitcoin/pull/30417#issuecomment-2218224154)
This is also done in #30395.
(https://github.com/bitcoin/bitcoin/pull/30417#issuecomment-2218224154)
This is also done in #30395.
💬 ryanofsky commented on pull request "assumeutxo: Check snapshot base block is not in invalid chain":
(https://github.com/bitcoin/bitcoin/pull/30267#discussion_r1670879567)
re: https://github.com/bitcoin/bitcoin/pull/30267#discussion_r1663611194
> What is the point of translating this message when the translation is discarded? Seems wasteful of translator's time, no?
Removed translation in #30417
(https://github.com/bitcoin/bitcoin/pull/30267#discussion_r1670879567)
re: https://github.com/bitcoin/bitcoin/pull/30267#discussion_r1663611194
> What is the point of translating this message when the translation is discarded? Seems wasteful of translator's time, no?
Removed translation in #30417
💬 ryanofsky commented on pull request "assumeutxo: Check snapshot base block is not in invalid chain":
(https://github.com/bitcoin/bitcoin/pull/30267#discussion_r1670880468)
re: https://github.com/bitcoin/bitcoin/pull/30267#discussion_r1663631973
> It is not possible to pass a raw c-string pointer to transifex for translation. Only string literals can be translated.
Fixed in #30417
(https://github.com/bitcoin/bitcoin/pull/30267#discussion_r1670880468)
re: https://github.com/bitcoin/bitcoin/pull/30267#discussion_r1663631973
> It is not possible to pass a raw c-string pointer to transifex for translation. Only string literals can be translated.
Fixed in #30417
💬 ryanofsky commented on pull request "assumeutxo: Check snapshot base block is not in invalid chain":
(https://github.com/bitcoin/bitcoin/pull/30267#discussion_r1670879771)
re: https://github.com/bitcoin/bitcoin/pull/30267#discussion_r1663647981
> Is the trailing newline needed? This would be the first `JSONRPCError` with a trailing newline.
Removed in #30417
(https://github.com/bitcoin/bitcoin/pull/30267#discussion_r1670879771)
re: https://github.com/bitcoin/bitcoin/pull/30267#discussion_r1663647981
> Is the trailing newline needed? This would be the first `JSONRPCError` with a trailing newline.
Removed in #30417
💬 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#discussion_r1670889699)
thanks, taken
(https://github.com/bitcoin/bitcoin/pull/30352#discussion_r1670889699)
thanks, taken
💬 instagibbs commented on pull request "#28984 package rbf followups":
(https://github.com/bitcoin/bitcoin/pull/30295#discussion_r1670908419)
removed
(https://github.com/bitcoin/bitcoin/pull/30295#discussion_r1670908419)
removed
💬 instagibbs commented on pull request "#28984 package rbf followups":
(https://github.com/bitcoin/bitcoin/pull/30295#discussion_r1670908464)
done
(https://github.com/bitcoin/bitcoin/pull/30295#discussion_r1670908464)
done
💬 instagibbs commented on pull request "#28984 package rbf followups":
(https://github.com/bitcoin/bitcoin/pull/30295#discussion_r1670908480)
done
(https://github.com/bitcoin/bitcoin/pull/30295#discussion_r1670908480)
done
💬 theStack commented on pull request "net: fix race condition in self-connect detection":
(https://github.com/bitcoin/bitcoin/pull/30394#issuecomment-2218275587)
@mzumsande: Good catch! With that in my mind, I see the following paths forward:
1. Queue outbound VERSION message immediately in `CConnman::OpenNetworkConnection` (as done in a previous version of this PR: https://github.com/theStack/bitcoin/tree/202407-p2p-fix_selfdetection_racecond_oldversion, extending the `NetEventsInterface` with a new `SendInitialMessages` method, called at the end)
2. Adapt the current state of this PR to only start processing messages of outbound peers after `m_outbou
...
(https://github.com/bitcoin/bitcoin/pull/30394#issuecomment-2218275587)
@mzumsande: Good catch! With that in my mind, I see the following paths forward:
1. Queue outbound VERSION message immediately in `CConnman::OpenNetworkConnection` (as done in a previous version of this PR: https://github.com/theStack/bitcoin/tree/202407-p2p-fix_selfdetection_racecond_oldversion, extending the `NetEventsInterface` with a new `SendInitialMessages` method, called at the end)
2. Adapt the current state of this PR to only start processing messages of outbound peers after `m_outbou
...
💬 dergoegge commented on pull request "net: fix race condition in self-connect detection":
(https://github.com/bitcoin/bitcoin/pull/30394#issuecomment-2218287690)
Option 2. seems the best to me.
(https://github.com/bitcoin/bitcoin/pull/30394#issuecomment-2218287690)
Option 2. seems the best to me.
💬 sipa commented on pull request "net: fix race condition in self-connect detection":
(https://github.com/bitcoin/bitcoin/pull/30394#issuecomment-2218293210)
I think (2) is a 1-line change: return immediately from `ProcessMessages` if no version message has been sent by us to the peer.
(https://github.com/bitcoin/bitcoin/pull/30394#issuecomment-2218293210)
I think (2) is a 1-line change: return immediately from `ProcessMessages` if no version message has been sent by us to the peer.
👍 ismaelsadeeq approved a pull request: "MiniMiner: use FeeFrac in AncestorFeerateComparator"
(https://github.com/bitcoin/bitcoin/pull/30412#pullrequestreview-2167005183)
Tested ACK 09370529fb9f6d06f6d16bdb1fb336f7a265d8ba
(https://github.com/bitcoin/bitcoin/pull/30412#pullrequestreview-2167005183)
Tested ACK 09370529fb9f6d06f6d16bdb1fb336f7a265d8ba
💬 ryanofsky commented on pull request "Stratum v2 Template Provider (take 3)":
(https://github.com/bitcoin/bitcoin/pull/29432#issuecomment-2218317900)
re: https://github.com/bitcoin/bitcoin/pull/29432#issuecomment-2211245443
> Yet another approach for said sidecar is to use IPC. It offers first class access to the node, e.g. via the newly added mining interface. It can probably automagically find a running Bitcoin Core process or spin one up. This would require more (review) progress in #10102 and additional tooling so external application can easily use IPC.
I don't actually think much in #10102 is needed, because the bulk of #10102 is
...
(https://github.com/bitcoin/bitcoin/pull/29432#issuecomment-2218317900)
re: https://github.com/bitcoin/bitcoin/pull/29432#issuecomment-2211245443
> Yet another approach for said sidecar is to use IPC. It offers first class access to the node, e.g. via the newly added mining interface. It can probably automagically find a running Bitcoin Core process or spin one up. This would require more (review) progress in #10102 and additional tooling so external application can easily use IPC.
I don't actually think much in #10102 is needed, because the bulk of #10102 is
...
💬 garlonicon commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2218329966)
Well, I already shared a diff somewhere: https://bitcointalk.org/index.php?topic=5496494.msg64205870#msg64205870
I simply don't know a better way to compete with ASICs on testnets. Because testnet3 and testnet4 are the only networks I know of, where CPUs and ASICs can co-exist.
For example: if after 20 minutes, any block would be accepted, but at the same time, the real difficulty would be placed in the block header, then that kind of trick would be impossible, because ASICs would triviall
...
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2218329966)
Well, I already shared a diff somewhere: https://bitcointalk.org/index.php?topic=5496494.msg64205870#msg64205870
I simply don't know a better way to compete with ASICs on testnets. Because testnet3 and testnet4 are the only networks I know of, where CPUs and ASICs can co-exist.
For example: if after 20 minutes, any block would be accepted, but at the same time, the real difficulty would be placed in the block header, then that kind of trick would be impossible, because ASICs would triviall
...
💬 theStack commented on pull request "net: fix race condition in self-connect detection":
(https://github.com/bitcoin/bitcoin/pull/30394#issuecomment-2218330911)
> Option 2. seems the best to me.
> I think (2) is a 1-line change: return immediately from `ProcessMessages` if no version message has been sent by us to the peer.
Thanks for the quick feedback, done.
(https://github.com/bitcoin/bitcoin/pull/30394#issuecomment-2218330911)
> Option 2. seems the best to me.
> I think (2) is a 1-line change: return immediately from `ProcessMessages` if no version message has been sent by us to the peer.
Thanks for the quick feedback, done.