💬 sipa commented on issue "Method not found":
(https://github.com/bitcoin/bitcoin/issues/27617#issuecomment-1542347503)
@Jackwumingjie Did you recompile?
(https://github.com/bitcoin/bitcoin/issues/27617#issuecomment-1542347503)
@Jackwumingjie Did you recompile?
💬 jamesob commented on pull request "assumeutxo (2)":
(https://github.com/bitcoin/bitcoin/pull/27596#issuecomment-1542375384)
> What's your feeling on how important figuring out the fix for the pruning issue is at the moment? People don't consider it blocking https://github.com/bitcoin/bitcoin/pull/24008, right?
Right, pruning issues shouldn't block #24008 - those changes need to happen regardless of how we manage pruning with snapshots.
I'll reproduce/investigate the pruning issues over the coming days. But it's worth noting that @Sjors didn't see any regressions in pruning on this branch _before_ loading the sn
...
(https://github.com/bitcoin/bitcoin/pull/27596#issuecomment-1542375384)
> What's your feeling on how important figuring out the fix for the pruning issue is at the moment? People don't consider it blocking https://github.com/bitcoin/bitcoin/pull/24008, right?
Right, pruning issues shouldn't block #24008 - those changes need to happen regardless of how we manage pruning with snapshots.
I'll reproduce/investigate the pruning issues over the coming days. But it's worth noting that @Sjors didn't see any regressions in pruning on this branch _before_ loading the sn
...
💬 instagibbs commented on pull request "p2p: Avoid prematurely clearing download state for other peers":
(https://github.com/bitcoin/bitcoin/pull/27608#discussion_r1190051098)
Is this block required anymore now that `ProcessBlock` will call it for us?
(https://github.com/bitcoin/bitcoin/pull/27608#discussion_r1190051098)
Is this block required anymore now that `ProcessBlock` will call it for us?
⚠️ adastreamer opened an issue: "Keep it simple"
(https://github.com/bitcoin/bitcoin/issues/27618)
### Please describe the feature you'd like to see added.
Dear community,
On my opinion Bitcoin network should not contain anything except BTC transfer transactions. BTC network is absolutely organic and all economic rules are totally balanced - fee/rate/complexity.
All application-level business logic such as tokens and custom data, should be moved to shard/side-chains to keep the main network simple and light as possible. Great example - Lightning network, or the design of Polka/TON netw
...
(https://github.com/bitcoin/bitcoin/issues/27618)
### Please describe the feature you'd like to see added.
Dear community,
On my opinion Bitcoin network should not contain anything except BTC transfer transactions. BTC network is absolutely organic and all economic rules are totally balanced - fee/rate/complexity.
All application-level business logic such as tokens and custom data, should be moved to shard/side-chains to keep the main network simple and light as possible. Great example - Lightning network, or the design of Polka/TON netw
...
💬 jamesob commented on pull request "p2p: Avoid prematurely clearing download state for other peers":
(https://github.com/bitcoin/bitcoin/pull/27608#discussion_r1190059834)
"by another peer" reads fine to me?
(https://github.com/bitcoin/bitcoin/pull/27608#discussion_r1190059834)
"by another peer" reads fine to me?
✅ fanquake closed an issue: "Keep it simple"
(https://github.com/bitcoin/bitcoin/issues/27618)
(https://github.com/bitcoin/bitcoin/issues/27618)
💬 willcl-ark commented on issue "Keep it simple":
(https://github.com/bitcoin/bitcoin/issues/27618#issuecomment-1542389194)
@adastreamer This project's issue tracker is not the right place for this sort of discussion.
I'd recommend asking conceptual/theoretical questions like this either on the bitcoin-dev mailing list or on bitcoin.stackexchange.com.
(https://github.com/bitcoin/bitcoin/issues/27618#issuecomment-1542389194)
@adastreamer This project's issue tracker is not the right place for this sort of discussion.
I'd recommend asking conceptual/theoretical questions like this either on the bitcoin-dev mailing list or on bitcoin.stackexchange.com.
💬 instagibbs commented on pull request "p2p: Avoid prematurely clearing download state for other peers":
(https://github.com/bitcoin/bitcoin/pull/27608#discussion_r1190062712)
peer didn't request, WE requested that peer
(https://github.com/bitcoin/bitcoin/pull/27608#discussion_r1190062712)
peer didn't request, WE requested that peer
💬 willcl-ark commented on issue "Method not found":
(https://github.com/bitcoin/bitcoin/issues/27617#issuecomment-1542391942)
@Jackwumingjie now that you have the wallet compiled in the error message is telling you what to do to: i) either create a wallet (if you don't have one already) or ii) load a wallet (if you do have one).
If you run `bitcoin-cli help createwallet` or `bitcoin-cli help loadwallet` you will find more detailed instructions on how to use these RPCs.
Also see https://github.com/bitcoin/bitcoin/blob/master/doc/managing-wallets.md for more information.
(https://github.com/bitcoin/bitcoin/issues/27617#issuecomment-1542391942)
@Jackwumingjie now that you have the wallet compiled in the error message is telling you what to do to: i) either create a wallet (if you don't have one already) or ii) load a wallet (if you do have one).
If you run `bitcoin-cli help createwallet` or `bitcoin-cli help loadwallet` you will find more detailed instructions on how to use these RPCs.
Also see https://github.com/bitcoin/bitcoin/blob/master/doc/managing-wallets.md for more information.
💬 instagibbs commented on pull request "p2p: Avoid prematurely clearing download state for other peers":
(https://github.com/bitcoin/bitcoin/pull/27608#discussion_r1190063736)
ah right, suggested text is also ambiguous....
"Block was requested by us from another peer" ?
(https://github.com/bitcoin/bitcoin/pull/27608#discussion_r1190063736)
ah right, suggested text is also ambiguous....
"Block was requested by us from another peer" ?
💬 jamesob commented on pull request "assumeutxo (2)":
(https://github.com/bitcoin/bitcoin/pull/27596#issuecomment-1542394306)
Hm, for what it's worth, pruning is working as expected for me on this branch.

```
Every 2.0s: cat <(./src/bitcoin-cli -datadir=/home/james/tmp/bitcoin-au-testing getmempoolinfo) <( ./src/bitcoin-cli -datadir=/home/james/tmp/bitcoin-au-testing getchainstates)
...
(https://github.com/bitcoin/bitcoin/pull/27596#issuecomment-1542394306)
Hm, for what it's worth, pruning is working as expected for me on this branch.

```
Every 2.0s: cat <(./src/bitcoin-cli -datadir=/home/james/tmp/bitcoin-au-testing getmempoolinfo) <( ./src/bitcoin-cli -datadir=/home/james/tmp/bitcoin-au-testing getchainstates)
...
💬 glozow commented on pull request "Improve performance of p2p inv to send queues":
(https://github.com/bitcoin/bitcoin/pull/27610#discussion_r1190081684)
Could this increase the number of transactions we're announcing beyond `INVENTORY_MAX_RECENT_RELAY = 3500` so things fall out of `m_recently_announced_invs` (essentially what you said in https://github.com/bitcoin/bitcoin/pull/27602#discussion_r1189250200)?
Maybe we want to increase `INVENTORY_MAX_RECENT_RELAY`, e.g. equal to `MAX_PEER_TX_ANNOUNCEMENTS = 5000` (the max requesting coming from the receiver end if they're Bitcoin Core - imo it could make sense for these to be symmetrical)?
(https://github.com/bitcoin/bitcoin/pull/27610#discussion_r1190081684)
Could this increase the number of transactions we're announcing beyond `INVENTORY_MAX_RECENT_RELAY = 3500` so things fall out of `m_recently_announced_invs` (essentially what you said in https://github.com/bitcoin/bitcoin/pull/27602#discussion_r1189250200)?
Maybe we want to increase `INVENTORY_MAX_RECENT_RELAY`, e.g. equal to `MAX_PEER_TX_ANNOUNCEMENTS = 5000` (the max requesting coming from the receiver end if they're Bitcoin Core - imo it could make sense for these to be symmetrical)?
🤔 pinheadmz reviewed a pull request: "Improve performance of p2p inv to send queues"
(https://github.com/bitcoin/bitcoin/pull/27610#pullrequestreview-1420860416)
Concept ACK
A few questions below.
I have a non-debug mainnet node with a 100% `b-msghandler` thread. I'm going to deploy this branch today and monitor
(https://github.com/bitcoin/bitcoin/pull/27610#pullrequestreview-1420860416)
Concept ACK
A few questions below.
I have a non-debug mainnet node with a 100% `b-msghandler` thread. I'm going to deploy this branch today and monitor
💬 pinheadmz commented on pull request "Improve performance of p2p inv to send queues":
(https://github.com/bitcoin/bitcoin/pull/27610#discussion_r1190049503)
Why stop at 1000? If it's the same rationale could you use this constant?
https://github.com/bitcoin/bitcoin/blob/104eed116614996d9724f82d47e373ef420cd372/src/net_processing.cpp#L109-L110
(https://github.com/bitcoin/bitcoin/pull/27610#discussion_r1190049503)
Why stop at 1000? If it's the same rationale could you use this constant?
https://github.com/bitcoin/bitcoin/blob/104eed116614996d9724f82d47e373ef420cd372/src/net_processing.cpp#L109-L110
💬 pinheadmz commented on pull request "Improve performance of p2p inv to send queues":
(https://github.com/bitcoin/bitcoin/pull/27610#discussion_r1190081977)
Is there a reason why we can't ignore not-in-mempool txs before we even get to this point?
i.e. here:
https://github.com/bitcoin/bitcoin/blob/104eed116614996d9724f82d47e373ef420cd372/src/net_processing.cpp#L5671-L5673
(https://github.com/bitcoin/bitcoin/pull/27610#discussion_r1190081977)
Is there a reason why we can't ignore not-in-mempool txs before we even get to this point?
i.e. here:
https://github.com/bitcoin/bitcoin/blob/104eed116614996d9724f82d47e373ef420cd372/src/net_processing.cpp#L5671-L5673
💬 ryanofsky commented on pull request "refactor, kernel: Decouple ArgsManager from blockstorage":
(https://github.com/bitcoin/bitcoin/pull/27125#discussion_r1190097934)
In commit "zmq: Pass lambda to zmq's ZMQPublishRawBlockNotifier" (6247b3c5e3c9e70097243a85b3d883b279a473cc)
It looks like the lambda is taking a reference to the local `get_block_by_index` variable here, which doesn't seem right, since the variable will go out of scope before the lambda is called. So I think `&` should be dropped here.
Not totally sure though, since I would expect there to be problems in CI if there was a bug.
(https://github.com/bitcoin/bitcoin/pull/27125#discussion_r1190097934)
In commit "zmq: Pass lambda to zmq's ZMQPublishRawBlockNotifier" (6247b3c5e3c9e70097243a85b3d883b279a473cc)
It looks like the lambda is taking a reference to the local `get_block_by_index` variable here, which doesn't seem right, since the variable will go out of scope before the lambda is called. So I think `&` should be dropped here.
Not totally sure though, since I would expect there to be problems in CI if there was a bug.
💬 glozow commented on pull request "rpc: allow submitpackage to be called outside of regtest":
(https://github.com/bitcoin/bitcoin/pull/27609#discussion_r1190100674)
Fixed
(https://github.com/bitcoin/bitcoin/pull/27609#discussion_r1190100674)
Fixed
💬 glozow commented on pull request "rpc: allow submitpackage to be called outside of regtest":
(https://github.com/bitcoin/bitcoin/pull/27609#issuecomment-1542429830)
Added a release note and addressed https://github.com/bitcoin/bitcoin/pull/27609#discussion_r1190006006
(https://github.com/bitcoin/bitcoin/pull/27609#issuecomment-1542429830)
Added a release note and addressed https://github.com/bitcoin/bitcoin/pull/27609#discussion_r1190006006
💬 brandonpille commented on issue "rpc: Allow importing wallets by data instead of by filename":
(https://github.com/bitcoin/bitcoin/issues/27597#issuecomment-1542436043)
No not specifically. I was just wondering why there is an import_wallet rpc that accepts a filename where the file is on the system itself.
(https://github.com/bitcoin/bitcoin/issues/27597#issuecomment-1542436043)
No not specifically. I was just wondering why there is an import_wallet rpc that accepts a filename where the file is on the system itself.
💬 LarryRuane commented on pull request "add ryanofsky to trusted-keys":
(https://github.com/bitcoin/bitcoin/pull/27604#issuecomment-1542437622)
post-merge ACK
(https://github.com/bitcoin/bitcoin/pull/27604#issuecomment-1542437622)
post-merge ACK