📝 hebasto converted_to_draft a pull request: "ci: Run Windows native task on GitHub Actions"
(https://github.com/bitcoin/bitcoin/pull/28173)
From https://github.com/bitcoin/bitcoin/issues/28098:
> Thus, someone would have to sponsor an amount of roughly 5kUSD/mo for those two tasks.
> If the goal is to stay on a free plan, I think the only option is GitHub Actions CI.
Historical context:
- https://github.com/bitcoin/bitcoin/pull/17697
- https://github.com/bitcoin/bitcoin/issues/17803
- https://github.com/bitcoin/bitcoin/pull/18031
Security concerns:
- https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-16514321
...
(https://github.com/bitcoin/bitcoin/pull/28173)
From https://github.com/bitcoin/bitcoin/issues/28098:
> Thus, someone would have to sponsor an amount of roughly 5kUSD/mo for those two tasks.
> If the goal is to stay on a free plan, I think the only option is GitHub Actions CI.
Historical context:
- https://github.com/bitcoin/bitcoin/pull/17697
- https://github.com/bitcoin/bitcoin/issues/17803
- https://github.com/bitcoin/bitcoin/pull/18031
Security concerns:
- https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-16514321
...
💬 zndtoshi commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666435919)
Did anyone calculate what would be the cost of placing ordinals inside a no-limit op_return output? If the costs would be higher (as I imagine) than putting them in the witness space (and taking advantage of the witness discount) then the merge of this proposal would not solve anything because people will just continue to use the cheapest way.
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666435919)
Did anyone calculate what would be the cost of placing ordinals inside a no-limit op_return output? If the costs would be higher (as I imagine) than putting them in the witness space (and taking advantage of the witness discount) then the merge of this proposal would not solve anything because people will just continue to use the cheapest way.
💬 TheCharlatan commented on pull request "kernel: Prune leveldb headers":
(https://github.com/bitcoin/bitcoin/pull/28186#discussion_r1284999471)
It would, but then we'd also have to forward-declare a destructor class for it and I don't think it's really worth doing that.
(https://github.com/bitcoin/bitcoin/pull/28186#discussion_r1284999471)
It would, but then we'd also have to forward-declare a destructor class for it and I don't think it's really worth doing that.
💬 dimitaracev commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666441956)
Concept NACK for the same reasons others have stated above.
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666441956)
Concept NACK for the same reasons others have stated above.
📝 willcl-ark opened a pull request: "Use shared_ptr for CNode inside CConnman"
(https://github.com/bitcoin/bitcoin/pull/28222)
Switch to using smart pointers to `CNode`s inside of `CConnman`.
Currently we are manually refcounting CNodes which is potentially error-prone and makes operations such as deleting them from multiple threads difficult without introducing new locks or other synchronisation operations (see https://github.com/bitcoin/bitcoin/pull/27912).
Switch to using `std::shared_ptr` references to `CNode`s inside of `m_nodes` and `m_nodes_disconnected` to give us better memory safety today, and in the fut
...
(https://github.com/bitcoin/bitcoin/pull/28222)
Switch to using smart pointers to `CNode`s inside of `CConnman`.
Currently we are manually refcounting CNodes which is potentially error-prone and makes operations such as deleting them from multiple threads difficult without introducing new locks or other synchronisation operations (see https://github.com/bitcoin/bitcoin/pull/27912).
Switch to using `std::shared_ptr` references to `CNode`s inside of `m_nodes` and `m_nodes_disconnected` to give us better memory safety today, and in the fut
...
💬 TheCharlatan commented on pull request "kernel: Prune leveldb headers":
(https://github.com/bitcoin/bitcoin/pull/28186#issuecomment-1666459887)
Thank you for the review @stickies-v,
Updated 3fb2dac2ce78092c1006ee082c536bea1b69a152 -> 1be04724a3ac061859118c09b90e2e15ea8d04b0 ([cleaveLeveldbHeaders_4](https://github.com/TheCharlatan/bitcoin/tree/cleaveLeveldbHeaders_4) -> [cleaveLeveldbHeaders_5](https://github.com/TheCharlatan/bitcoin/tree/cleaveLeveldbHeaders_5), [compare](https://github.com/TheCharlatan/bitcoin/compare/cleaveLeveldbHeaders_4..cleaveLeveldbHeaders_5))
* Addressed @stickies-v's [comment_1](https://github.com/bitco
...
(https://github.com/bitcoin/bitcoin/pull/28186#issuecomment-1666459887)
Thank you for the review @stickies-v,
Updated 3fb2dac2ce78092c1006ee082c536bea1b69a152 -> 1be04724a3ac061859118c09b90e2e15ea8d04b0 ([cleaveLeveldbHeaders_4](https://github.com/TheCharlatan/bitcoin/tree/cleaveLeveldbHeaders_4) -> [cleaveLeveldbHeaders_5](https://github.com/TheCharlatan/bitcoin/tree/cleaveLeveldbHeaders_5), [compare](https://github.com/TheCharlatan/bitcoin/compare/cleaveLeveldbHeaders_4..cleaveLeveldbHeaders_5))
* Addressed @stickies-v's [comment_1](https://github.com/bitco
...
💬 real-or-random commented on issue "ci: Future of macOS and Windows MSVC CI tasks":
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1666461727)
> Thus, someone would have to sponsor an amount of roughly 5kUSD/mo for those two tasks
How did you arrive at these numbers? Is there a better source than the [cirrus "metrics" page](https://cirrus-ci.com/metrics/repository/github/bitcoin/bitcoin)? I looked at this in the past for libsecp256k1 and arrived at very high USD numbers. Now I redid the numbers for Linux tasks and that's pretty cheap (for secp256k1):
Based on the graph in https://cirrus-ci.com/metrics/repository/github/bitcoin-co
...
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1666461727)
> Thus, someone would have to sponsor an amount of roughly 5kUSD/mo for those two tasks
How did you arrive at these numbers? Is there a better source than the [cirrus "metrics" page](https://cirrus-ci.com/metrics/repository/github/bitcoin/bitcoin)? I looked at this in the past for libsecp256k1 and arrived at very high USD numbers. Now I redid the numbers for Linux tasks and that's pretty cheap (for secp256k1):
Based on the graph in https://cirrus-ci.com/metrics/repository/github/bitcoin-co
...
💬 vostrnad commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666461731)
> Yes, that's a good thing because standard output types don't bloat the UTXO set as much as the current spam attacks do.
I admit I don't know the specifics of how the UTXO set is stored, but how does storing 96 bytes in one 3-of-3 bare multisig bloat it more than say storing it in 3 P2TR outputs?
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666461731)
> Yes, that's a good thing because standard output types don't bloat the UTXO set as much as the current spam attacks do.
I admit I don't know the specifics of how the UTXO set is stored, but how does storing 96 bytes in one 3-of-3 bare multisig bloat it more than say storing it in 3 P2TR outputs?
💬 Retropex commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666462061)
> Best practices in accordance with whom?
With my node that has been constantly spamming for seven months with catastrophic consequences on the UTXOs set.
[Size of Serialized UTXO Set.](https://statoshi.info/d/000000009/unspent-transaction-output-set?orgId=1&refresh=10m&from=now-1y&to=now&viewPanel=8)
[Stamps.](https://orangepill.ovh/fr/tx/b06d85ba23e663d24e73041df4f708e030991377a36a300dd439e6bfa2f2eaa1)
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666462061)
> Best practices in accordance with whom?
With my node that has been constantly spamming for seven months with catastrophic consequences on the UTXOs set.
[Size of Serialized UTXO Set.](https://statoshi.info/d/000000009/unspent-transaction-output-set?orgId=1&refresh=10m&from=now-1y&to=now&viewPanel=8)
[Stamps.](https://orangepill.ovh/fr/tx/b06d85ba23e663d24e73041df4f708e030991377a36a300dd439e6bfa2f2eaa1)
💬 hebasto commented on issue "ci: Future of macOS and Windows MSVC CI tasks":
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1666465022)
> > Thus, someone would have to sponsor an amount of roughly 5kUSD/mo for those two tasks
>
> How did you arrive at these numbers? Is there a better source than the [cirrus "metrics" page](https://cirrus-ci.com/metrics/repository/github/bitcoin/bitcoin)?
https://cirrus-ci.com/settings/github/bitcoin:
But "Monthly Usage" numbers in https://cirrus-ci.com/settings/github/bitcoin-core are no
...
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1666465022)
> > Thus, someone would have to sponsor an amount of roughly 5kUSD/mo for those two tasks
>
> How did you arrive at these numbers? Is there a better source than the [cirrus "metrics" page](https://cirrus-ci.com/metrics/repository/github/bitcoin/bitcoin)?
https://cirrus-ci.com/settings/github/bitcoin:
But "Monthly Usage" numbers in https://cirrus-ci.com/settings/github/bitcoin-core are no
...
💬 real-or-random commented on issue "ci: Future of macOS and Windows MSVC CI tasks":
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1666467850)
Oh, thanks, this was the page I couldn't find anymore. But I don't understand the numbers. For example for the "bitcoin" org, the page shows 3495 CPU hours and 3160 credits on Linux in July. How does this work out? 3495 h = 209700 min, which translates to 629,1 credits assuming 3 credits/1000 min.
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1666467850)
Oh, thanks, this was the page I couldn't find anymore. But I don't understand the numbers. For example for the "bitcoin" org, the page shows 3495 CPU hours and 3160 credits on Linux in July. How does this work out? 3495 h = 209700 min, which translates to 629,1 credits assuming 3 credits/1000 min.
💬 hebasto commented on issue "ci: Future of macOS and Windows MSVC CI tasks":
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1666469027)
> Oh, thanks, this was the page I couldn't find anymore. But I don't understand the numbers. For example for the "bitcoin" org, the page shows 3495 CPU hours and 3160 credits on Linux in July. How does this work out? 3495 h = 209700 min, which translates to 629,1 credits assuming 3 credits/1000 min.
cc @fkorotkov
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1666469027)
> Oh, thanks, this was the page I couldn't find anymore. But I don't understand the numbers. For example for the "bitcoin" org, the page shows 3495 CPU hours and 3160 credits on Linux in July. How does this work out? 3495 h = 209700 min, which translates to 629,1 credits assuming 3 credits/1000 min.
cc @fkorotkov
💬 Retropex commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#discussion_r1285019803)
PR updated.
Your changes worked on my side.
(https://github.com/bitcoin/bitcoin/pull/28217#discussion_r1285019803)
PR updated.
Your changes worked on my side.
💬 vostrnad commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666471945)
The vast majority of the recent UTXO set size increase (which mostly happened in the last four months, not seven) comes not from [bare multisig](https://transactionfee.info/charts/inputs-and-outputs-p2ms/) but from [BRC-20](https://transactionfee.info/charts/inputs-and-outputs-p2tr/). Bare multisig peaked in April, barely crossing 10k unspent outputs a day, and currently adds only a few hundred daily, while BRC-20 still keeps adding over 50k unspent outputs every day.
Note that this is largel
...
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666471945)
The vast majority of the recent UTXO set size increase (which mostly happened in the last four months, not seven) comes not from [bare multisig](https://transactionfee.info/charts/inputs-and-outputs-p2ms/) but from [BRC-20](https://transactionfee.info/charts/inputs-and-outputs-p2tr/). Bare multisig peaked in April, barely crossing 10k unspent outputs a day, and currently adds only a few hundred daily, while BRC-20 still keeps adding over 50k unspent outputs every day.
Note that this is largel
...
💬 vasild commented on issue "Does not use bind to local address for outgoing connections":
(https://github.com/bitcoin/bitcoin/issues/6476#issuecomment-1666472338)
This request looks reasonable. Is there still interest in it?
Something like this should do it (and pass the proper argument to `ConnectSocketDirectly()` untested):
```diff
-bool ConnectSocketDirectly(const CService &addrConnect, const Sock& sock, int nTimeout, bool manual_connection)
+bool ConnectSocketDirectly(const std::optional<CNetAddr>& addr_from, const CService &addrConnect, const Sock& sock, int nTimeout, bool manual_connection)
{
// Create a sockaddr from the specified s
...
(https://github.com/bitcoin/bitcoin/issues/6476#issuecomment-1666472338)
This request looks reasonable. Is there still interest in it?
Something like this should do it (and pass the proper argument to `ConnectSocketDirectly()` untested):
```diff
-bool ConnectSocketDirectly(const CService &addrConnect, const Sock& sock, int nTimeout, bool manual_connection)
+bool ConnectSocketDirectly(const std::optional<CNetAddr>& addr_from, const CService &addrConnect, const Sock& sock, int nTimeout, bool manual_connection)
{
// Create a sockaddr from the specified s
...
💬 HenrikJannsen commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666475502)
> Did anyone calculate what would be the cost of placing ordinals inside a no-limit op_return output? If the costs would be higher (as I imagine) than putting them in the witness space (and taking advantage of the witness discount) then the merge of this proposal would not solve anything because people will just continue to use the cheapest way. For those reasons I'm actually in favor.. so ACK.
It is not only the financial costs one need to consider, there are other costs. Complexity of imple
...
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666475502)
> Did anyone calculate what would be the cost of placing ordinals inside a no-limit op_return output? If the costs would be higher (as I imagine) than putting them in the witness space (and taking advantage of the witness discount) then the merge of this proposal would not solve anything because people will just continue to use the cheapest way. For those reasons I'm actually in favor.. so ACK.
It is not only the financial costs one need to consider, there are other costs. Complexity of imple
...
💬 hebasto commented on issue "ci: Future of macOS and Windows MSVC CI tasks":
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1666478746)
> But I don't understand the numbers.
Me neither. See https://github.com/cirruslabs/cirrus-ci-web/pull/572#issuecomment-1666478538.
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1666478746)
> But I don't understand the numbers.
Me neither. See https://github.com/cirruslabs/cirrus-ci-web/pull/572#issuecomment-1666478538.
📝 fanquake locked a pull request: "Create devcontainer.json"
(https://github.com/bitcoin/bitcoin/pull/28219)
<!--
*** 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
...
(https://github.com/bitcoin/bitcoin/pull/28219)
<!--
*** 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
...
💬 zndtoshi commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666485874)
An option would be also to keep status quo and let node runners modify bitcoin.conf if they want to increase the op_return limit. Like the discussion with fullmempoolrbf.
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666485874)
An option would be also to keep status quo and let node runners modify bitcoin.conf if they want to increase the op_return limit. Like the discussion with fullmempoolrbf.
💬 zkfrio commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666488599)
> I don't understand why Bitcoin devs are not more engaged in those discussions.
Because nobody wants to attack the network because of some transactions.
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666488599)
> I don't understand why Bitcoin devs are not more engaged in those discussions.
Because nobody wants to attack the network because of some transactions.