💬 russeree commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1681361730)
@Retropex
> @russeree you seem obstinate in believing that I'm trying to force things, that's not the case.
Sorry for misinterpreting your statement this is what threw me off...
> Unfortunately despite the fact that this is not an isolated request (almost) no developer has helped us on the subject.
conveys a sense of bias or at least a perspective of disappointment. The term "unfortunately" connotes a negative view on the situation, implying that the outcome or response (or lack the
...
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1681361730)
@Retropex
> @russeree you seem obstinate in believing that I'm trying to force things, that's not the case.
Sorry for misinterpreting your statement this is what threw me off...
> Unfortunately despite the fact that this is not an isolated request (almost) no developer has helped us on the subject.
conveys a sense of bias or at least a perspective of disappointment. The term "unfortunately" connotes a negative view on the situation, implying that the outcome or response (or lack the
...
💬 fjahr commented on pull request "lint: fix custom mypy cache dir setting":
(https://github.com/bitcoin/bitcoin/pull/28184#discussion_r1296511440)
That was the previous behavior. There is even an explicit line for this in our `.gitignore`. What would you like to do instead? Move it into `/test/cache/`?
(https://github.com/bitcoin/bitcoin/pull/28184#discussion_r1296511440)
That was the previous behavior. There is even an explicit line for this in our `.gitignore`. What would you like to do instead? Move it into `/test/cache/`?
💬 fjahr commented on pull request "lint: fix custom mypy cache dir setting":
(https://github.com/bitcoin/bitcoin/pull/28184#discussion_r1296516711)
This was added as part of #18210 but I didn't see an explanation given there. I think it is better to specify a location explicitly since the default is using the current directory which may be leading to unexpected results if this script is called from different contexts. But if we don't care about something like this, it may be removed.
(https://github.com/bitcoin/bitcoin/pull/28184#discussion_r1296516711)
This was added as part of #18210 but I didn't see an explanation given there. I think it is better to specify a location explicitly since the default is using the current directory which may be leading to unexpected results if this script is called from different contexts. But if we don't care about something like this, it may be removed.
💬 sipa commented on pull request "Descriptor unit tests and simplifications":
(https://github.com/bitcoin/bitcoin/pull/24361#issuecomment-1681381767)
Leaving this as up for grabs. I still think it's a good idea, but don't have time to pursue it now.
(https://github.com/bitcoin/bitcoin/pull/24361#issuecomment-1681381767)
Leaving this as up for grabs. I still think it's a good idea, but don't have time to pursue it now.
✅ sipa closed a pull request: "Descriptor unit tests and simplifications"
(https://github.com/bitcoin/bitcoin/pull/24361)
(https://github.com/bitcoin/bitcoin/pull/24361)
💬 sipa commented on pull request "Don't empty dbcache on prune flushes: >30% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1296524385)
If these were iterators into the map, rather than pointers to the value, I think you wouldn't need the `m_outpoint`.
(https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1296524385)
If these were iterators into the map, rather than pointers to the value, I think you wouldn't need the `m_outpoint`.
💬 sipa commented on pull request "net: transport abstraction":
(https://github.com/bitcoin/bitcoin/pull/28165#discussion_r1296525115)
Done.
(https://github.com/bitcoin/bitcoin/pull/28165#discussion_r1296525115)
Done.
💬 sipa commented on pull request "net: transport abstraction":
(https://github.com/bitcoin/bitcoin/pull/28165#discussion_r1296525550)
Actually just the second condition suffices (the entire expected message is moved to the transport). I've simplified the code accordingly.
(https://github.com/bitcoin/bitcoin/pull/28165#discussion_r1296525550)
Actually just the second condition suffices (the entire expected message is moved to the transport). I've simplified the code accordingly.
💬 sipa commented on pull request "net: transport abstraction":
(https://github.com/bitcoin/bitcoin/pull/28165#discussion_r1296526306)
I've moved the introduction of `have_next_message` to (a separate commit in) #28196, as it's not really necessary in this PR yet.
(https://github.com/bitcoin/bitcoin/pull/28165#discussion_r1296526306)
I've moved the introduction of `have_next_message` to (a separate commit in) #28196, as it's not really necessary in this PR yet.
💬 sipa commented on pull request "net: transport abstraction":
(https://github.com/bitcoin/bitcoin/pull/28165#discussion_r1296528645)
Done.
(https://github.com/bitcoin/bitcoin/pull/28165#discussion_r1296528645)
Done.
💬 russeree commented on issue "Improve the error message when an address cannot be parsed because it is for a different network ":
(https://github.com/bitcoin/bitcoin/issues/26290#issuecomment-1681429178)
Following up to my previous post there have been substantial changes since the last revision.
- An incorrect bech32 address error message now presents the
expected ChainParams hrp and network to the user.
- A Bech32 address with an incorrect ChainParams prefix is
not automatically handled as base58, increasing the accuracy
and readability of user facing error messages.
- An incorrect base58 address prefix now presents the user with the
expected prefixes for the cu
...
(https://github.com/bitcoin/bitcoin/issues/26290#issuecomment-1681429178)
Following up to my previous post there have been substantial changes since the last revision.
- An incorrect bech32 address error message now presents the
expected ChainParams hrp and network to the user.
- A Bech32 address with an incorrect ChainParams prefix is
not automatically handled as base58, increasing the accuracy
and readability of user facing error messages.
- An incorrect base58 address prefix now presents the user with the
expected prefixes for the cu
...
💬 RicYashiroLee commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1681436917)
> @Retropex
>
> > @russeree you seem obstinate in believing that I'm trying to force things, that's not the case.
>
> Sorry for misinterpreting your statement this is what threw me off...
>
> > Unfortunately despite the fact that this is not an isolated request (almost) no developer has helped us on the subject.
>
> conveys a sense of bias or at least a perspective of disappointment. The term "unfortunately" connotes a negative view on the situation, implying that the outcome or resp
...
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1681436917)
> @Retropex
>
> > @russeree you seem obstinate in believing that I'm trying to force things, that's not the case.
>
> Sorry for misinterpreting your statement this is what threw me off...
>
> > Unfortunately despite the fact that this is not an isolated request (almost) no developer has helped us on the subject.
>
> conveys a sense of bias or at least a perspective of disappointment. The term "unfortunately" connotes a negative view on the situation, implying that the outcome or resp
...
💬 ajtowns commented on pull request "Break up script/standard.{h/cpp}":
(https://github.com/bitcoin/bitcoin/pull/28244#issuecomment-1681438781)
ACK 91d924ede1b421df31c895f4f43359e453a09ca5
(https://github.com/bitcoin/bitcoin/pull/28244#issuecomment-1681438781)
ACK 91d924ede1b421df31c895f4f43359e453a09ca5
💬 ajtowns commented on pull request "doc: clarify that LOCK() does AssertLockNotHeld() internally":
(https://github.com/bitcoin/bitcoin/pull/27116#issuecomment-1681440075)
I lean lightly towards (1), but prefer "(0) keep this PR as is" over (2) or (3).
(https://github.com/bitcoin/bitcoin/pull/27116#issuecomment-1681440075)
I lean lightly towards (1), but prefer "(0) keep this PR as is" over (2) or (3).
💬 ajtowns commented on pull request "Update MANDATORY_SCRIPT_VERIFY_FLAGS":
(https://github.com/bitcoin/bitcoin/pull/26291#discussion_r1296582840)
Sure. Presuming #28244 is merged, will tweak the wording when rebasing on that
(https://github.com/bitcoin/bitcoin/pull/26291#discussion_r1296582840)
Sure. Presuming #28244 is merged, will tweak the wording when rebasing on that
💬 ajtowns commented on pull request "[no merge, meta] refactor: net/net processing split":
(https://github.com/bitcoin/bitcoin/pull/28252#issuecomment-1681482672)
I guess two other things might be worth thinking about:
- the approach I describe above maybe can be looked at as moving much of the low-level stuff into `CNode` (or `net_node.h`), leaving `net_processing` for the high-level logic about messages and peer state, and `net`/`CConnman` for the high-level logic about dealing with many peers. so it's still something of a low/high level split, just splitting at a different point. moving as much low-level logic into `CNode` as possible also helps en
...
(https://github.com/bitcoin/bitcoin/pull/28252#issuecomment-1681482672)
I guess two other things might be worth thinking about:
- the approach I describe above maybe can be looked at as moving much of the low-level stuff into `CNode` (or `net_node.h`), leaving `net_processing` for the high-level logic about messages and peer state, and `net`/`CConnman` for the high-level logic about dealing with many peers. so it's still something of a low/high level split, just splitting at a different point. moving as much low-level logic into `CNode` as possible also helps en
...
💬 ajtowns commented on issue "meta: Isolated fuzzing of net processing":
(https://github.com/bitcoin/bitcoin/issues/27502#issuecomment-1681492139)
> Mostly all code in `net_processing.cpp` (and relevant modules like orphanage, tx tracker) but excluding net, validation or mempool logic. Stubbing the latter out gives us control over testing net processing behavior related to these adjacent modules by being able to mock their behavior and state.
I guess the thing I'm wondering is if/how you get coverage on behaviours like "tx is missing witness data", "we got a tx via txid so can cancel out requests via wtxid", "compact block is invalid",
...
(https://github.com/bitcoin/bitcoin/issues/27502#issuecomment-1681492139)
> Mostly all code in `net_processing.cpp` (and relevant modules like orphanage, tx tracker) but excluding net, validation or mempool logic. Stubbing the latter out gives us control over testing net processing behavior related to these adjacent modules by being able to mock their behavior and state.
I guess the thing I'm wondering is if/how you get coverage on behaviours like "tx is missing witness data", "we got a tx via txid so can cancel out requests via wtxid", "compact block is invalid",
...
💬 ariard commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1681522508)
> I think you asking these questions inappropriately gives readers the impression
> that there actually are non-trivial examples of real businesses who are relying
> on unconfirmed transactions. The fact is in this entire thread no-one has been
> able to provide clear, convincing, evidence that this is true.
I think you have two layers of reasoning: a) browsing the matrix of alternatives solutions for unconfirmed transactions and b) the economics traffic of the use-cases which justifies to
...
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1681522508)
> I think you asking these questions inappropriately gives readers the impression
> that there actually are non-trivial examples of real businesses who are relying
> on unconfirmed transactions. The fact is in this entire thread no-one has been
> able to provide clear, convincing, evidence that this is true.
I think you have two layers of reasoning: a) browsing the matrix of alternatives solutions for unconfirmed transactions and b) the economics traffic of the use-cases which justifies to
...
💬 pcfreak30 commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1681546191)
This should summarize this whole debate which started from `laser-eyed maxis` Twitter accounts virtue signaling on Twitter and calling for miners to not mine ordinal transactions in Q1-Q2 this year.
`Bitcoin for me, but not for thee`. Respectfully, anyone who wants to dictate the `right` use of bitcoin for what I call frankly, the Church of Satoshi... needs to go and _kindly_... **fuck off**.
You are turning out to be no better than the central bankers you demonize in the process.
Innov
...
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1681546191)
This should summarize this whole debate which started from `laser-eyed maxis` Twitter accounts virtue signaling on Twitter and calling for miners to not mine ordinal transactions in Q1-Q2 this year.
`Bitcoin for me, but not for thee`. Respectfully, anyone who wants to dictate the `right` use of bitcoin for what I call frankly, the Church of Satoshi... needs to go and _kindly_... **fuck off**.
You are turning out to be no better than the central bankers you demonize in the process.
Innov
...
💬 xiaobolei commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1681561094)
Some Bitcoin Politicians are real "SPAMS"
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1681561094)
Some Bitcoin Politicians are real "SPAMS"