💬 Crazyk031 commented on pull request "set DEFAULT_PERMIT_BAREMULTISIG to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666218117)
No transaction on the Bitcoin network is spam, what a bunch of censorshipnists..
This is not Bitcoin..
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666218117)
No transaction on the Bitcoin network is spam, what a bunch of censorshipnists..
This is not Bitcoin..
💬 Sun0fABeach commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666235310)
Concept ACK
Very important step to close this attack vector.
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666235310)
Concept ACK
Very important step to close this attack vector.
💬 HenrikJannsen commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666252994)
Concept NACK
I also do not see any reason why 80 bytes is not enough for the use cases which makes sense.
Making life for spammers easier is not our task. Better put effort into how to make it harder and more inconvenient for them to spam the blockchain. E.g. by making node options to block abusive behavior more popular (like using `permitbaremultisig=0` as mentioned here https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665903498). Their business models will suffer if their suc
...
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666252994)
Concept NACK
I also do not see any reason why 80 bytes is not enough for the use cases which makes sense.
Making life for spammers easier is not our task. Better put effort into how to make it harder and more inconvenient for them to spam the blockchain. E.g. by making node options to block abusive behavior more popular (like using `permitbaremultisig=0` as mentioned here https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665903498). Their business models will suffer if their suc
...
💬 HenrikJannsen commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666257468)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666257468)
Concept ACK
💬 furszy commented on pull request "indexes: Stop using node internal types and locking cs_main, improve sync logic":
(https://github.com/bitcoin/bitcoin/pull/24230#discussion_r1284902580)
> Yes, I am definitely looking for suggestions on how many of the first commits it would make sense to split off into a separate PR.
Ok cool. I suggested to decouple this commit only because I'm going commit by commit and it seems like an easy step forward, but will keep moving forward.
> But just to be clear, there isn't a bug here, just suboptimal behavior. If -reindex-chainstate is used and there are still block-connected notifications waiting in the queue when the index is started, it
...
(https://github.com/bitcoin/bitcoin/pull/24230#discussion_r1284902580)
> Yes, I am definitely looking for suggestions on how many of the first commits it would make sense to split off into a separate PR.
Ok cool. I suggested to decouple this commit only because I'm going commit by commit and it seems like an easy step forward, but will keep moving forward.
> But just to be clear, there isn't a bug here, just suboptimal behavior. If -reindex-chainstate is used and there are still block-connected notifications waiting in the queue when the index is started, it
...
💬 hsjoberg commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666268867)
Concept ACK.
It's absurd to keep such strict size limitations when ordinal inscriptions are abusing witness space and witness discount anyway.
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666268867)
Concept ACK.
It's absurd to keep such strict size limitations when ordinal inscriptions are abusing witness space and witness discount anyway.
💬 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