💬 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.
(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
...
(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?
(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
...
(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
...
(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
...
💬 iBeizsley commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666619330)
> The size of OP_RETURN should ideally be larger to accommodate both a hash, and a reference to something outside of Bitcoin as the smallest way to make that reference / consume the least space.
You can store 80 bytes in an op return. A SHA256 hash is 32 bytes.
Why do you need more than 48 bytes for a reference?
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666619330)
> The size of OP_RETURN should ideally be larger to accommodate both a hash, and a reference to something outside of Bitcoin as the smallest way to make that reference / consume the least space.
You can store 80 bytes in an op return. A SHA256 hash is 32 bytes.
Why do you need more than 48 bytes for a reference?
💬 achow101 commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666620826)
Leaning towards Concept ACK
Bare multisigs are generally unusable to the vast majority of wallet software, if not all of them. They do not have an address type so the vast majority of users are completely unable to send to them. Sending to such requires specialized software and quite a bit of communication in order to get the script right. It requires some technical knowhow on the sender side to do correctly.
Arguably the same should be done for P2PK outputs as well for the same reasons.
...
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666620826)
Leaning towards Concept ACK
Bare multisigs are generally unusable to the vast majority of wallet software, if not all of them. They do not have an address type so the vast majority of users are completely unable to send to them. Sending to such requires specialized software and quite a bit of communication in order to get the script right. It requires some technical knowhow on the sender side to do correctly.
Arguably the same should be done for P2PK outputs as well for the same reasons.
...
💬 vicariousdrama commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666623631)
> You can store 80 bytes in an op return. A SHA256 hash is 32 bytes.
>
> Why do you need more than 48 bytes for a reference?
Varies depending on the actual URI
Assuming a SHA-1 hash of the following, but stored in binary form of 20 bytes
0e7364296be76d9ce5bc53dee6a15024d139760c
How should something like this be stored in 60 bytes
https://github.com/PoodleLabs/PoodleLabs.BitcoinBinaryVerificationScripts
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666623631)
> You can store 80 bytes in an op return. A SHA256 hash is 32 bytes.
>
> Why do you need more than 48 bytes for a reference?
Varies depending on the actual URI
Assuming a SHA-1 hash of the following, but stored in binary form of 20 bytes
0e7364296be76d9ce5bc53dee6a15024d139760c
How should something like this be stored in 60 bytes
https://github.com/PoodleLabs/PoodleLabs.BitcoinBinaryVerificationScripts
💬 luke-jr commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666624588)
It shouldn't be. Transaction keys are not URIs.
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666624588)
It shouldn't be. Transaction keys are not URIs.
💬 RicYashiroLee commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666625863)
> > The size of OP_RETURN should ideally be larger to accommodate both a hash, and a reference to something outside of Bitcoin as the smallest way to make that reference / consume the least space.
>
> You can store 80 bytes in an op return. A SHA256 hash is 32 bytes.
>
> Why do you need more than 48 bytes for a reference?
Mostly, Bitcoin's TINY SCOPE has no space for unrelated non-primary garbage data, desincentivizes bitcoiners of running full nodes and implicitly hurt Bitcoin's true d
...
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666625863)
> > The size of OP_RETURN should ideally be larger to accommodate both a hash, and a reference to something outside of Bitcoin as the smallest way to make that reference / consume the least space.
>
> You can store 80 bytes in an op return. A SHA256 hash is 32 bytes.
>
> Why do you need more than 48 bytes for a reference?
Mostly, Bitcoin's TINY SCOPE has no space for unrelated non-primary garbage data, desincentivizes bitcoiners of running full nodes and implicitly hurt Bitcoin's true d
...
💬 iBeizsley commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666629910)
> > You can store 80 bytes in an op return. A SHA256 hash is 32 bytes.
> > Why do you need more than 48 bytes for a reference?
>
> Varies depending on the actual URI
>
> Assuming a SHA-1 hash of the following, but stored in binary form of 20 bytes 0e7364296be76d9ce5bc53dee6a15024d139760c
>
> How should something like this be stored in 60 bytes https://github.com/PoodleLabs/PoodleLabs.BitcoinBinaryVerificationScripts
The hash itself can act as a resource identifier, and the following
...
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666629910)
> > You can store 80 bytes in an op return. A SHA256 hash is 32 bytes.
> > Why do you need more than 48 bytes for a reference?
>
> Varies depending on the actual URI
>
> Assuming a SHA-1 hash of the following, but stored in binary form of 20 bytes 0e7364296be76d9ce5bc53dee6a15024d139760c
>
> How should something like this be stored in 60 bytes https://github.com/PoodleLabs/PoodleLabs.BitcoinBinaryVerificationScripts
The hash itself can act as a resource identifier, and the following
...
💬 coinables commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666668653)
> > 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
...
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666668653)
> > 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
...
💬 Symphonic3 commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666722223)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666722223)
Concept ACK
💬 YellowRoseCx commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1666725276)
> > why not focus efforts on reducing the need for Replace by Fee to begin with?
>
> As I and others have explained above in the linked resources, eg https://petertodd.org/2023/fullrbf-multiparty-protocols and https://petertodd.org/2023/why-you-should-run-mempoolfullrbf, it is impossible to eliminate the need for transaction replacement.
After reading your blog posts and thinking about it for the day, I've got some questions about it if you don't mind.
One of the issues you write about i
...
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1666725276)
> > why not focus efforts on reducing the need for Replace by Fee to begin with?
>
> As I and others have explained above in the linked resources, eg https://petertodd.org/2023/fullrbf-multiparty-protocols and https://petertodd.org/2023/why-you-should-run-mempoolfullrbf, it is impossible to eliminate the need for transaction replacement.
After reading your blog posts and thinking about it for the day, I've got some questions about it if you don't mind.
One of the issues you write about i
...
📝 martinus opened a pull request: "util/blockstorage: Add `TRACE_RAII`, slightly faster -reindex-chainstate with CBufferedFile"
(https://github.com/bitcoin/bitcoin/pull/28226)
TLDR:
* Adds a `TRACE_RAII` macro to easily trace runtime of a code block.
* Switch to `CBufferedFile` in `BlockManager::ReadBlockFromDisk` is slightly faster:
* 9% faster unserialization => * 1.2% faster `-reindex-chainstate`
---
While profiling `-reindex-changestate` I saw lots of `fread()` calls in in `BlockManager::ReadBlockFromDisk`. This replaces the use of `CAutoFile` with `CBufferedFile` with a small buffer, leading to much fewer calls to
`fread()`, which gives a little speedup
...
(https://github.com/bitcoin/bitcoin/pull/28226)
TLDR:
* Adds a `TRACE_RAII` macro to easily trace runtime of a code block.
* Switch to `CBufferedFile` in `BlockManager::ReadBlockFromDisk` is slightly faster:
* 9% faster unserialization => * 1.2% faster `-reindex-chainstate`
---
While profiling `-reindex-changestate` I saw lots of `fread()` calls in in `BlockManager::ReadBlockFromDisk`. This replaces the use of `CAutoFile` with `CBufferedFile` with a small buffer, leading to much fewer calls to
`fread()`, which gives a little speedup
...
💬 MarcoFalke commented on pull request "util/blockstorage: Add `TRACE_RAII`, slightly faster -reindex-chainstate with CBufferedFile":
(https://github.com/bitcoin/bitcoin/pull/28226#issuecomment-1666759670)
Shouldn't `std::fread` be already cached? I could imagine the result to be different on different hardware? Also, `-reindex-chainstate` seems rare enough to not spend time to optimize its runtime? Going further, if the only goal of `CBufferedFile` is to speed up `-reindex` by 1%, we could consider removing it. Since the implementation is put in the header file of `streams.h`, removing it could reduce peak compile memory usage by .5% and compilation speed by .3% on every fresh compilation IIRC. O
...
(https://github.com/bitcoin/bitcoin/pull/28226#issuecomment-1666759670)
Shouldn't `std::fread` be already cached? I could imagine the result to be different on different hardware? Also, `-reindex-chainstate` seems rare enough to not spend time to optimize its runtime? Going further, if the only goal of `CBufferedFile` is to speed up `-reindex` by 1%, we could consider removing it. Since the implementation is put in the header file of `streams.h`, removing it could reduce peak compile memory usage by .5% and compilation speed by .3% on every fresh compilation IIRC. O
...
💬 MarcoFalke commented on issue "fuzz:crc32c::ExtendArm64 Undefined symbols for architecture arm64:":
(https://github.com/bitcoin/bitcoin/issues/28223#issuecomment-1666762164)
Closing for now. Let us know if this is still an issue or if you have any other questions.
(https://github.com/bitcoin/bitcoin/issues/28223#issuecomment-1666762164)
Closing for now. Let us know if this is still an issue or if you have any other questions.
✅ MarcoFalke closed an issue: "fuzz:crc32c::ExtendArm64 Undefined symbols for architecture arm64:"
(https://github.com/bitcoin/bitcoin/issues/28223)
(https://github.com/bitcoin/bitcoin/issues/28223)
💬 MarcoFalke commented on pull request "Bump python minimum version to 3.9":
(https://github.com/bitcoin/bitcoin/pull/28211#issuecomment-1666771306)
> Isn't Stream a rolling release? What about RHEL?
I don't think Stream it is a rolling release. It should ship all the same package *versions* as the corresponding RHEL release (however, the binaries may not be bit-by-bit-identical).
I've adjusted the pull request description to say `CentOS-like 8/9`.
You can verify it locally by running a fresh install of CentOS 9 Stream / Alma Linux 9 / Rocky Linux 9 and typing `python3 --version`. For me, it gives: `Python 3.9.17`. Trying to install
...
(https://github.com/bitcoin/bitcoin/pull/28211#issuecomment-1666771306)
> Isn't Stream a rolling release? What about RHEL?
I don't think Stream it is a rolling release. It should ship all the same package *versions* as the corresponding RHEL release (however, the binaries may not be bit-by-bit-identical).
I've adjusted the pull request description to say `CentOS-like 8/9`.
You can verify it locally by running a fresh install of CentOS 9 Stream / Alma Linux 9 / Rocky Linux 9 and typing `python3 --version`. For me, it gives: `Python 3.9.17`. Trying to install
...
💬 MarcoFalke commented on pull request "mempool: Persist with XOR":
(https://github.com/bitcoin/bitcoin/pull/28207#issuecomment-1666779214)
> (Although downgrading might be something we want to support?)
It is. You can simply set `-persistmempoolv1=1`.
(https://github.com/bitcoin/bitcoin/pull/28207#issuecomment-1666779214)
> (Although downgrading might be something we want to support?)
It is. You can simply set `-persistmempoolv1=1`.