💬 petertodd commented on pull request "Reduce minrelaytxfee to 100 sats/kvB":
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3139446010)
> Concept NACK. Everything below 1s/vB is spam. There's no reason to change the default.

FYI my two OpenTimestamps calendars are creating sub-1sat/vB transactions:

https://alice.btc.calendar.opentimestamps.org/
https://bob.btc.calendar.opentimestamps.org/

The operator of the Finney calendar has told me he's looking into doing that as
well.

Also BlueWallet recently merged a pull-req to allow users to choose sub-1sat/vB
fees.

💬 petertodd commented on pull request "Reduce minrelaytxfee to 100 sats/kvB":
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3139456269)
> It's the USD that has fallen, Bitcoin has remained more or less the same.

This is clearly not true. If you compute the Big Mac Index for Bitcoin and USD,
Bitcoin has clearly made enormous gains over the time period in question.

https://en.wikipedia.org/wiki/Big_Mac_Index

💬 1440000bytes commented on pull request "Reduce minrelaytxfee to 100 sats/kvB":
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3139506353)
> FYI my two OpenTimestamps calendars are creating sub-1sat/vB transactions:
> Also BlueWallet recently merged a pull-req to allow users to choose sub-1sat/vB
fees.

Luke isn't wrong if runes and inscriptions are considered spam. Minimum fee is still above 1 sat/vbyte in most blocks and sub 1 sat/vbyte fee rate is mostly used by runes and inscription transactions.

<img width="1850" height="703" alt="image" src="https://github.com/user-attachments/assets/f1c5502f-7bee-4d53-a024-b7ffa49e379
...

