💬 linkinparkrulz commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666294718)
>
Best practices in accordance with who?
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666294718)
>
Best practices in accordance with who?
💬 linkinparkrulz commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666295024)
"It would also promote the adoption of best practices."
Best practices in accordance with who?
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666295024)
"It would also promote the adoption of best practices."
Best practices in accordance with who?
💬 vostrnad commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666333797)
Bare multisig has one advantage over redeem/witness/leaf script multisig in that it's not necessary to backup all public keys/xpubs in order to reconstruct the spending script, the threshold number of private keys/xprvs is enough to recover funds.
Additionally, I don't think this change would really affect spam, as anyone determined to store raw data in unprunable outputs (as opposed to OP_RETURN or unused script branches) can just switch to a different standard output type while only sacrifi
...
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666333797)
Bare multisig has one advantage over redeem/witness/leaf script multisig in that it's not necessary to backup all public keys/xpubs in order to reconstruct the spending script, the threshold number of private keys/xprvs is enough to recover funds.
Additionally, I don't think this change would really affect spam, as anyone determined to store raw data in unprunable outputs (as opposed to OP_RETURN or unused script branches) can just switch to a different standard output type while only sacrifi
...
📝 maxwellcotto opened 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
...
✅ pinheadmz closed a pull request: "Create devcontainer.json"
(https://github.com/bitcoin/bitcoin/pull/28219)
(https://github.com/bitcoin/bitcoin/pull/28219)
💬 imacfan commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666352633)
Concept NACK
As a full node runner it's not acceptable to me to remove a data limit. Data limits are critical to making running a node accessible to as many as possible.
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666352633)
Concept NACK
As a full node runner it's not acceptable to me to remove a data limit. Data limits are critical to making running a node accessible to as many as possible.
💬 ns-xvrn commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666356763)
Concept NACK
Just because a protocol has unwanted steganography attacks, instead of deterring that - you're saying allow it with arms wide open. Totally unacceptable, this is not what Bitcoin protocol is for, as a full node operator - I don't want it.
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666356763)
Concept NACK
Just because a protocol has unwanted steganography attacks, instead of deterring that - you're saying allow it with arms wide open. Totally unacceptable, this is not what Bitcoin protocol is for, as a full node operator - I don't want it.
💬 jonatack commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#discussion_r1284948058)
As a minimum, the tests would need to pass (if there is rough consensus on the change).
<details><summary>example test update</summary><p>
```diff
diff --git a/src/test/script_p2sh_tests.cpp b/src/test/script_p2sh_tests.cpp
index 739ab75de36..4e1225452fb 100644
--- a/src/test/script_p2sh_tests.cpp
+++ b/src/test/script_p2sh_tests.cpp
@@ -201,7 +201,7 @@ BOOST_AUTO_TEST_CASE(set)
{
SignatureData empty;
BOOST_CHECK_MESSAGE(SignSignature(keystore, CTransaction(t
...
(https://github.com/bitcoin/bitcoin/pull/28217#discussion_r1284948058)
As a minimum, the tests would need to pass (if there is rough consensus on the change).
<details><summary>example test update</summary><p>
```diff
diff --git a/src/test/script_p2sh_tests.cpp b/src/test/script_p2sh_tests.cpp
index 739ab75de36..4e1225452fb 100644
--- a/src/test/script_p2sh_tests.cpp
+++ b/src/test/script_p2sh_tests.cpp
@@ -201,7 +201,7 @@ BOOST_AUTO_TEST_CASE(set)
{
SignatureData empty;
BOOST_CHECK_MESSAGE(SignSignature(keystore, CTransaction(t
...
💬 cesarmassri commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666362344)
> Bare multisig has one advantage over redeem/witness/leaf script multisig in that it's not necessary to backup all public keys/xpubs in order to reconstruct the spending script, the threshold number of private keys/xprvs is enough to recover funds.
>
> Additionally, I don't think this change would really affect spam, as anyone determined to store raw data in unprunable outputs (as opposed to OP_RETURN or unused script branches) can just switch to a different standard output type while only s
...
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666362344)
> Bare multisig has one advantage over redeem/witness/leaf script multisig in that it's not necessary to backup all public keys/xpubs in order to reconstruct the spending script, the threshold number of private keys/xprvs is enough to recover funds.
>
> Additionally, I don't think this change would really affect spam, as anyone determined to store raw data in unprunable outputs (as opposed to OP_RETURN or unused script branches) can just switch to a different standard output type while only s
...
💬 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
...