💬 petertodd commented on issue "Cluster mempool, CPFP carveout, and V3 transaction policy":
(https://github.com/bitcoin/bitcoin/issues/29319#issuecomment-1923061666)
> @petertodd
>
> > Can you give a bit more detail on what challenges you think that'll pose?
>
> from my memory: "How this new replacement rule would behave if you have a parent in the "replace-by-feerate" half but the child is in the "replace-by-fee" one ?” see the conversation here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019839.html in past conversations we have assumed a “static” N blocks worth of mempool, unclear to me with your proposal if dynamic. i wond
...
(https://github.com/bitcoin/bitcoin/issues/29319#issuecomment-1923061666)
> @petertodd
>
> > Can you give a bit more detail on what challenges you think that'll pose?
>
> from my memory: "How this new replacement rule would behave if you have a parent in the "replace-by-feerate" half but the child is in the "replace-by-fee" one ?” see the conversation here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019839.html in past conversations we have assumed a “static” N blocks worth of mempool, unclear to me with your proposal if dynamic. i wond
...
💬 petertodd commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1923151784)
> I've heard similar arguments from many people, and I have to say I disagree. The miners need to follow the will of the users (especially the holders), or bitcoin cannot survive long-term. Mining pools are highly attuned to short-term interests, generally at the expense of long-term considerations. This is understandable given the competitive and unpredictable nature of proof-of-work pooled mining. A pool operator who tries to be a good citizen and caretake bitcoin's long-term interests will mo
...
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1923151784)
> I've heard similar arguments from many people, and I have to say I disagree. The miners need to follow the will of the users (especially the holders), or bitcoin cannot survive long-term. Mining pools are highly attuned to short-term interests, generally at the expense of long-term considerations. This is understandable given the competitive and unpredictable nature of proof-of-work pooled mining. A pool operator who tries to be a good citizen and caretake bitcoin's long-term interests will mo
...
💬 BitcoinMechanic commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1923175031)
The issue with (I hope) accidental conflation of "miners" with "pool operators" as you are doing @petertodd is that it makes a trivial task (getting a dozen people to flip a `1` to a `0`) seem insurmountable by implying that we are dealing with miners in general. We aren't.
As you point out, it is **extremely easy** to get three or four entities to do something like mempoolfullrbf=1.
The difference here is we aren't trying to route around network defaults, we are trying to have them be set
...
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1923175031)
The issue with (I hope) accidental conflation of "miners" with "pool operators" as you are doing @petertodd is that it makes a trivial task (getting a dozen people to flip a `1` to a `0`) seem insurmountable by implying that we are dealing with miners in general. We aren't.
As you point out, it is **extremely easy** to get three or four entities to do something like mempoolfullrbf=1.
The difference here is we aren't trying to route around network defaults, we are trying to have them be set
...
💬 petertodd commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1923231248)
> The issue with (I hope) accidental conflation of "miners" with "pool operators" as you are doing @petertodd is that it makes a trivial task (getting a dozen people to flip a `1` to a `0`) seem insurmountable by implying that we are dealing with miners in general. We aren't.
If it's so trivial, you should do that first: get a majority of hash power to set `-permitbaremultisig=0`. If you can, then you'd have a much better argument for this pull-req.
> As you point out, it is **extremely
...
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1923231248)
> The issue with (I hope) accidental conflation of "miners" with "pool operators" as you are doing @petertodd is that it makes a trivial task (getting a dozen people to flip a `1` to a `0`) seem insurmountable by implying that we are dealing with miners in general. We aren't.
If it's so trivial, you should do that first: get a majority of hash power to set `-permitbaremultisig=0`. If you can, then you'd have a much better argument for this pull-req.
> As you point out, it is **extremely
...
💬 BitcoinMechanic commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1923269102)
>If it's so trivial, you should do that first: get a majority of hash power to set -permitbaremultisig=0. If you can, then you'd have a much better argument for this pull-req.
Lobbying mining pools in order to backwards-rationalize and shoehorn changes in to bitcoin core itself is perhaps more efficient in that you get to take advantage of the awful centralization issue we have with pools currently, but is clearly not the correct way to go about things.
If you're going to assert that the c
...
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1923269102)
>If it's so trivial, you should do that first: get a majority of hash power to set -permitbaremultisig=0. If you can, then you'd have a much better argument for this pull-req.
Lobbying mining pools in order to backwards-rationalize and shoehorn changes in to bitcoin core itself is perhaps more efficient in that you get to take advantage of the awful centralization issue we have with pools currently, but is clearly not the correct way to go about things.
If you're going to assert that the c
...
💬 stratospher commented on pull request "test: make v2transport arg in addconnection mandatory and few cleanups":
(https://github.com/bitcoin/bitcoin/pull/29356#issuecomment-1923275862)
> Another possible alternative for addconnection's third parameter handling would be to take as default whatever is set by -v2transport, like we already do it for addnode (i.e. bool use_v2transport = self.MaybeArg<bool>(2).value_or(node_v2transport);).
@theStack, i went with the mandatory third parameter approach because:
1. this can be used only for interaction between python dummy peer(`P2PInterface`) and bitcoind(`TestNode`) on only regtest anyways.
2. we're indirectly passing whatever i
...
(https://github.com/bitcoin/bitcoin/pull/29356#issuecomment-1923275862)
> Another possible alternative for addconnection's third parameter handling would be to take as default whatever is set by -v2transport, like we already do it for addnode (i.e. bool use_v2transport = self.MaybeArg<bool>(2).value_or(node_v2transport);).
@theStack, i went with the mandatory third parameter approach because:
1. this can be used only for interaction between python dummy peer(`P2PInterface`) and bitcoind(`TestNode`) on only regtest anyways.
2. we're indirectly passing whatever i
...
💬 maflcko commented on pull request "Stratum v2 Noise Protocol":
(https://github.com/bitcoin/bitcoin/pull/29346#discussion_r1475695984)
> I'll look into replace `write` with `>>`.
`>>` means reading. You may want to try `<<`, if you want to write an object.
(https://github.com/bitcoin/bitcoin/pull/29346#discussion_r1475695984)
> I'll look into replace `write` with `>>`.
`>>` means reading. You may want to try `<<`, if you want to write an object.
💬 maflcko commented on pull request "assumeutxo, rpc: Add 'start' parameter to loadtxoutset":
(https://github.com/bitcoin/bitcoin/pull/28659#issuecomment-1923278780)
I think it is fine to not have an abort command for now, because currently it is also not possible to abort, unless the complete process is shut down. But up to you.
(https://github.com/bitcoin/bitcoin/pull/28659#issuecomment-1923278780)
I think it is fine to not have an abort command for now, because currently it is also not possible to abort, unless the complete process is shut down. But up to you.
💬 maflcko commented on pull request "log: Don't use scientific notation in log messages":
(https://github.com/bitcoin/bitcoin/pull/29254#issuecomment-1923279799)
lgtm
(https://github.com/bitcoin/bitcoin/pull/29254#issuecomment-1923279799)
lgtm
⚠️ ttiiggss opened an issue: "(website) Piotr Piasecki link to Testnet Faucet gives a errror 500."
(https://github.com/bitcoin/bitcoin/issues/29368)
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Current behaviour
Tried to claim some testnet coins, used the link [here](https://developer.bitcoin.org/examples/testing.html)
Got a error 500. Tried to contact Piotr Piasecki but cannot find details.
### Expected behaviour
Testnet Faucet link to resolve.
### Steps to reproduce
Click [This](https://tpfaucet.appspot.com/)
### Relevant log output
_No response_
### How did you obtain Bitcoin Core
...
(https://github.com/bitcoin/bitcoin/issues/29368)
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Current behaviour
Tried to claim some testnet coins, used the link [here](https://developer.bitcoin.org/examples/testing.html)
Got a error 500. Tried to contact Piotr Piasecki but cannot find details.
### Expected behaviour
Testnet Faucet link to resolve.
### Steps to reproduce
Click [This](https://tpfaucet.appspot.com/)
### Relevant log output
_No response_
### How did you obtain Bitcoin Core
...
✅ fanquake closed an issue: "(website) Piotr Piasecki link to Testnet Faucet gives a errror 500."
(https://github.com/bitcoin/bitcoin/issues/29368)
(https://github.com/bitcoin/bitcoin/issues/29368)
💬 glozow commented on pull request "log: Don't use scientific notation in log messages":
(https://github.com/bitcoin/bitcoin/pull/29254#issuecomment-1923383346)
> > lgtm ACK [c819a83](https://github.com/bitcoin/bitcoin/commit/c819a83b4d83413a31323c1304664ee4c228ca29). can you update the PR description?
>
> Updated.
Are you sure the 'before" is accurate?
(https://github.com/bitcoin/bitcoin/pull/29254#issuecomment-1923383346)
> > lgtm ACK [c819a83](https://github.com/bitcoin/bitcoin/commit/c819a83b4d83413a31323c1304664ee4c228ca29). can you update the PR description?
>
> Updated.
Are you sure the 'before" is accurate?
💬 fanquake commented on pull request "build: LLD based macOS toolchain":
(https://github.com/bitcoin/bitcoin/pull/21778#issuecomment-1923423102)
Squashed down the changes, and did some Guix cleanup.
We can entirely remove the GCC toolchain from the macOS build now. Apart from removing unused deps,
my other reason to do this was to make sure that `ld` wasn't even in the build environment, so couldn't be getting used over `lld`.
However this has come with a new issue. Qt now fails to build, because it's trying to build qmake with `g++`,
which no-longer exists. This would seem to be a bug in any case, because if we are using a clang
...
(https://github.com/bitcoin/bitcoin/pull/21778#issuecomment-1923423102)
Squashed down the changes, and did some Guix cleanup.
We can entirely remove the GCC toolchain from the macOS build now. Apart from removing unused deps,
my other reason to do this was to make sure that `ld` wasn't even in the build environment, so couldn't be getting used over `lld`.
However this has come with a new issue. Qt now fails to build, because it's trying to build qmake with `g++`,
which no-longer exists. This would seem to be a bug in any case, because if we are using a clang
...
💬 kristapsk commented on pull request "log: Don't use scientific notation in log messages":
(https://github.com/bitcoin/bitcoin/pull/29254#issuecomment-1923436808)
> > > lgtm ACK [c819a83](https://github.com/bitcoin/bitcoin/commit/c819a83b4d83413a31323c1304664ee4c228ca29). can you update the PR description?
> >
> >
> > Updated.
>
> Are you sure the 'before" is accurate?
Yes, `%g` results in using `%e` or `%f`, depending on what results in shorter string.
(https://github.com/bitcoin/bitcoin/pull/29254#issuecomment-1923436808)
> > > lgtm ACK [c819a83](https://github.com/bitcoin/bitcoin/commit/c819a83b4d83413a31323c1304664ee4c228ca29). can you update the PR description?
> >
> >
> > Updated.
>
> Are you sure the 'before" is accurate?
Yes, `%g` results in using `%e` or `%f`, depending on what results in shorter string.
👍 theStack approved a pull request: "test: make v2transport arg in addconnection mandatory and few cleanups"
(https://github.com/bitcoin/bitcoin/pull/29356#pullrequestreview-1858800304)
Code-review ACK e7fd70f4b6b163f4ad5b25b4da7fa79899245235
> > Another possible alternative for addconnection's third parameter handling would be to take as default whatever is set by -v2transport, like we already do it for addnode (i.e. bool use_v2transport = self.MaybeArg(2).value_or(node_v2transport);).
>
> @theStack, i went with the mandatory third parameter approach because:
>
> 1. this can be used only for interaction between python dummy peer(`P2PInterface`) and bitcoind(`TestNode`
...
(https://github.com/bitcoin/bitcoin/pull/29356#pullrequestreview-1858800304)
Code-review ACK e7fd70f4b6b163f4ad5b25b4da7fa79899245235
> > Another possible alternative for addconnection's third parameter handling would be to take as default whatever is set by -v2transport, like we already do it for addnode (i.e. bool use_v2transport = self.MaybeArg(2).value_or(node_v2transport);).
>
> @theStack, i went with the mandatory third parameter approach because:
>
> 1. this can be used only for interaction between python dummy peer(`P2PInterface`) and bitcoind(`TestNode`
...
👍 dergoegge approved a pull request: "refactor: Fix timedata includes"
(https://github.com/bitcoin/bitcoin/pull/29361#pullrequestreview-1858811371)
utACK fad0fafd5aca699cfab7673f8eb18211139aeb18
(https://github.com/bitcoin/bitcoin/pull/29361#pullrequestreview-1858811371)
utACK fad0fafd5aca699cfab7673f8eb18211139aeb18
👍 delta1 approved a pull request: "wallet: Set descriptors flag after migrating blank wallets"
(https://github.com/bitcoin/bitcoin/pull/29367#pullrequestreview-1858823743)
tested ACK 3904123da954f9ebd905de4129aec9f9bab9efc7
confirmed that the test assertion fails without the change to wallet.cpp
(https://github.com/bitcoin/bitcoin/pull/29367#pullrequestreview-1858823743)
tested ACK 3904123da954f9ebd905de4129aec9f9bab9efc7
confirmed that the test assertion fails without the change to wallet.cpp
💬 kristapsk commented on pull request "log: Don't use scientific notation in log messages":
(https://github.com/bitcoin/bitcoin/pull/29254#issuecomment-1923477085)
> > > > lgtm ACK [c819a83](https://github.com/bitcoin/bitcoin/commit/c819a83b4d83413a31323c1304664ee4c228ca29). can you update the PR description?
> > >
> > >
> > > Updated.
> >
> >
> > Are you sure the 'before" is accurate?
>
> Yes, `%g` results in using `%e` or `%f`, depending on what results in shorter string.
Oh, wait, no, accidentally removed precision for "before" when editing, double checked debug.log, fixed.
(https://github.com/bitcoin/bitcoin/pull/29254#issuecomment-1923477085)
> > > > lgtm ACK [c819a83](https://github.com/bitcoin/bitcoin/commit/c819a83b4d83413a31323c1304664ee4c228ca29). can you update the PR description?
> > >
> > >
> > > Updated.
> >
> >
> > Are you sure the 'before" is accurate?
>
> Yes, `%g` results in using `%e` or `%f`, depending on what results in shorter string.
Oh, wait, no, accidentally removed precision for "before" when editing, double checked debug.log, fixed.
💬 delta1 commented on pull request "doc: Assert that assumed-valid blocks are not fully valid in CheckBlockIndex()":
(https://github.com/bitcoin/bitcoin/pull/29355#issuecomment-1923498222)
concept ACK fa027e08f7be63c201f42d0e06160d2273b4a6dd
(https://github.com/bitcoin/bitcoin/pull/29355#issuecomment-1923498222)
concept ACK fa027e08f7be63c201f42d0e06160d2273b4a6dd
💬 Sjors commented on pull request "Stratum v2 Noise Protocol":
(https://github.com/bitcoin/bitcoin/pull/29346#discussion_r1475854412)
` << m_sig` works fine, so `m_sig` can live happily as a `std::array<unsigned char`
(https://github.com/bitcoin/bitcoin/pull/29346#discussion_r1475854412)
` << m_sig` works fine, so `m_sig` can live happily as a `std::array<unsigned char`