📝 ariard opened a pull request: "Libstandardness (edition 2023)"
(https://github.com/bitcoin/bitcoin/pull/28220)
This PR proposes to introduce a new interface to allow applications and second layers protocols to verify that their unconfirmed and non-propagated transactions are valid under Bitcoin Core transaction relay policy.
This new `libstandardness` interface is designed at the image of the `bitcoinconsensus` library, which already exposes some of the script verification internals to other applications. A new method is introduced `libstandard_verify_transaction` which indicate to the caller if the t
...
(https://github.com/bitcoin/bitcoin/pull/28220)
This PR proposes to introduce a new interface to allow applications and second layers protocols to verify that their unconfirmed and non-propagated transactions are valid under Bitcoin Core transaction relay policy.
This new `libstandardness` interface is designed at the image of the `bitcoinconsensus` library, which already exposes some of the script verification internals to other applications. A new method is introduced `libstandard_verify_transaction` which indicate to the caller if the t
...
📝 ariard converted_to_draft a pull request: "Libstandardness (edition 2023)"
(https://github.com/bitcoin/bitcoin/pull/28220)
This PR proposes to introduce a new interface to allow applications and second layers protocols to verify that their unconfirmed and non-propagated transactions are valid under Bitcoin Core transaction relay policy.
This new `libstandardness` interface is designed at the image of the `bitcoinconsensus` library, which already exposes some of the script verification internals to other applications. A new method is introduced `libstandard_verify_transaction` which indicate to the caller if the t
...
(https://github.com/bitcoin/bitcoin/pull/28220)
This PR proposes to introduce a new interface to allow applications and second layers protocols to verify that their unconfirmed and non-propagated transactions are valid under Bitcoin Core transaction relay policy.
This new `libstandardness` interface is designed at the image of the `bitcoinconsensus` library, which already exposes some of the script verification internals to other applications. A new method is introduced `libstandard_verify_transaction` which indicate to the caller if the t
...
💬 ariard commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666376820)
> Can it be used to pin transactions in a way that unupgraded nodes (including poorly maintained alternative implementations that are potentially used in second layer protocols) wouldn't notice?
@Sjors What do you mean by introducing a pinning vector for second layers, like you would need `SIGHASH_SINGLE` tx (which is the case with LN anchor output) where the tx finalizer doesn’t commit to inputs/outputs with `SIGHASH_ALL`, which mean it could be pinned by a large range of tricks, such as add
...
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666376820)
> Can it be used to pin transactions in a way that unupgraded nodes (including poorly maintained alternative implementations that are potentially used in second layer protocols) wouldn't notice?
@Sjors What do you mean by introducing a pinning vector for second layers, like you would need `SIGHASH_SINGLE` tx (which is the case with LN anchor output) where the tx finalizer doesn’t commit to inputs/outputs with `SIGHASH_ALL`, which mean it could be pinned by a large range of tricks, such as add
...
💬 RicYashiroLee commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666382038)
> > If you believe that core shouldnt be making policy decisions on behalf of users, then shouldnt the default be that there is no default policy and that users can set it to whatever they want? Thats what this PR would do (for this policy item).
>
> There is inherently ALWAYS a policy. "No default policy" would mean users are forced to make a decision (that was #).
>
> This PR would make the default policy actively HARMFUL to Bitcoin (more than it already is). If you want a simpler defaul
...
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666382038)
> > If you believe that core shouldnt be making policy decisions on behalf of users, then shouldnt the default be that there is no default policy and that users can set it to whatever they want? Thats what this PR would do (for this policy item).
>
> There is inherently ALWAYS a policy. "No default policy" would mean users are forced to make a decision (that was #).
>
> This PR would make the default policy actively HARMFUL to Bitcoin (more than it already is). If you want a simpler defaul
...
💬 dpc commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666383038)
OP_RETURN size limit is a "feel good" policy, that achieves nothing and just make things artificially more difficult in other areas. You'd think that Bitcoiners are going to be more rational than politicians that need to fool the public to get re-elected with such policies.
People were putting garbage and "spamming" the blockchain in the past, spamming is rampant currently and I have never ever seen a convincing explanation of a future strategy that could actually stop it. And no, ever increa
...
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666383038)
OP_RETURN size limit is a "feel good" policy, that achieves nothing and just make things artificially more difficult in other areas. You'd think that Bitcoiners are going to be more rational than politicians that need to fool the public to get re-elected with such policies.
People were putting garbage and "spamming" the blockchain in the past, spamming is rampant currently and I have never ever seen a convincing explanation of a future strategy that could actually stop it. And no, ever increa
...
⚠️ darosior opened an issue: "Flaky `wallet_transactiontime_rescan.py --legacy-wallet` functional test"
(https://github.com/bitcoin/bitcoin/issues/28221)
Failed in CI on unrelated PR https://github.com/bitcoin/bitcoin/pull/28216.
```
test 2023-08-04T17:39:25.417000Z TestFramework (ERROR): Called Process failed with 'error: timeout on transient error: Could not connect to the server 127.0.0.1:20800 (error code 0 - "timeout reached")
Make sure the bitcoind server is running and that you are connecting to the correct RPC port.
'
Traceba
...
(https://github.com/bitcoin/bitcoin/issues/28221)
Failed in CI on unrelated PR https://github.com/bitcoin/bitcoin/pull/28216.
```
test 2023-08-04T17:39:25.417000Z TestFramework (ERROR): Called Process failed with 'error: timeout on transient error: Could not connect to the server 127.0.0.1:20800 (error code 0 - "timeout reached")
Make sure the bitcoind server is running and that you are connecting to the correct RPC port.
'
Traceba
...
💬 darosior commented on pull request "mempool: Persist with XOR":
(https://github.com/bitcoin/bitcoin/pull/28207#discussion_r1284973598)
Might as well set it to true, as long as someone who was relying on the previous behaviour can simply set `-persistmempoolv1`.
(https://github.com/bitcoin/bitcoin/pull/28207#discussion_r1284973598)
Might as well set it to true, as long as someone who was relying on the previous behaviour can simply set `-persistmempoolv1`.
🤔 darosior reviewed a pull request: "mempool: Persist with XOR"
(https://github.com/bitcoin/bitcoin/pull/28207#pullrequestreview-1563779763)
Concept and approach ACK. I don't think there is harm in making it the default behaviour immediately.
(https://github.com/bitcoin/bitcoin/pull/28207#pullrequestreview-1563779763)
Concept and approach ACK. I don't think there is harm in making it the default behaviour immediately.
💬 darosior commented on pull request "mempool: Persist with XOR":
(https://github.com/bitcoin/bitcoin/pull/28207#discussion_r1284973476)
```suggestion
DEFAULT_PERSIST_V1_DAT),
```
(https://github.com/bitcoin/bitcoin/pull/28207#discussion_r1284973476)
```suggestion
DEFAULT_PERSIST_V1_DAT),
```
💬 hebasto commented on pull request "ci: Run Windows native task on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28173#issuecomment-1666430255)
Converting this PR to a draft as it conflicts with https://github.com/bitcoin/bitcoin/pull/28187.
Please review https://github.com/bitcoin/bitcoin/pull/28187 first.
(https://github.com/bitcoin/bitcoin/pull/28173#issuecomment-1666430255)
Converting this PR to a draft as it conflicts with https://github.com/bitcoin/bitcoin/pull/28187.
Please review https://github.com/bitcoin/bitcoin/pull/28187 first.
📝 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
...