💬 ariard commented on pull request "Add issuer-selected opt-in txn / pckg policy checks":
(https://github.com/bitcoin/bitcoin/pull/29448#issuecomment-1952864387)
> It's not really clear to me what you're trying to achieve in this PR - some kind of way for transactions to specify what their > ancestor/descendant limits are? There are no tests, the CI is failing, and a lot of the code comments are incorrect/irrelevant > to the adjacent lines.

Yeah some kind of way for transactions to specify what their ancestor / descendant / max weight / limits, in the hard limits of current mempool ones. I know no test and CI failing, it’s just proof-of-concept code t
...

📝 josibake converted_to_draft a pull request: "Silent Payments: Implement BIP352"
(https://github.com/bitcoin/bitcoin/pull/28122)
This PR is part of integrating silent payments into Bitcoin Core. The project is tracked in https://github.com/bitcoin/bitcoin/issues/28536

## BIP352

This PR focuses strictly on the BIP logic and attempts to separate it from the wallet and transaction implementation details. This is accomplished by working directly with public and private keys, instead of needing a wallet backend and transactions for testing. Labels for the receiver are optional and thus deferred for a later PR.

Test ve
...

💬 fjahr commented on pull request "rpc: Do not wait for headers inside loadtxoutset":
(https://github.com/bitcoin/bitcoin/pull/29345#issuecomment-1952876404)
ACK faa30a4c56

Thanks, as @pablomartin4btc found, I had a slight preference for this simpler solution when reviewing the original PR.

I wrote a test for this (and also removed a `sync_block` call that seemed unnecessary in the process), can be pulled in here or I can open it as a follow-up: https://github.com/fjahr/bitcoin/commits/pr29345/

💬 brunoerg commented on pull request "contrib: add test for bucketing with asmap":
(https://github.com/bitcoin/bitcoin/pull/28869#issuecomment-1952906081)
Force-pushed changing the code to make it faster. Removed the `assert_debug_log` when adding an address into addrman.

Thanks, @fjahr.

💬 achow101 commented on pull request "rpc: Fixed signed integer overflow for large feerates":
(https://github.com/bitcoin/bitcoin/pull/29434#issuecomment-1952971290)
ACK dddd7be9bf038c25f3e53c5bd708fb9cf73d4493

💬 brunoerg commented on pull request "net: call `Select` with reachable networks in `ThreadOpenConnections`":
(https://github.com/bitcoin/bitcoin/pull/29436#discussion_r1494903447)
> Might be worth making this overflow-safe?

I don't know, I don't see a viable way of reaching that.

> it's really hard to trigger.... feeding addrman with that much garbage would be a failure probably before the size_t limit is hit :)

I believe that's impractical due to the limited size of addrman.

👍 BrandonOdiwuor approved a pull request: "test: Recognize dialog object by name"
(https://github.com/bitcoin-core/gui/pull/797#pullrequestreview-1888982852)
ACK 4c9db9b5874acb5db2fb9bb1eb5d549aa17f9aa8

⚠️ so7ow opened an issue: "When selecting a custom location on first launch of Bitcoin Core GUI on Mac, where is that setting stored?"
(https://github.com/bitcoin-core/gui/issues/798)
### Issues, reports or feature requests related to the GUI should be opened directly on the GUI repo

- [X] I still think this issue should be opened here

### Report

When selecting a custom location on first launch of Bitcoin Core GUI on Mac, where is that setting stored?

I've looked in ~/Library/Application\ Support/Bitcoin for bitcoin.conf and settings.json and in the selected custom location for those same files and I can't locate where that configuration settings is stored.

🚀 achow101 merged a pull request: "rpc: Fixed signed integer overflow for large feerates"
(https://github.com/bitcoin/bitcoin/pull/29434)

✅ so7ow closed an issue: "When selecting a custom location on first launch of Bitcoin Core GUI on Mac, where is that setting stored?"
(https://github.com/bitcoin-core/gui/issues/798)

💬 so7ow commented on issue "When selecting a custom location on first launch of Bitcoin Core GUI on Mac, where is that setting stored?":
(https://github.com/bitcoin-core/gui/issues/798#issuecomment-1953000731)
I belive I've located it:

`~/Library/Preferences/org.bitcoin.Bitcoin-Qt.plist`

⚠️ so7ow reopened an issue: "When selecting a custom location on first launch of Bitcoin Core GUI on Mac, where is that setting stored?"
(https://github.com/bitcoin-core/gui/issues/798)
### Issues, reports or feature requests related to the GUI should be opened directly on the GUI repo

- [X] I still think this issue should be opened here

### Report

When selecting a custom location on first launch of Bitcoin Core GUI on Mac, where is that setting stored?

I've looked in ~/Library/Application\ Support/Bitcoin for bitcoin.conf and settings.json and in the selected custom location for those same files and I can't locate where that configuration setting is stored.

💬 so7ow commented on issue "When selecting a custom location on first launch of Bitcoin Core GUI on Mac, where is that setting stored?":
(https://github.com/bitcoin-core/gui/issues/798#issuecomment-1953013370)
I spoke too soon. When I delete that file, Bitcoin Core GUI still knows about the custom location I selected at first launch.

💬 jeffreyjackson commented on issue "iOS Deployment Target for RPC":
(https://github.com/bitcoin/bitcoin/issues/11720#issuecomment-1953019639)
This is interesting. I have a spare 1tb iPhone I'd love to get this running on.

⚠️ ariard opened an issue: "Brainstorm: Transaction issuer-selected policy limits"
(https://github.com/bitcoin/bitcoin/issues/29454)
This issue opens a brainstorm about introducing transaction issuer-selected policy limits.

Currently, all the policy limits are either static (e.g `DUST_RELAY_TX_FEE` or `MIN_STANDARD_TX_NONWITNESS_SIZE`)
or it can be set dynamically on the command-line by the node operator (e.g ancestors / descendants / incremental
tx-relay fee). New policy mechanism like v3 are introducing specific limit such as the 1000 vb limit on the single
child.

This approach is limited for some use-cases, as the
...

💬 ariard commented on pull request "Add issuer-selected opt-in txn / pckg policy checks":
(https://github.com/bitcoin/bitcoin/pull/29448#issuecomment-1953038192)
did it https://github.com/bitcoin/bitcoin/issues/29454

🤔 furszy reviewed a pull request: "wallet: cache IsMine scriptPubKeys to improve performance of descriptor wallets"
(https://github.com/bitcoin/bitcoin/pull/26008#pullrequestreview-1889102719)
Code review ACK e041ed9b

It isn't blocking, but I have to admit that I'm still not really happy with the doubled script storage. I think we can do better. Will be experimenting with possible solutions.
A first measure to decrease it and remain fast, without changing the structure, could be to use the cache only for the inactive SPKMs. Since the active ones are limited in number (max 8), they can be checked quickly. However, this approach does not address the issue of handling really large sc
...

📝 bitcoin-pow opened a pull request: "Merge the PoW/PoT consensus code into BTC 026x baseline"
(https://github.com/bitcoin/bitcoin/pull/29455)
This feature implements the Proof-of-Work / Proof-of-Transaction (PoW/PoT) consensus which will make BTC a more decentralized blockchain. Instead of mining using dumb work, the consensus uses SMART work. Miners hash using their own utxo hashes to do the PoW. An attacker can't simple turn on a large farm of ASICs to attack the network, they must slowly build up their transactions to gain enough utxos so they can mine using them. The maximum possible hash rate continues to increase as more utxos a
...

✅ fanquake closed a pull request: "Merge the PoW/PoT consensus code into BTC 026x baseline"
(https://github.com/bitcoin/bitcoin/pull/29455)

📝 fanquake locked a pull request: "Merge the PoW/PoT consensus code into BTC 026x baseline"
(https://github.com/bitcoin/bitcoin/pull/29455)
This feature implements the Proof-of-Work / Proof-of-Transaction (PoW/PoT) consensus which will make BTC a more decentralized blockchain. Instead of mining using dumb work, the consensus uses SMART work. Miners hash using their own utxo hashes to do the PoW. An attacker can't simple turn on a large farm of ASICs to attack the network, they must slowly build up their transactions to gain enough utxos so they can mine using them. The maximum possible hash rate continues to increase as more utxos a
...