💬 brunoerg commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1214831451)
It seems for extra anonymity, but I have a similar doubt, couldn't I make easier for someone to censor us?

💬 instagibbs commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1214832859)
unless we want to sybil the network and fake long-term connections, it's obvious what this connection will be about? Just retry with new peers until someone honest propagates it?

💬 ryanofsky commented on pull request "wallet: Add tracing for sqlite statements":
(https://github.com/bitcoin/bitcoin/pull/27801#issuecomment-1574316464)
> Turning this on will log private keys as they are being written to the db, which seems a little scary.

Yes when the tracing was turned on, having access to the debug log file would be like having access to the database file. The keys would at least be encrypted if the wallet had a password set, but it could still be scary/unexpected behavior.

I looked into ways of trying to mask values in the sql statement, but the `sqlite3_stmt` object is pretty opaque and I couldn't find any function h
...

💬 achow101 commented on pull request "wallet: Add tracing for sqlite statements":
(https://github.com/bitcoin/bitcoin/pull/27801#issuecomment-1574364005)
ACK ff9d961bf38b24f8f931dcf66799cbc468e473df

💬 achow101 commented on pull request "fuzz: Fix mini_miner_selection running out of coin":
(https://github.com/bitcoin/bitcoin/pull/27806#discussion_r1214886372)
In bbb927739955b1588d94c5fd8ed73ddf5afde46c "fuzz: Fix mini_miner_selection running out of coin"

Is it possible that `available_coins` is empty and so `num_inputs = 0`? It may be useful to have an additional assert before the inputs are filled below.

💬 ismaelsadeeq commented on pull request "Fee estimation: avoid serving stale fee estimate":
(https://github.com/bitcoin/bitcoin/pull/27622#discussion_r1214935160)
Thank you, I added the delete attempt

💬 ismaelsadeeq commented on pull request "Fee estimation: avoid serving stale fee estimate":
(https://github.com/bitcoin/bitcoin/pull/27622#discussion_r1214936512)
Sure, thank you, I updated the test.

💬 ismaelsadeeq commented on pull request "Fee estimation: avoid serving stale fee estimate":
(https://github.com/bitcoin/bitcoin/pull/27622#issuecomment-1574425436)
> Also wondering if we should include a hidden argument to allow older files for testing reasons, re: #27415
> I've used it for systems I've built for integration testing, and not having to touch a file during testing to refresh it would be a simplification.
>
> > For testing, they could mock the time right?
>
> Depends on your test setup, really. It might interfere during integration tests which require a realistic clock?
>
> Makes sense, seems fine as a regtest-only option for testing
...

💬 ajtowns commented on pull request "net_processing: Drop m_recently_announced_invs bloom filter":
(https://github.com/bitcoin/bitcoin/pull/27675#discussion_r1215190508)
I think the answer is just to add a new tx entry field for the steady clock time and use that at natural precision.

💬 desibitcoiner commented on issue "Build broken when enabling fuzzing on Apple M1 hw using homebrew llvm.":
(https://github.com/bitcoin/bitcoin/issues/27550#issuecomment-1574690664)
I'm trying to run a build on Fedora 36 and I'm seeing the same error.
When I run ./configure I see the following:

configure: WARNING: Bitcoin Core requires this library for BDB (legacy) wallet support
configure: WARNING: Passing --without-bdb will suppress this warning
checking for SQLITE... yes
checking whether to build wallet with support for sqlite... yes
checking whether Userspace, Statically Defined Tracing tracepoints are supported... no
checking for natpmp.h... yes
checking for
...

⚠️ desibitcoiner opened an issue: "Build fails on Fedora 36 - configure failed for src/secp256k1"
(https://github.com/bitcoin/bitcoin/issues/27808)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

Found an recent similar issue but didn't help:
https://github.com/bitcoin/bitcoin/issues/27550

I'm trying to run a build on Fedora 36 and I'm seeing the same error.
When I run ./configure I see the following:

configure: WARNING: Bitcoin Core requires this library for BDB (legacy) wallet support
configure: WARNING: Passing --without-bdb will suppress this warning
checking for SQLI
...

👍 hebasto approved a pull request: "guix: remove cURL from build env"
(https://github.com/bitcoin/bitcoin/pull/27779#pullrequestreview-1458997060)
ACK 641897a83dc9d40b618efbae67c3beb90a1f34f8

Guix build:
```
7e9b3758aadd87db9c89fec5c05ca7a5020aaebf185daee4f7570dd1eeb23355 guix-build-641897a83dc9/output/aarch64-linux-gnu/SHA256SUMS.part
494f06d1f21ad20aa8cc8f61c4dfeda053215f41bb2aa0bfd47343909edf4dad guix-build-641897a83dc9/output/aarch64-linux-gnu/bitcoin-641897a83dc9-aarch64-linux-gnu-debug.tar.gz
8a3912a0ff0cb41b87494291ca13bc9caa47ff08d57f37b6d99a9c8e3667390a guix-build-641897a83dc9/output/aarch64-linux-gnu/bitcoin-641897a83dc
...

📝 aguycalled opened a pull request: "BLSCT SubAddressPool"
(https://github.com/bitcoin/bitcoin/pull/27809)
This PR adds support for the use of a SubAddress pool and the generation of different receiving addresses.

`getnewaddress` RPC method pulls addresses from the pool and shows to the requester receiving addresses.

By default it generates addresses under account `0`.

✅ fanquake closed a pull request: "BLSCT SubAddressPool"
(https://github.com/bitcoin/bitcoin/pull/27809)

💬 Ayms commented on pull request "Ignore datacarrier limits for dataless OP_RETURN outputs":
(https://github.com/bitcoin/bitcoin/pull/27261#issuecomment-1574929624)
I must be brain damaged or something like this, still I don't get what it has to do with https://github.com/bitcoin/bitcoin/issues/27043 (and when it will happen)

📝 dergoegge opened a pull request: "fuzz: Partially revert #27780"
(https://github.com/bitcoin/bitcoin/pull/27810)
Partially revert #27780, because moving the duplicate coinbase check out of the `was_valid` branch leads to non-bug crashes in the fuzz target.

For context and further explanation see: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=59516

💬 sipa commented on pull request "util: generalize accounting of system-allocated memory in pool resource":
(https://github.com/bitcoin/bitcoin/pull/27748#discussion_r1215541260)
This is what I measure (GCC 12.2.0, glibc 2.37, x86_64 and i686):

* 64-bit:
** 1-24: 32
** 25-40: 48
** 41-56: 64
** 57-72: 80
** 73-88: 96
** Rule: max(32, (X+23) & ~15)

* 32-bit:
** 1-12: 16
** 13-28: 32
** 29-44: 48
** 45-60: 64
** 61-76: 80
** Rule: (X+19) & ~15

💬 brunoerg commented on pull request "fuzz: Fix mini_miner_selection running out of coin":
(https://github.com/bitcoin/bitcoin/pull/27806#discussion_r1215564954)
Wouldn't be an alternative to replace `LIMITED_WHILE(fuzzed_data_provider.ConsumeBool(), 100)` for `LIMITED_WHILE(!available_coins.empty(), 100)`?

📝 hebasto opened a pull request: "guix: Clean up manifest"
(https://github.com/bitcoin/bitcoin/pull/27811)
This PR cleans up the `contrib/guix/manifest.scm` in the following way:
- Unneeded for a successful build modules have be dropped.
- Some modules have been enhanced with `#:select` clauses, which improves maintainability (see the commit message for details).

Based on https://github.com/bitcoin/bitcoin/pull/27779.

💬 denavila commented on pull request "wallet: Deniability API (Unilateral Transaction Meta-Privacy)":
(https://github.com/bitcoin/bitcoin/pull/27792#issuecomment-1575041987)
> Good point and most of the people who tried this with coins involved in any incident regret doing it. Privacy in bitcoin is not as simple as doing some transactions with your own addresses automatically. There are lot of things you need to take care of. One mistake and your privacy is breached, publicly available for the whole world.

What kind of incidents do you mean? Do you have some concrete examples?
I don't see how one's privacy would be any worse after sending transactions to oneself
...