💬 eriknylund commented on pull request "test: verify spend from 999-of-999 taproot multisig wallet":
(https://github.com/bitcoin/bitcoin/pull/28212#discussion_r1297001150)
Thanks for the comments. 🙏 I added the comma, rebased onto master and force pushed to trigger a new build to get the mac CI through.

💬 MarcoFalke commented on pull request "ci: Run "macOS native x86_64" job on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28187#issuecomment-1682007407)
That page says "People with write permissions to a repository can re-run workflows in the repository." Maybe someone else *without* write access can confirm whether they can re-run on Cirrus?

💬 ismaelsadeeq commented on pull request "test doc: tests `acceptstalefeeestimates` option is only supported on regtest chain":
(https://github.com/bitcoin/bitcoin/pull/28157#issuecomment-1682010377)
rebased

💬 fanquake commented on pull request "ci: Run "macOS native x86_64" job on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28187#issuecomment-1682018059)
> That page says "People with write permissions to a repository can re-run workflows in the repository."

Hopefully not. If this really is the case, that's another downside to GH Actions, and going to be a wrose developer experience (we can't give write access to all contributors just to re-run CI). Would have been good if these things had been explained in the PR description, or discussion.

> can confirm whether they can re-run on Cirrus?

Contributors can definitely re-run Cirrus jobs.
...

🚀 fanquake merged a pull request: "ci: Move tidy to persistent worker"
(https://github.com/bitcoin/bitcoin/pull/28214)

📝 hebasto opened a pull request: "ci: Ensure that only a single workflow processes `github.ref` at a time"
(https://github.com/bitcoin/bitcoin/pull/28282)
This PR ensures that only a single workflow processes any push or pull request at a time.

A new push will be queued.

For a new pull request update, the previous in-progress one will be cancelled.

Address https://github.com/bitcoin/bitcoin/pull/28187#discussion_r1295144563.

💬 dergoegge commented on pull request "ci: Run "macOS native x86_64" job on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28187#issuecomment-1682031077)
> Maybe someone else without write access can confirm whether they can re-run on Cirrus?

I can't re-run GH actions tasks but am able to re-run cirrus jobs.

👍 theStack approved a pull request: "Break up script/standard.{h/cpp}"
(https://github.com/bitcoin/bitcoin/pull/28244#pullrequestreview-1582307974)
Code-review ACK 91d924ede1b421df31c895f4f43359e453a09ca5

💬 hebasto commented on pull request "ci: Run "macOS native x86_64" job on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28187#discussion_r1297022112)
> Should also abort on a force push, to avoid wasting CPU, no?

Done in #28282.

🤔 MarcoFalke reviewed a pull request: "ci: Ensure that only a single workflow processes `github.ref` at a time"
(https://github.com/bitcoin/bitcoin/pull/28282#pullrequestreview-1582331060)
ACK

💬 MarcoFalke commented on pull request "ci: Ensure that only a single workflow processes `github.ref` at a time":
(https://github.com/bitcoin/bitcoin/pull/28282#discussion_r1297036891)
```suggestion
cancel-in-progress: ${{ github.event_name == 'pull_request' }}
```

why is this needed?

💬 hebasto commented on pull request "ci: Run "macOS native x86_64" job on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28187#issuecomment-1682048469)
> > Maybe someone else without write access can confirm whether they can re-run on Cirrus?
>
> I can't re-run GH actions tasks but am able to re-run cirrus jobs.

Does closing a PR and following re-opening it work?

✅ dergoegge closed a pull request: "util: Type-safe transaction identifiers"
(https://github.com/bitcoin/bitcoin/pull/28107)

📝 dergoegge reopened a pull request: "util: Type-safe transaction identifiers"
(https://github.com/bitcoin/bitcoin/pull/28107)
We currently have two different identifiers for transactions: `txid` (refering to the hash of a transaction without witness data) and `wtxid` (referring to the hash of a transaction including witness data). Both are typed as `uint256` which could lead to type-safety bugs in which one transaction identifier type is passed where the other would be expected.

This PR introduces explicit `Txid` and `Wtxid` types that (if used) would cause compilation errors for such type confusion bugs.

(Only t
...

💬 dergoegge commented on pull request "ci: Run "macOS native x86_64" job on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28187#issuecomment-1682051697)
> Does closing a PR and following re-opening it work?

No, that just cancels all jobs and the gha one just continues running

🤔 ajtowns reviewed a pull request: "rpc: Add Arg() default helper"
(https://github.com/bitcoin/bitcoin/pull/28230#pullrequestreview-1582339621)
utACK fa0cbfc445fbbad4009833ad9f13fb56886111a5

💬 ajtowns commented on pull request "rpc: Add Arg() default helper":
(https://github.com/bitcoin/bitcoin/pull/28230#discussion_r1297043205)
"checks" not "checkes"

💬 ajtowns commented on pull request "rpc: Add Arg() default helper":
(https://github.com/bitcoin/bitcoin/pull/28230#discussion_r1297042546)
With `MaybeArg` always working, could make this:

```c++
static const UniValue* DetailMaybeArg(const std::vector<RPCArg>& params, const JSONRPCRequest* req, size_t i, bool null_ok)
{
...
if (!null_ok) CheckRequiredOrDefault(param);
...
}

#define TMPL_INST_MAYBE(ret_type, get_arg, return_code, return_code_null) \
template <> \
ret_type RPCHelpMan::get_arg(size_t i) const \
{
...

💬 ajtowns commented on pull request "rpc: Add Arg() default helper":
(https://github.com/bitcoin/bitcoin/pull/28230#discussion_r1297043961)
Add "should not be used for optional arguments that do not have a default error" or similar?

💬 hebasto commented on pull request "ci: Ensure that only a single workflow processes `github.ref` at a time":
(https://github.com/bitcoin/bitcoin/pull/28282#discussion_r1297049828)
Thanks! Updated.