💬 brunoerg commented on pull request "fuzz: improve `coinselection`":
(https://github.com/bitcoin/bitcoin/pull/27585#discussion_r1284796940)
Done!
(https://github.com/bitcoin/bitcoin/pull/27585#discussion_r1284796940)
Done!
💬 brunoerg commented on pull request "fuzz: improve `coinselection`":
(https://github.com/bitcoin/bitcoin/pull/27585#issuecomment-1666096855)
Force-pushed addressing @furszy's suggestion to check whether `GetChange` is always 0 for any BnB result.
(https://github.com/bitcoin/bitcoin/pull/27585#issuecomment-1666096855)
Force-pushed addressing @furszy's suggestion to check whether `GetChange` is always 0 for any BnB result.
💬 ekzyis commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1666104716)
> How long do you want Bitcoin users to stand waiting in a store before they can leave with their groceries?
Why is there no mention of the Lightning Network in this thread? Users should use the Lightning Network for instant payments which are also cheaper than onchain.
> To quote the whitepaper:
>
>> In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transacti
...
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1666104716)
> How long do you want Bitcoin users to stand waiting in a store before they can leave with their groceries?
Why is there no mention of the Lightning Network in this thread? Users should use the Lightning Network for instant payments which are also cheaper than onchain.
> To quote the whitepaper:
>
>> In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transacti
...
💬 RobinLinus commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666108973)
> individuals opposing this PR [...] dictate to all other people how they should and should not use Bitcoin
That's incorrect. Everyone clearly agrees that we want to use Bitcoin for transactions. In contrast, many people don't want to use it for storing arbitrary data, because that reduces the scalability of transactions.
Hacking non-transaction data into the chain _"dictates to all other people"_ that everyone has to download and store this data forever, which harms all users who want to u
...
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666108973)
> individuals opposing this PR [...] dictate to all other people how they should and should not use Bitcoin
That's incorrect. Everyone clearly agrees that we want to use Bitcoin for transactions. In contrast, many people don't want to use it for storing arbitrary data, because that reduces the scalability of transactions.
Hacking non-transaction data into the chain _"dictates to all other people"_ that everyone has to download and store this data forever, which harms all users who want to u
...
💬 RobinLinus commented on pull request "set DEFAULT_PERMIT_BAREMULTISIG to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666111581)
Concept ACK. Long overdue.
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666111581)
Concept ACK. Long overdue.
💬 1ma commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666120264)
> 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).
Personally I'd like that the developers chose a default mempool policy with a very hard stance on spam to try not to burden more than necessary the computing resources volunteered by node runners. And then provide a wide range of options to customize t
...
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666120264)
> 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).
Personally I'd like that the developers chose a default mempool policy with a very hard stance on spam to try not to burden more than necessary the computing resources volunteered by node runners. And then provide a wide range of options to customize t
...
💬 luke-jr commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666121084)
subpools
Jed Bridges
>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 si
...
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666121084)
subpools
Jed Bridges
>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 si
...
💬 luke-jr commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666121523)
>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 default, the obvi
...
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666121523)
>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 default, the obvi
...
💬 1ma commented on pull request "set DEFAULT_PERMIT_BAREMULTISIG to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666143754)
Concept ACK.
Bare multisig has not been used for doing multisig transactions in ages. Today their only known use is embedding arbitrary data in transactions that nodes cannot prune from the UTXO set, bloating it forever[^1]. Bare multisig should be treated as an attack vector on Bitcoin nodes, like other constructs that were deemed unsafe and disabled soon after the inception of Bitcoin.
[^1]: https://stampchain.io/
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666143754)
Concept ACK.
Bare multisig has not been used for doing multisig transactions in ages. Today their only known use is embedding arbitrary data in transactions that nodes cannot prune from the UTXO set, bloating it forever[^1]. Bare multisig should be treated as an attack vector on Bitcoin nodes, like other constructs that were deemed unsafe and disabled soon after the inception of Bitcoin.
[^1]: https://stampchain.io/
💬 whycorn commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666162624)
Peter's inflationista vibes in full swing, I don't want spam on my full node. Close this ASAP.
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666162624)
Peter's inflationista vibes in full swing, I don't want spam on my full node. Close this ASAP.
💬 whycorn commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666176725)
Someone exploiting covert channels to spam vs. simply welcoming all the spam. There's a difference in that.
NACK squared.
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666176725)
Someone exploiting covert channels to spam vs. simply welcoming all the spam. There's a difference in that.
NACK squared.
📝 ryanofsky opened a pull request: "assumeutxo cleanup: Move IsInitialBlockDownload & NotifyHeaderTip to ChainstateManager"
(https://github.com/bitcoin/bitcoin/pull/28218)
This change makes `IsInitialBlockDownload` and `NotifyHeaderTip` functions no longer tied to individual `Chainstate` objects. It makes them work with the `ChainstateManager` object instead so code is simpler and it is no longer possible to call them incorrectly with an inactive `Chainstate`.
This change also makes `m_cached_finished_ibd` caching easier to reason about, because now there is only one cached value instead of two (for background and snapshot chainstates) so the cached IBD state n
...
(https://github.com/bitcoin/bitcoin/pull/28218)
This change makes `IsInitialBlockDownload` and `NotifyHeaderTip` functions no longer tied to individual `Chainstate` objects. It makes them work with the `ChainstateManager` object instead so code is simpler and it is no longer possible to call them incorrectly with an inactive `Chainstate`.
This change also makes `m_cached_finished_ibd` caching easier to reason about, because now there is only one cached value instead of two (for background and snapshot chainstates) so the cached IBD state n
...
💬 cbergqvist commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666192859)
Concept NACK
@ChristopherA wrote:
> My goal is not "non-bitcoin stuff". My specific challenge is that Lightning and Nostr use public keys in a persistent way that are not rotatable, which is a bad cryptographic practice. By committing to a rotated key and some other cryptographic in advance in L1, they could be. I believe this could be as small as a signed hash and a little metadata. However, this is larger than 80-byte limit in OP_RETURN. I can now put it into an inscription-style transacti
...
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666192859)
Concept NACK
@ChristopherA wrote:
> My goal is not "non-bitcoin stuff". My specific challenge is that Lightning and Nostr use public keys in a persistent way that are not rotatable, which is a bad cryptographic practice. By committing to a rotated key and some other cryptographic in advance in L1, they could be. I believe this could be as small as a signed hash and a little metadata. However, this is larger than 80-byte limit in OP_RETURN. I can now put it into an inscription-style transacti
...
💬 zkfrio commented on pull request "set DEFAULT_PERMIT_BAREMULTISIG to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666216446)
This change only affects P2P not blockchain. If bare multisig has no use case, why does it even exist in Bitcoin?
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666216446)
This change only affects P2P not blockchain. If bare multisig has no use case, why does it even exist in Bitcoin?
💬 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.