💬 RobinLinus commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666365005)
> can just switch to a different standard output type
Yes, that's a good thing because standard output types don't bloat the UTXO set as much as the current spam attacks do.
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666365005)
> can just switch to a different standard output type
Yes, that's a good thing because standard output types don't bloat the UTXO set as much as the current spam attacks do.
💬 furszy commented on pull request "test: create wallet specific for test_locked_wallet case":
(https://github.com/bitcoin/bitcoin/pull/28139#discussion_r1284952519)
Haven't been able to reproduce it. It is always passing here. But, I imagine that it's related to the dynamic fee rate calculation. Which.. is not needed in this test case; the test exercises the creation of a changeless transaction, the fee rate used is not really important.
So, when you can, try https://github.com/furszy/bitcoin-core/commit/557c50deb0253af299dc88856b34399b0d626bd3.
(https://github.com/bitcoin/bitcoin/pull/28139#discussion_r1284952519)
Haven't been able to reproduce it. It is always passing here. But, I imagine that it's related to the dynamic fee rate calculation. Which.. is not needed in this test case; the test exercises the creation of a changeless transaction, the fee rate used is not really important.
So, when you can, try https://github.com/furszy/bitcoin-core/commit/557c50deb0253af299dc88856b34399b0d626bd3.
💬 vicariousdrama commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666369659)
Concept ACK
Primarily for same reasons outlined by @ChristopherA.
Allows for including signature by a third party other than that signing the keys controlling the inputs. E.g., service provider. Promotes decentralization as otherwise users that want this feature must work with miners directly. May help reduce rate of UTXO growth that results from abusive outputs used in bare multisig.
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666369659)
Concept ACK
Primarily for same reasons outlined by @ChristopherA.
Allows for including signature by a third party other than that signing the keys controlling the inputs. E.g., service provider. Promotes decentralization as otherwise users that want this feature must work with miners directly. May help reduce rate of UTXO growth that results from abusive outputs used in bare multisig.
💬 whycorn commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666370704)
> Concept ACK Primarily for same reasons outlined by @ChristopherA. Allows for including signature by a third party other than that signing the keys controlling the inputs. E.g., service provider. Promotes decentralization as otherwise users that want this feature must work with miners directly. May help reduce rate of UTXO growth that results from abusive outputs used in bare multisig.
have you considered looking at this: https://github.com/bitcoin/bitcoin/pull/28217
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666370704)
> Concept ACK Primarily for same reasons outlined by @ChristopherA. Allows for including signature by a third party other than that signing the keys controlling the inputs. E.g., service provider. Promotes decentralization as otherwise users that want this feature must work with miners directly. May help reduce rate of UTXO growth that results from abusive outputs used in bare multisig.
have you considered looking at this: https://github.com/bitcoin/bitcoin/pull/28217
💬 YellowRoseCx commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1666370902)
Those are good points but as for the first, my honest answer is because I
think it's complicated to use unless you use centralized or trust based
services which is completely against the Bitcoin ethos imo. Even though LN
uses the same currency/coin(bitcoin) as the Bitcoin Network, using it is
not actually using Bitcoin unless you're opening or closing channel. I've
been using bitcoin for over a decade and imo unless I can look up my
transaction on the Bitcoin blockchain connected to my BTC
...
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1666370902)
Those are good points but as for the first, my honest answer is because I
think it's complicated to use unless you use centralized or trust based
services which is completely against the Bitcoin ethos imo. Even though LN
uses the same currency/coin(bitcoin) as the Bitcoin Network, using it is
not actually using Bitcoin unless you're opening or closing channel. I've
been using bitcoin for over a decade and imo unless I can look up my
transaction on the Bitcoin blockchain connected to my BTC
...
💬 whycorn commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666371003)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666371003)
Concept ACK
📝 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.