✅ fanquake closed a pull request: "Create docker-image.yml"
(https://github.com/bitcoin/bitcoin/pull/27470)

📝 fanquake locked a pull request: "Create docker-image.yml"
(https://github.com/bitcoin/bitcoin/pull/27470)
<!--
*** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed
immediately.

GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->

<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:

* Any test improvements or new tests that improv
...

🤔 theStack requested changes to a pull request: "bugfix: rest: avoid segfault for invalid URI"
(https://github.com/bitcoin/bitcoin/pull/27468#pullrequestreview-1386991939)
It's still possible to provoke a segfault via the `/rest/mempool` endpoint, which also uses `GetQueryParameter()` (tested on a `bitcoind -signet -rest` instance):

```
$ curl localhost:38332/rest/mempool/contents.json?%
curl: (52) Empty reply from server

bitcoind output:
libc++abi: terminating with uncaught exception of type std::runtime_error: URI parsing failed, it likely contained RFC 3986 invalid characters
Abort trap (core dumped)
```

Should be easy to fix by catching ` std::ru
...

⚠️ Pttn opened an issue: "Mishandled "unknown" Address Type"
(https://github.com/bitcoin/bitcoin/issues/27472)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

Bitcoin Core behaves unexpectedly or even crashes.

* `getnewaddress "" unknown`: "Error: No unknown addresses available. (code -12)"
* `getrawchangeaddress unknown`: "Error: No unknown addresses available. (code -12)"
* `createmultisig 2 '["03789ed0bb717d88f7d321a368d905e7430207ebbd82bd342cf11ae157a7ace5fd", "03dbc6764b8884a92e871274b87583e6d5c2a58819473e17e107ef3f6aa5a61626"]' unknow
...

📝 Pttn opened a pull request: "Properly handle "unknown" Address Type"
(https://github.com/bitcoin/bitcoin/pull/27473)
Fixes https://github.com/bitcoin/bitcoin/issues/27472 by also handling at the relevant places the case where ParseOutputType returns OutputType::UNKNOWN, and not just when it returns `std::nullopt`.

💬 achow101 commented on pull request "Properly handle "unknown" Address Type":
(https://github.com/bitcoin/bitcoin/pull/27473#issuecomment-1510495876)
Given that we shouldn't ever accept `unknown` as an output type, I think it would make sense to just make `ParseOutputType` to never return `OutputType::UNKNOWN` instead of having every caller handle it specially.

💬 Pttn commented on pull request "Properly handle "unknown" Address Type":
(https://github.com/bitcoin/bitcoin/pull/27473#issuecomment-1510498491)
Makes sense, commit updated.

💬 pablomartin4btc commented on pull request "bugfix: rest: avoid segfault for invalid URI":
(https://github.com/bitcoin/bitcoin/pull/27468#issuecomment-1510527803)
> It's still possible to provoke a segfault via the `/rest/mempool` endpoint, which also uses `GetQueryParameter()` (tested on a `bitcoind -signet -rest` instance):
>

Thanks @theStack. I'll fix it asap.

💬 ariard commented on issue "Package Relay Project Tracking":
(https://github.com/bitcoin/bitcoin/issues/27463#issuecomment-1510569136)
I think one more sub-category to track is the feedback collected on how package
relay/nversion=3 are fitting multi-party applications and contracting protocols
- Lightning: legacy channels / anchor output / taproot types
- Peerswap: claim with preimage + refund cooperatively + refund after csv passes
- Collaborative transaction: splicing + dual funding flows

The [0-conf flow](https://github.com/lightning/bolts/pull/910) of Lightning can be also considered. As deployed today by some LSPs w
...

💬 ajtowns commented on issue "Package Relay Project Tracking":
(https://github.com/bitcoin/bitcoin/issues/27463#issuecomment-1510719846)
I think at a high level, the "package relay" part looks like:

- [x] make package mempool acceptance available via rpc in regtest
- [ ] fix up package acceptance/retention/mining policies to be free from DoS vectors and to behave sensibly
- [ ] behave sensibly with arbitrary txs in a package
- [ ] implement bip331 to expose package relay over p2p not just rpc

And relatedly:

- [ ] version 3 acceptance/rbf policies to limit pinnability
- [ ] ephemeral anchors

Particularly if #
...

💬 ajtowns commented on pull request "mempool: disallow txns under min relay fee, even in packages":
(https://github.com/bitcoin/bitcoin/pull/26933#issuecomment-1510743503)
ACK 6fb01d26c57f6af7205721e528bbafee8fa41027

👍 vasild approved a pull request: "p2p: skip netgroup diversity follow-up"
(https://github.com/bitcoin/bitcoin/pull/27467#pullrequestreview-1387402427)
ACK 51bc09089b18afaa3ba5a1bea638c158df20bdfa

💬 vasild commented on pull request "p2p: skip netgroup diversity follow-up":
(https://github.com/bitcoin/bitcoin/pull/27467#discussion_r1168268562)
nit: `_set` seems unnecessary. E.g. `apples` vs `apples_vector` (I guess the first one is preferable).

👍 vasild approved a pull request: "bugfix: rest: avoid segfault for invalid URI"
(https://github.com/bitcoin/bitcoin/pull/27468#pullrequestreview-1387411349)
ACK 827b14c33f39131ede35ddecde75cc052d977ec5

💬 ajtowns commented on issue "Package Relay Project Tracking":
(https://github.com/bitcoin/bitcoin/issues/27463#issuecomment-1510836263)
FWIW, I don't think "incentive compatibility" is a good description of our goal here -- I think there's three goals we want:

- for most normal use cases (including newly invented ones) just submitting your txs over p2p should work fine
- (otherwise people will tend to use centralised tx submission methods, which creates a chokepoint that will attract censorship)
- running a plain bitcoind should get you block templates within 90%-99% of optimal, depending on the resources you can alloc
...

💬 ajtowns commented on pull request "mempool: disallow txns under min relay fee, even in packages":
(https://github.com/bitcoin/bitcoin/pull/26933#issuecomment-1510851570)
> I'm not really sure where to draw the line between useful and not useful

I think "submitpackage" would count as obviously useful if it was available on mainnet -- even without package relay, a miner could expose that via a web form to allow people to do cpfp bumps when the (miner's) mempool is full, eg.

I was viewing that RPC more as "here's a way of exposing some code we're working on so we can test it while it's in development", but if you look at it as "here's something that would be
...

💬 glozow commented on issue "Package Relay Project Tracking":
(https://github.com/bitcoin/bitcoin/issues/27463#issuecomment-1510857791)
> I think at a high level, the "package relay" part looks like:

Yes, that is how I think of it.

> Particularly if https://github.com/bitcoin/bitcoin/pull/26933 is applied, is there any reason not to make submitpackage available on
all chains? It should behave no differently to submitting the transactions individually with a non-full mempool, no?

Somewhat. It's still a little bit weird when you submit a child-with-parents where a parent relies on the other (grep "Check that validation
...

💬 MarcoFalke commented on pull request "bugfix: Properly handle "unknown" Address Type":
(https://github.com/bitcoin/bitcoin/pull/27473#issuecomment-1510914279)
Looks like this may have been introduced in f5649db9d5e984ba7f376ccfd5b0a627f5c42402, so not a regression in 25.x, but 24.x?

💬 MarcoFalke commented on issue "Mishandled "unknown" Address Type":
(https://github.com/bitcoin/bitcoin/issues/27472#issuecomment-1510918616)
I wonder if `src/test/fuzz/rpc.cpp` should be updated to include a wallet somehow to catch issues like this

💬 glozow commented on pull request "mempool: disallow txns under min relay fee, even in packages":
(https://github.com/bitcoin/bitcoin/pull/26933#issuecomment-1510988023)
6fb01d2...563a2ee addressed
- https://github.com/bitcoin/bitcoin/pull/26933#discussion_r1164418072
- https://github.com/bitcoin/bitcoin/pull/26933#discussion_r1164429604
- https://github.com/bitcoin/bitcoin/pull/26933#discussion_r1164445008
- https://github.com/bitcoin/bitcoin/pull/26933#discussion_r1164445361