💬 vasild commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1665867224)
`6e6f83b0f7...36074c093b`: rebase, fix a bug where [we sent the transaction without the witness](https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1284610972), and extend the test to cover that
(https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1665867224)
`6e6f83b0f7...36074c093b`: rebase, fix a bug where [we sent the transaction without the witness](https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1284610972), and extend the test to cover that
💬 RobinLinus commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665884417)
> This creates many unprunable outputs
This is their pitch though _"Unprunable UTXO Art"_ . They are intentionally spamming the chain. Relaxing bitcoin's spam mitigations doesn't help against that.
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665884417)
> This creates many unprunable outputs
This is their pitch though _"Unprunable UTXO Art"_ . They are intentionally spamming the chain. Relaxing bitcoin's spam mitigations doesn't help against that.
💬 MajesticBank commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1665898833)
With having full-rbf by default privacy would be increased for transactions created by bitcoin core, this is very important pull request.
Maybe that's the thing we don't like in this proposal?
Anyone claiming they are accepting 0-conf bitcoin transaction over internet is spreading FUD and that having full-rbf by default does anything bad to their non-existent payment system.
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1665898833)
With having full-rbf by default privacy would be increased for transactions created by bitcoin core, this is very important pull request.
Maybe that's the thing we don't like in this proposal?
Anyone claiming they are accepting 0-conf bitcoin transaction over internet is spreading FUD and that having full-rbf by default does anything bad to their non-existent payment system.
💬 1ma commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665903498)
> For readers of the thread who are not familiar with the STAMPS community, people are going around the OP_RETURN limit and doing things like embedding data in bare multisig: https://mempool.space/tx/1c61f2d4000e1bc2ce27ec24e4fcbbb376c2bd19641e071403e68d84d48eea8a
This creates many unprunable outputs and takes up more blockspace, so its bad for block capacity and utxoset bloat.
The stamps "community" can only route around OP_RETURN because back in 2014 Mike Hearn derailed the discussion to m
...
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665903498)
> For readers of the thread who are not familiar with the STAMPS community, people are going around the OP_RETURN limit and doing things like embedding data in bare multisig: https://mempool.space/tx/1c61f2d4000e1bc2ce27ec24e4fcbbb376c2bd19641e071403e68d84d48eea8a
This creates many unprunable outputs and takes up more blockspace, so its bad for block capacity and utxoset bloat.
The stamps "community" can only route around OP_RETURN because back in 2014 Mike Hearn derailed the discussion to m
...
💬 RicYashiroLee commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665924680)
IMV from too many commentary I have seen already from Peter, this is just another massive example of altcoining mindset, of many wishful thinking ideas coming from Peter Todd, detrimental to Bitcoin Full Node Operators, and only giving, as a direct consequence, more power to a central hub of Core Devs who are in high risk of conflict of interests, as he is included in such risk group of service providers and centralizers, 'scaling' business oriented. Full Node operators, on the contrary, are the
...
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665924680)
IMV from too many commentary I have seen already from Peter, this is just another massive example of altcoining mindset, of many wishful thinking ideas coming from Peter Todd, detrimental to Bitcoin Full Node Operators, and only giving, as a direct consequence, more power to a central hub of Core Devs who are in high risk of conflict of interests, as he is included in such risk group of service providers and centralizers, 'scaling' business oriented. Full Node operators, on the contrary, are the
...
💬 YellowRoseCx commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1665933394)
> With having full-rbf by default privacy would be increased for transactions created by bitcoin core, this is very important pull request.
>
> Maybe that's the thing we don't like in this proposal?
>
> Anyone claiming they are accepting 0-conf bitcoin transaction over internet is spreading FUD and that having full-rbf by default does anything bad to their non-existent payment system.
How long do you want Bitcoin users to stand waiting in a store before they can leave with their groceri
...
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1665933394)
> With having full-rbf by default privacy would be increased for transactions created by bitcoin core, this is very important pull request.
>
> Maybe that's the thing we don't like in this proposal?
>
> Anyone claiming they are accepting 0-conf bitcoin transaction over internet is spreading FUD and that having full-rbf by default does anything bad to their non-existent payment system.
How long do you want Bitcoin users to stand waiting in a store before they can leave with their groceri
...
💬 jonatack commented on pull request "refactor: Add util::Result failure values, multiple error and warning messages":
(https://github.com/bitcoin/bitcoin/pull/25665#discussion_r1284653088)
835f094 It looks like this empty vector might be declarable `constexpr`, at least with clang 16.0.6 arm64.
(https://github.com/bitcoin/bitcoin/pull/25665#discussion_r1284653088)
835f094 It looks like this empty vector might be declarable `constexpr`, at least with clang 16.0.6 arm64.
🤔 jonatack reviewed a pull request: "refactor: Add util::Result failure values, multiple error and warning messages"
(https://github.com/bitcoin/bitcoin/pull/25665#pullrequestreview-1563250744)
ACK 9e80d0b754a28733c79a52c8e0431616c31d071c
Nice documentation, code, and commit message improvements. Some non-blocking comments.
(https://github.com/bitcoin/bitcoin/pull/25665#pullrequestreview-1563250744)
ACK 9e80d0b754a28733c79a52c8e0431616c31d071c
Nice documentation, code, and commit message improvements. Some non-blocking comments.
💬 jonatack commented on pull request "refactor: Add util::Result failure values, multiple error and warning messages":
(https://github.com/bitcoin/bitcoin/pull/25665#discussion_r1284654294)
9ec1bda Can `Base` here be private instead of protected?
(https://github.com/bitcoin/bitcoin/pull/25665#discussion_r1284654294)
9ec1bda Can `Base` here be private instead of protected?
💬 jonatack commented on pull request "refactor: Add util::Result failure values, multiple error and warning messages":
(https://github.com/bitcoin/bitcoin/pull/25665#discussion_r1284664601)
9ec1bda
```
src/util/result.h:300: OT ==> TO, OF, OR, NOT
src/util/result.h:301: OT ==> TO, OF, OR, NOT
^ Warning: codespell identified likely spelling errors. Any false positives? Add them to the list of ignored words in test/lint/spelling.ignore-words.txt
```
(https://github.com/bitcoin/bitcoin/pull/25665#discussion_r1284664601)
9ec1bda
```
src/util/result.h:300: OT ==> TO, OF, OR, NOT
src/util/result.h:301: OT ==> TO, OF, OR, NOT
^ Warning: codespell identified likely spelling errors. Any false positives? Add them to the list of ignored words in test/lint/spelling.ignore-words.txt
```
💬 petertodd commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1665939229)
> With having full-rbf by default privacy would be increased for transactions created by bitcoin core, this is very important pull request.
That is correct. The BIP125 flag is a way to distinguish transactions from different wallets, and Chainanalysis certainly makes use of this. Deployment of Full-RBF would eliminate the need for any wallet to set BIP125 flags, allowing all wallets to eventually transition to having identical characteristics.
> Anyone claiming they are accepting 0-conf bi
...
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1665939229)
> With having full-rbf by default privacy would be increased for transactions created by bitcoin core, this is very important pull request.
That is correct. The BIP125 flag is a way to distinguish transactions from different wallets, and Chainanalysis certainly makes use of this. Deployment of Full-RBF would eliminate the need for any wallet to set BIP125 flags, allowing all wallets to eventually transition to having identical characteristics.
> Anyone claiming they are accepting 0-conf bi
...
💬 RicYashiroLee commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665951546)
> For readers of the thread who are not familiar with the STAMPS community, people are going around the OP_RETURN limit and doing things like embedding data in bare multisig: https://mempool.space/tx/1c61f2d4000e1bc2ce27ec24e4fcbbb376c2bd19641e071403e68d84d48eea8a This creates many unprunable outputs and takes up more blockspace, so its bad for block capacity and utxoset bloat.
The key word IMV is making things cumbersom for any out of scope use of Bitcoin, not more relaxed. And enable Node o
...
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665951546)
> For readers of the thread who are not familiar with the STAMPS community, people are going around the OP_RETURN limit and doing things like embedding data in bare multisig: https://mempool.space/tx/1c61f2d4000e1bc2ce27ec24e4fcbbb376c2bd19641e071403e68d84d48eea8a This creates many unprunable outputs and takes up more blockspace, so its bad for block capacity and utxoset bloat.
The key word IMV is making things cumbersom for any out of scope use of Bitcoin, not more relaxed. And enable Node o
...
💬 rot13maxi commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665971141)
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).
On Fri, Aug 4, 2023 at 1:25 PM, Richard Yashiro Lee ***@***.***(mailto:On Fri, Aug 4, 2023 at 1:25 PM, Richard Yashiro Lee <<a href=)> wrote:
>> For readers of the thread who are not familiar with the STAMPS community, people are going around the OP_RETUR
...
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665971141)
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).
On Fri, Aug 4, 2023 at 1:25 PM, Richard Yashiro Lee ***@***.***(mailto:On Fri, Aug 4, 2023 at 1:25 PM, Richard Yashiro Lee <<a href=)> wrote:
>> For readers of the thread who are not familiar with the STAMPS community, people are going around the OP_RETUR
...
💬 pinheadmz commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1284699462)
🕺 ah nice! I thought there might be something wrong with the transactions themselves, but when I restarted without sensitive relay everything broadcast fine. I didn't think of serialization being the issue! So, great catch.
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1284699462)
🕺 ah nice! I thought there might be something wrong with the transactions themselves, but when I restarted without sensitive relay everything broadcast fine. I didn't think of serialization being the issue! So, great catch.
💬 RicYashiroLee commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665978948)
> 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).
> […](#)
> On Fri, Aug 4, 2023 at 1:25 PM, Richard Yashiro Lee ***@***.***(mailto:On Fri, Aug 4, 2023 at 1:25 PM, Richard Yashiro Lee <<a href=)> wrote: > For readers of the thread who are not familiar with the STAMPS community, people are going around
...
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665978948)
> 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).
> […](#)
> On Fri, Aug 4, 2023 at 1:25 PM, Richard Yashiro Lee ***@***.***(mailto:On Fri, Aug 4, 2023 at 1:25 PM, Richard Yashiro Lee <<a href=)> wrote: > For readers of the thread who are not familiar with the STAMPS community, people are going around
...
💬 Sjors commented on pull request "Bump python minimum version to 3.9":
(https://github.com/bitcoin/bitcoin/pull/28211#issuecomment-1665980580)
Don't forget to bump `.python-version`
(https://github.com/bitcoin/bitcoin/pull/28211#issuecomment-1665980580)
Don't forget to bump `.python-version`
💬 RicYashiroLee commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665986103)
>
That is a twisted logic. It is not because it is already bad that anyone is centrally allowed to make it worse.
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665986103)
>
That is a twisted logic. It is not because it is already bad that anyone is centrally allowed to make it worse.
💬 nikicat commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665988600)
The individuals opposing this PR, believing they protect Bitcoin from centralization, ironically desire to dictate to all other people how they should and should not use Bitcoin. This type of standardness paternalism could eventually prompt the creation of other ways to include non-standard transactions in the blockchain, like a transaction marketplace for miners, which would totally eliminate standardness checks as a way to regulate Bitcoin.
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665988600)
The individuals opposing this PR, believing they protect Bitcoin from centralization, ironically desire to dictate to all other people how they should and should not use Bitcoin. This type of standardness paternalism could eventually prompt the creation of other ways to include non-standard transactions in the blockchain, like a transaction marketplace for miners, which would totally eliminate standardness checks as a way to regulate Bitcoin.
💬 RicYashiroLee commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665996720)
> > I understand that, it's a matter of trust. What I mean is that if the Bitcoin developers end up sanctioning such an obvious sabotage on the system I won't trust them as a group to continue developing the reference implementation.
>
> We still "sanction" even more "obvious sabotage" by the fact that bare multisig outputs are relayed by default. If you have a complaint, I'd suggest you start there rather than on OP_Return, a mechanism designed specifically for low impact and vigorously disc
...
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665996720)
> > I understand that, it's a matter of trust. What I mean is that if the Bitcoin developers end up sanctioning such an obvious sabotage on the system I won't trust them as a group to continue developing the reference implementation.
>
> We still "sanction" even more "obvious sabotage" by the fact that bare multisig outputs are relayed by default. If you have a complaint, I'd suggest you start there rather than on OP_Return, a mechanism designed specifically for low impact and vigorously disc
...
💬 RicYashiroLee commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666014187)
> The individuals opposing this PR, believing they protect Bitcoin from centralization, ironically desire to dictate to all other people how they should and should not use Bitcoin. This type of standardness paternalism could eventually prompt the creation of other ways to include non-standard transactions in the blockchain, like a transaction marketplace for miners, which would totally eliminate standardness checks as a way to regulate Bitcoin.
Every supposedly weakness of Bitcoin (IMV any ex
...
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666014187)
> The individuals opposing this PR, believing they protect Bitcoin from centralization, ironically desire to dictate to all other people how they should and should not use Bitcoin. This type of standardness paternalism could eventually prompt the creation of other ways to include non-standard transactions in the blockchain, like a transaction marketplace for miners, which would totally eliminate standardness checks as a way to regulate Bitcoin.
Every supposedly weakness of Bitcoin (IMV any ex
...