Bitcoin Core Github
43 subscribers
122K links
Download Telegram
💬 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
💬 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.
💬 RobinLinus commented on pull request "set DEFAULT_PERMIT_BAREMULTISIG to false":
(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.
💬 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);
```
💬 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
```
💬 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.
💬 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;
```
💬 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?
💬 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?
💬 achow101 commented on pull request "BIP324 ciphersuite":
(https://github.com/bitcoin/bitcoin/pull/28008#discussion_r1284733846)
In aa8cee93342ee857931afec9af3ff5dbd8ce7749 "crypto: add FSChaCha20Poly1305, rekeying wrapper around ChaCha20Poly1305"

This variable could live outside of the loop and just be reused every time.
💬 brunoerg commented on pull request "fuzz: improve `coinselection`":
(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.
💬 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
...
💬 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
...
💬 RobinLinus commented on pull request "set DEFAULT_PERMIT_BAREMULTISIG to false":
(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
...
💬 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
...
💬 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
...
💬 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/