🤔 glozow reviewed a pull request: "test: doc: follow-up #28368"
(https://github.com/bitcoin/bitcoin/pull/29013#pullrequestreview-1800463253)
utACK b1318dcc56a0181783ee7ddbd388ae878a0efc52

⚠️ zhaocaipeng opened an issue: "is a getBlockTemplate transactions's bug?"
(https://github.com/bitcoin/bitcoin/issues/29166)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

I invoke the getBlockTemplate interface using SegWit. The sum of weights in the returned transactions data is 3991625, and the sum of SigOps is 20037. Each time, I package all the transactions returned by getBlockTemplate into a block. I observe that the weight limit is 4000000, and the data returned complies with this requirement. However, I notice that the SigOp limit is 80000, and it is
...

💬 stickies-v commented on pull request "doc: Add multiprocess design doc":
(https://github.com/bitcoin/bitcoin/pull/28978#discussion_r1439417050)
nit: Perhaps useful to parameterize the host platform to highlight it's configurable? E.g.

```sh
HOST_PLATFORM="x86_64-pc-linux-gnu"
cd <BITCOIN_SOURCE_DIRECTORY>
make -C depends NO_QT=1 MULTIPROCESS=1
CONFIG_SITE=$PWD/depends/$HOST_PLATFORM/share/config.site ./configure
```

💬 stickies-v commented on pull request "doc: Add multiprocess design doc":
(https://github.com/bitcoin/bitcoin/pull/28978#discussion_r1439454381)
dead link
```suggestion
In the meantime, the developer guide [Internal interface guidelines](../developer-notes.md#internal-interface-guidelines) can provide guidance on keeping interfaces consistent and functional and avoiding compile errors.
```

💬 stickies-v commented on pull request "doc: Add multiprocess design doc":
(https://github.com/bitcoin/bitcoin/pull/28978#discussion_r1439476415)
nit
```suggestion
- **client class (in generated code)**: A C++ class generated from a Cap’n Proto interface which inherits from a Bitcoin Core abstract class, and implements each virtual method to send IPC requests to another process. (see also [components section](#c-client-subclasses-in-generated-code))
```

💬 stickies-v commented on pull request "doc: Add multiprocess design doc":
(https://github.com/bitcoin/bitcoin/pull/28978#discussion_r1439431086)
Perhaps useful to elaborate on what the `mpgen` wrapping adds to the Cap'n Proto output?

💬 stickies-v commented on pull request "doc: Add multiprocess design doc":
(https://github.com/bitcoin/bitcoin/pull/28978#discussion_r1439470004)
```suggestion
- When the call returns, it encapsulates the return value in a Cap’n Proto response, which it sends back to the `bitcoin-wallet` process.
```

👍 stickies-v approved a pull request: "doc: Add multiprocess design doc"
(https://github.com/bitcoin/bitcoin/pull/28978#pullrequestreview-1800375604)
ACK 91dc48c14825a9075a57c1eefda202b83b6346ba - left a couple of improvements but agreed that iterating in future PRs is better.

💬 Randy808 commented on pull request "Add OP_TXHASH and OP_CHECKTXHASHVERIFY opcodes":
(https://github.com/bitcoin/bitcoin/pull/29050#discussion_r1439490798)
nit: Consider adding curly braces for here for clarity (since it's so close to the break)

💬 Randy808 commented on pull request "Add OP_TXHASH and OP_CHECKTXHASHVERIFY opcodes":
(https://github.com/bitcoin/bitcoin/pull/29050#discussion_r1439490848)
Leaving it on the stack seems inconsistent with the semantics of the other 'VERIFY' opcodes

💬 glozow commented on issue "is a getBlockTemplate transactions's bug?":
(https://github.com/bitcoin/bitcoin/issues/29166#issuecomment-1874086428)
If you have a general question, consider asking on [stack exchange](https://bitcoin.stackexchange.com/).

If this is a bug report, what was the JSON result returned from `getblocktemplate` when this happened?

💬 Randy808 commented on pull request "Add OP_TXHASH and OP_CHECKTXHASHVERIFY opcodes":
(https://github.com/bitcoin/bitcoin/pull/29050#discussion_r1439497216)
I guess there's nothing wrong with concatenating the arguments and pushing it on the stack as one element to save bytes, but this part also seems inconsistent with the other opcodes. Not the most important thing in the world though, I'm curious what others think

💬 Randy808 commented on pull request "Add OP_TXHASH and OP_CHECKTXHASHVERIFY opcodes":
(https://github.com/bitcoin/bitcoin/pull/29050#discussion_r1439504948)
Good list of options 👍

💬 dergoegge commented on pull request "PoC: fuzz chainstate and block managers":
(https://github.com/bitcoin/bitcoin/pull/29158#discussion_r1439533284)
Have you checked if using `fmemopen` is better/faster than using a ram disk?

💬 hebasto commented on pull request "build: use `-no_exported_symbols` on macOS":
(https://github.com/bitcoin/bitcoin/pull/29072#discussion_r1439553990)
This makes `libbitcoinconsensus.0.dylib` export no symbols, which is not what we want, right?
```
% dyld_info -exports src/.libs/libbitcoinconsensus.0.dylib
src/.libs/libbitcoinconsensus.0.dylib [arm64]:
-exports:
offset symbol
```

💬 achow101 commented on pull request "doc: Add multiprocess design doc":
(https://github.com/bitcoin/bitcoin/pull/28978#issuecomment-1874192332)
ACK 91dc48c14825a9075a57c1eefda202b83b6346ba

💬 martinus commented on pull request "test: doc: follow-up #28368":
(https://github.com/bitcoin/bitcoin/pull/29013#issuecomment-1874194468)
re-ACK b1318dcc56a0181783ee7ddbd388ae878a0efc52

🚀 achow101 merged a pull request: "doc: Add multiprocess design doc"
(https://github.com/bitcoin/bitcoin/pull/28978)

💬 jamesob commented on pull request "PoC: fuzz chainstate and block managers":
(https://github.com/bitcoin/bitcoin/pull/29158#issuecomment-1874196101)
Cool, this is a great thing to investigate. I'll be giving the approach a look this week.

💬 achow101 commented on pull request "refactor: share and use `GenerateRandomKey` helper":
(https://github.com/bitcoin/bitcoin/pull/28455#issuecomment-1874196735)
ACK fa1d49542e4b69a5d8b1177ffe4207f051a468bb