💬 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
...
💬 iBeizsley commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666017121)
> 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).
A value of infinity is still a value. You're suggesting a change from current default policy. You're making a policy decision on behalf of others.
It should be configurable. We already have configuration options (one of which this PR _removes_). If a ch
...
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666017121)
> 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).
A value of infinity is still a value. You're suggesting a change from current default policy. You're making a policy decision on behalf of others.
It should be configurable. We already have configuration options (one of which this PR _removes_). If a ch
...
💬 RicYashiroLee commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666025993)
> > Concept NACK unless you keep the default at `MAX_OP_RETURN_RELAY`. Depending on adoption we can always drop that default later. No need to make pull requests more controversial than necessary.
>
> @ChristopherA is paying me $1000 for 10 hours work to do this pull-req. Since the other sub-change got mired in controversy, I decided to meet my client requirement in a time-efficient manner. Obviously, I can't promise to him that this will actually get merged. But I can promise to him that I'l
...
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666025993)
> > Concept NACK unless you keep the default at `MAX_OP_RETURN_RELAY`. Depending on adoption we can always drop that default later. No need to make pull requests more controversial than necessary.
>
> @ChristopherA is paying me $1000 for 10 hours work to do this pull-req. Since the other sub-change got mired in controversy, I decided to meet my client requirement in a time-efficient manner. Obviously, I can't promise to him that this will actually get merged. But I can promise to him that I'l
...
📝 Retropex opened a pull request: "set DEFAULT_PERMIT_BAREMULTISIG to false"
(https://github.com/bitcoin/bitcoin/pull/28217)
The default activation of the `permitbaremultisig` option proposes an enhancement for the Bitcoin network. By refusing non-P2SH multisignature transactions from the outset, this modification would contribute to reducing spam attempts and maintaining a healthy decentralization by discouraging undesirable activities. It would also promote the adoption of best practices.
This would strengthen the Bitcoin ecosystem by encouraging the use of compliant transactions.
(https://github.com/bitcoin/bitcoin/pull/28217)
The default activation of the `permitbaremultisig` option proposes an enhancement for the Bitcoin network. By refusing non-P2SH multisignature transactions from the outset, this modification would contribute to reducing spam attempts and maintaining a healthy decentralization by discouraging undesirable activities. It would also promote the adoption of best practices.
This would strengthen the Bitcoin ecosystem by encouraging the use of compliant transactions.
💬 Retropex commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666032195)
> Bitcoin Core is able to discard and not relay unconfirmed stamp transactions since March 2014
@1ma I think it's time to put this back on the table. #28217
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666032195)
> Bitcoin Core is able to discard and not relay unconfirmed stamp transactions since March 2014
@1ma I think it's time to put this back on the table. #28217
💬 luke-jr commented on pull request "set DEFAULT_PERMIT_BAREMULTISIG to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666056809)
Concept ACK; CI is failing, probably need to update some tests.
I'm not aware of any legitimate usage of bare multisig, so this should be a costless way to filter more spam. Knots has had this policy for years.
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666056809)
Concept ACK; CI is failing, probably need to update some tests.
I'm not aware of any legitimate usage of bare multisig, so this should be a costless way to filter more spam. Knots has had this policy for years.
💬 RobinLinus commented on pull request "set DEFAULT_PERMIT_BAREMULTISIG to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666069251)
Concept ACK. Great improvement
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666069251)
Concept ACK. Great improvement
🤔 jonatack reviewed a pull request: "net: Use serialization parameters for CAddress serialization"
(https://github.com/bitcoin/bitcoin/pull/25284#pullrequestreview-1563400593)
Initial tested approach ACK 6a99da9fa4a66e343df0910918da0ba9686d0fde. The template changes in b03572d8381 are nicely simplified from the original in #19503.
(https://github.com/bitcoin/bitcoin/pull/25284#pullrequestreview-1563400593)
Initial tested approach ACK 6a99da9fa4a66e343df0910918da0ba9686d0fde. The template changes in b03572d8381 are nicely simplified from the original in #19503.
💬 jonatack commented on pull request "net: Use serialization parameters for CAddress serialization":
(https://github.com/bitcoin/bitcoin/pull/25284#discussion_r1284769402)
6a99da9 If the `#if` directive is inversed
```
test/serialize_tests.cpp:281:22: error: use of undeclared identifier 'ParseUint32'; did you mean 'ParseUInt32'?
ok = ParseUint32(str, &data);
^~~~~~~~~~~
ParseUInt32
./util/strencodings.h:225:20: note: 'ParseUInt32' declared here
[[nodiscard]] bool ParseUInt32(std::string_view str, uint32_t *out);
```
(https://github.com/bitcoin/bitcoin/pull/25284#discussion_r1284769402)
6a99da9 If the `#if` directive is inversed
```
test/serialize_tests.cpp:281:22: error: use of undeclared identifier 'ParseUint32'; did you mean 'ParseUInt32'?
ok = ParseUint32(str, &data);
^~~~~~~~~~~
ParseUInt32
./util/strencodings.h:225:20: note: 'ParseUInt32' declared here
[[nodiscard]] bool ParseUInt32(std::string_view str, uint32_t *out);
```
💬 jonatack commented on pull request "net: Use serialization parameters for CAddress serialization":
(https://github.com/bitcoin/bitcoin/pull/25284#discussion_r1284741805)
ef03a51
```suggestion
/** Convert any argument to a reference to X, maintaining constness.
```
-----
also here
```diff
-/* ::GetSerializeSize implementations
+/** ::GetSerializeSize implementations
```
(https://github.com/bitcoin/bitcoin/pull/25284#discussion_r1284741805)
ef03a51
```suggestion
/** Convert any argument to a reference to X, maintaining constness.
```
-----
also here
```diff
-/* ::GetSerializeSize implementations
+/** ::GetSerializeSize implementations
```
💬 davidlick commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666078342)
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-1666078342)
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.
💬 achow101 commented on pull request "BIP324 ciphersuite":
(https://github.com/bitcoin/bitcoin/pull/28008#discussion_r1284753030)
In 9ff0768bdcca06836ccc673eacfa648e801930cb "crypto: add the ChaCha20Poly1305 AEAD as specified in RFC8439"
This could be made easier to read using `cipher.last()`.
```suggestion
if (timingsafe_bcmp(UCharCast(expected_tag), UCharCast(cipher.last(EXPANSION).data()), EXPANSION)) return false;
```
(https://github.com/bitcoin/bitcoin/pull/28008#discussion_r1284753030)
In 9ff0768bdcca06836ccc673eacfa648e801930cb "crypto: add the ChaCha20Poly1305 AEAD as specified in RFC8439"
This could be made easier to read using `cipher.last()`.
```suggestion
if (timingsafe_bcmp(UCharCast(expected_tag), UCharCast(cipher.last(EXPANSION).data()), EXPANSION)) return false;
```
💬 achow101 commented on pull request "BIP324 ciphersuite":
(https://github.com/bitcoin/bitcoin/pull/28008#discussion_r1284724692)
In 0fee267792eb8cbdd48ad78f1712420b5d8d905b "crypto: add FSChaCha20, a rekeying wrapper around ChaCha20"
We have `secure_allocator` which handles this cleaning when the object is destroyed, could we use that instead of having to remember to explicitly `memory_cleanse` secret data?
(https://github.com/bitcoin/bitcoin/pull/28008#discussion_r1284724692)
In 0fee267792eb8cbdd48ad78f1712420b5d8d905b "crypto: add FSChaCha20, a rekeying wrapper around ChaCha20"
We have `secure_allocator` which handles this cleaning when the object is destroyed, could we use that instead of having to remember to explicitly `memory_cleanse` secret data?
💬 achow101 commented on pull request "BIP324 ciphersuite":
(https://github.com/bitcoin/bitcoin/pull/28008#discussion_r1284765020)
In 990f0f8da92a2d11828a7c05ca93bf0520b2a95e "Add BIP324Cipher, encapsulating key agreement, derivation, and stream/AEAD ciphers"
Could you add a comment explaining what the values for `initiator` mean?
(https://github.com/bitcoin/bitcoin/pull/28008#discussion_r1284765020)
In 990f0f8da92a2d11828a7c05ca93bf0520b2a95e "Add BIP324Cipher, encapsulating key agreement, derivation, and stream/AEAD ciphers"
Could you add a comment explaining what the values for `initiator` mean?