💬 luke-jr commented on pull request "Libstandardness (edition 2023)":
(https://github.com/bitcoin/bitcoin/pull/28220#issuecomment-1666554027)
Concept NACK.

> Bitcoin Core transaction relay policy.

This is not and should never become a thing. Every node has its own policies, and relying on any specific policy is broken by design.

💬 jonatack commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#discussion_r1285088823)
> PR updated.

You'll need to squash the updates required for the tests to pass into the same commit as the code change.

💬 zkfrio commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666560846)
> This is a slap in the face to everything Satoshi worked towards.

I agree Satoshi would never use witness or bare multisig or OP_RETURN. They preferred [coinbase](https://mempool.space/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f). Unfortunately only miners can use it.

💬 itme-brain commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666561974)
Concept ACK

The limit is nothing more than feel-good policy, people have been circumventing it forever.

Maybe if `OP_RETURN` never had an arbitrary 80 byte limit we would've never gotten JPEGs in tapscripts?

⚠️ Smiril opened an issue: "fuzz:crc32c::ExtendArm64 Undefined symbols for architecture arm64:"
(https://github.com/bitcoin/bitcoin/issues/28223)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

configure success
make failed



### Expected behaviour

make Failed

### Steps to reproduce

./configure --enable-fuzz --disable-asm
....
Build Options:
with external callbacks = no
with benchmarks = no
with tests = yes
with ctime tests = no
with coverage = no
with examples = no
module ecdh = no
modu
...

💬 russeree commented on pull request "Bech32 LocateErrors "Bech32 string too short" case":
(https://github.com/bitcoin/bitcoin/pull/28160#issuecomment-1666570008)
Thanks for your feedback.

Though the error locations for the too short condition are not aesthetically pleasing at longer lengths; it does look nicer at shorter lengths of a too short bech32 string.


### Rationale
The error_locations for this PR took inspiration from the current error_locations for the too long condition LocateErrors
that when triggered will display the positions of any ad
...

💬 jonatack commented on issue "fuzz:crc32c::ExtendArm64 Undefined symbols for architecture arm64:":
(https://github.com/bitcoin/bitcoin/issues/28223#issuecomment-1666570052)
Try this (from `doc/fuzzing.md`) -- it works for me with the same equipment.

```
./autogen.sh && ./configure --enable-fuzz --with-sanitizers=fuzzer,address,undefined --disable-asm CC=$(brew --prefix llvm)/bin/clang CXX=$(brew --prefix llvm)/bin/clang++ && make clean && make -j11
```

💬 coinables commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666582128)
NACK, zero data to back-up PR claim that disallowing non-multisig p2sh would reduce spam, pure conjecture. A quick review of block data shows insignificant amount of non-multisig p2sh usage (not spam). If they pay the fee, it's not spam.

💬 Fiach-Dubh commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666588537)
> NACK, zero data to back-up PR claim that disallowing non-multisig p2sh would reduce spam, pure conjecture. A quick review of block data shows insignificant amount of non-multisig p2sh usage (not spam). If they pay the fee, it's not spam.

with respect, I think there is [historical data AND precedent](https://blog.bitmex.com/dapps-or-only-bitcoin-transactions-the-2014-debate/) to suggest that default policies can reduce the amount of onchain spam. (ie the reduction in counterparty spam after
...

💬 1ma commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666594995)
> Concept ACK
>
> The limit is nothing more than feel-good policy, people have been circumventing it forever.
>
> Maybe if `OP_RETURN` never had an arbitrary 80 byte limit we would've never gotten JPEGs in tapscripts?

If `datacarriersize` is truly not effective in practice then surely there is no need for this PR at all, and it can be closed.

💬 luke-jr commented on pull request "init: Add option for rpccookie permissions (replace 26088)":
(https://github.com/bitcoin/bitcoin/pull/28167#discussion_r1285117079)
Isn't the leading 0 optional? (Also the user might want to setgid or something weird)

💬 luke-jr commented on pull request "init: Add option for rpccookie permissions (replace 26088)":
(https://github.com/bitcoin/bitcoin/pull/28167#discussion_r1285117042)
Not sure `StringToOctal` is the right place for this check.

💬 moonsettler commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666596259)
Concept NACK; trying to discourage vandalism via policy incentivizes the emergence of mempool alternatives which could have quiet nasty consequences down the line.

📝 TheCharlatan opened a pull request: "tests: Reset node context members on ~ChainTestingSetup"
(https://github.com/bitcoin/bitcoin/pull/28224)
The destruction/resetting of node context members in the tests should roughly follow the behavior of the `Shutdown` function in `init.cpp`.

This was originally requested by @MarcoFalke in this [comment](https://github.com/bitcoin/bitcoin/pull/25065#discussion_r890161249) in response to the [original pull request](https://github.com/bitcoin/bitcoin/pull/25065) introducing the `kernel::Context`.

💬 HenrikJannsen commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666600410)
> > Allows for including signature by a third party other than that signing the keys controlling the inputs. E.g., service provider.
>
> 🚩🚩🚩 Sounds like maybe this is tied to some kind of KYC nonsense?
>
> There shouldn't be a "service provider" to begin with. (And if you really need such a signature, you could put it INSIDE the data which is being hashed.)

Would be interesting to hear the concrete use cases those who propose that have in mind.
Sounds a bit like a feature request fr
...

💬 Fiach-Dubh commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666600900)
> Concept NACK; trying to discourage vandalism via policy incentivizes the emergence of mempool alternatives which could have quiet nasty consequences down the line.

ie. MAYBE some spammers pay out of band more, raising the cost in UX, time and sats for this kind of unwanted behavior.

I'm ok with that.

Because maybe a good chunk of them just stop altogether.

💬 vicariousdrama commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666602973)
@whycorn
> have you considered looking at this: #28217
Its under consideration but independent of this PR and feature.

@luke-jr
> 🚩🚩🚩 Sounds like maybe this is tied to some kind of KYC nonsense?
>
> There shouldn't be a "service provider" to begin with. (And if you really need such a signature, you could put it INSIDE the data which is being hashed.)
Your emotion appears to get the better of you at times with use of the 🚩🚩🚩. This has nothing to do with KYC. Furthermore, service pr
...

💬 moonsettler commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666604137)
hmm i sense a serious lack of adversarial thinking. let's see if anyone can figure out what the real problem is?

💬 iBeizsley commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666608914)
> If someone who has created a data set that is stored off chain wants to sign it for attestation and produce a hash and expose both signature and hash or a url to said data without associating to their own Bitcoin for privacy reasons, or prefer paying out of band in some other asset or even god forbid fiat to an intermediary, then they should be able to. Are you wanting to define specific constraints on a protocol within the data of an OP_RETURN, or just OP_RETURN itself? The arbitrary 80 char
...

💬 vicariousdrama commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666617014)
> > If someone who has created a data set that is stored off chain wants to sign it for attestation and produce a hash and expose both signature and hash or a url to said data without associating to their own Bitcoin for privacy reasons, or prefer paying out of band in some other asset or even god forbid fiat to an intermediary, then they should be able to. Are you wanting to define specific constraints on a protocol within the data of an OP_RETURN, or just OP_RETURN itself? The arbitrary 80 ch
...