💬 stickies-v commented on pull request "log: rate limiting followups":
(https://github.com/bitcoin/bitcoin/pull/33011#discussion_r2245140841)
Re https://github.com/bitcoin/bitcoin/pull/33011#issuecomment-3136494016:

Nice find re the lock contention. I was able to hit this from other locations in the test too on my machine. As you suggested offline, I think the best fix is to disable the LOCK category for this test. It might be helpful to first add a commit to prevent leaking categories across tests (e.g. https://github.com/stickies-v/bitcoin/commit/3d96ff75f161419654b14a7e9fd884e52aec26c4), and then the below diff should work?

<
...

💬 ArmchairCryptologist commented on pull request "Reduce minrelaytxfee to 100 sats/kvB":
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3139637317)
> Luke isn't wrong if runes and inscriptions are considered spam. Minimum fee is still above 1 sat/vbyte in most blocks and sub 1 sat/vbyte fee rate is mostly used by runes and inscription transactions.

It's irrelevant whether or not anyone considers any transaction "spam", all that matters is if miners are mining them, and they are. At the time of this writing, looking back at the last three days worth of blocks, there are about 100 blocks containing <1 sat/vB transactions, and the only pool
...

💬 maflcko commented on pull request "ci: limit max stack size to 512 KiB":
(https://github.com/bitcoin/bitcoin/pull/33079#discussion_r2245154779)
Yeah, I was confused, because on current master, it passes even with the workaround reverted at least for me locally:

`git revert -m1 --no-commit 2d5b4244147bfd59471864ed563907e8012c7aee`

Though, lowering the stack limit gives the same segfault:

```diff
diff --git a/ci/test/03_test_script.sh b/ci/test/03_test_script.sh
index 13bfea1f22..eb3950d126 100755
--- a/ci/test/03_test_script.sh
+++ b/ci/test/03_test_script.sh
@@ -141,7 +141,7 @@ du -sh "${DEPENDS_DIR}"/*/
du -sh "${PREVI
...

💬 rkrux commented on pull request "wallet: Set descriptor cache upgraded flag for migrated wallets":
(https://github.com/bitcoin/bitcoin/pull/33031#discussion_r2245195429)
I see, yes `ser_string` seems thorough.

👍 rkrux approved a pull request: "wallet: Set descriptor cache upgraded flag for migrated wallets"
(https://github.com/bitcoin/bitcoin/pull/33031#pullrequestreview-3075128335)
lgtm ACK da84d666e375b82960962ddf840f331473149999 modulo py-lint error.

💬 rkrux commented on pull request "wallet: Set descriptor cache upgraded flag for migrated wallets":
(https://github.com/bitcoin/bitcoin/pull/33031#discussion_r2245197183)
Linter fails here because of `;`

👍 dergoegge approved a pull request: "ci: allow for any libc++ intrumentation & use it for TSAN"
(https://github.com/bitcoin/bitcoin/pull/33099#pullrequestreview-3075208244)
utACK 7aa5b67132dfb71e915675a3dbcb806284e08197

💬 Crypt-iQ commented on pull request "log: rate limiting followups":
(https://github.com/bitcoin/bitcoin/pull/33011#discussion_r2245259646)
Yup, I had also hit the lock contention logging issue in other parts of the test. I ran the suggested diff 100 times without any error. Will add.

💬 glozow commented on issue "doc: Mempool Policy documentation Outdated since TRUC":
(https://github.com/bitcoin/bitcoin/issues/32067#issuecomment-3139909112)
Right, this ended up in [BIP431](https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki#specification) but not our docs, which is not very clear.

> An individual TRUC transaction is permitted to be below the mempool min relay feerate, assuming it is considered within a package that meets the mempool's feerate requirements.

Happy to review a pull or I can open one

💬 stickies-v commented on pull request "refactor: GenTxid type safety followups":
(https://github.com/bitcoin/bitcoin/pull/33005#discussion_r2245365793)
> hmm, maybe should just do a brain dump to a gist sometime.

Please cc me if you do, would be very interested to see that.

> I think if they were (treated as) opaque handles and you had to use `GetInfo()` ... that would be fine fwiw.

I agree. Although not opaque, I think that's pretty much what the `GetEntry()` methods and `CTxMemPoolEntry` should support doing? But most of the mempool interface is still expecting iterators rather than entries, so it would require a bit of adding/chang
...

💬 darosior commented on pull request "validation: detect witness stripping early on":
(https://github.com/bitcoin/bitcoin/pull/33105#discussion_r2245380170)
I considered it and decided against because 1) whether to add the txid to the reject filter seems unrelated to standardness (and surprising that `-acceptnonstdtxn=1` would now break 1p1c in the adversarial case) and 2) a failure here means the witness is invalid by consensus, #29843 would already not allow it today on master.

💬 maflcko commented on pull request "ci: limit max stack size to 512 KiB":
(https://github.com/bitcoin/bitcoin/pull/33079#issuecomment-3139957274)
> > I wonder if it can be fixed by replacing the hard-coded
>
> I can't seem to recreate this locally, so going to follow up.

Same here, I can't reproduce, even on the same machine.

💬 darosior commented on pull request "validation: detect witness stripping early on":
(https://github.com/bitcoin/bitcoin/pull/33105#discussion_r2245449707)
I think this would be a bit confusing because it would need to return `true` for undefined program types, whereas we don't know yes if this type will require a witness or not (presumably yes, but hey). I also think it's brief enough to not warrant its own function. Happy to change it, but it seems cleaner this way.

💬 darosior commented on pull request "validation: detect witness stripping early on":
(https://github.com/bitcoin/bitcoin/pull/33105#discussion_r2245453045)
self nit: if i retouch, 0e22a1401c7edee8946f404dd0deb59a94231340's message is missing a word at the end of the second sentence.

💬 darosior commented on pull request "Bump SCRIPT_VERIFY flags to 64 bit":
(https://github.com/bitcoin/bitcoin/pull/32998#issuecomment-3140066988)
Concept ACK.

🤔 furszy reviewed a pull request: "index: fix wrong assert of current_tip == m_best_block_index"
(https://github.com/bitcoin/bitcoin/pull/32878#pullrequestreview-3075577814)
> Hi @furszy , sorry for the delay, I've picked your commit of the test, which I missed earlier.

No problem. This needs a rebase.

✅ fanquake closed an issue: "tsan: drop `DEBUG_LOCKORDER` macro from TSAN job?"
(https://github.com/bitcoin/bitcoin/issues/33087)