💬 sipa commented on pull request "crypto: more `Span<std::byte>` modernization & follow-ups":
(https://github.com/bitcoin/bitcoin/pull/28100#issuecomment-1677780358)
> @sipa could you update the PR dscription in regards to this, now that https://github.com/bitcoin/bitcoin/pull/28008 has been merged.
@fanquake Done.
(https://github.com/bitcoin/bitcoin/pull/28100#issuecomment-1677780358)
> @sipa could you update the PR dscription in regards to this, now that https://github.com/bitcoin/bitcoin/pull/28008 has been merged.
@fanquake Done.
⚠️ zydjohnHotmail opened an issue: "Any JavaScript functional test for this repo?"
(https://github.com/bitcoin/bitcoin/issues/28270)
### Motivation
Hi,
I am learning Bitcoin using this repo, and I have some experience with JavaScript, but my level with Python is very limited. I want to run some tests using JavaScript, but I found that all the functional tests are in Python. I want to know if it is possible to have the same functional tests in JavaScript.
Or give me some ideas on how can I do this with JavaScript?
For example for test_node.py and test_framework.py; if I want to use JavaScript with Bitcoin-core npm packag
...
(https://github.com/bitcoin/bitcoin/issues/28270)
### Motivation
Hi,
I am learning Bitcoin using this repo, and I have some experience with JavaScript, but my level with Python is very limited. I want to run some tests using JavaScript, but I found that all the functional tests are in Python. I want to know if it is possible to have the same functional tests in JavaScript.
Or give me some ideas on how can I do this with JavaScript?
For example for test_node.py and test_framework.py; if I want to use JavaScript with Bitcoin-core npm packag
...
💬 jonatack commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1677815858)
I think this change would also need a release note, though it could be done in a follow-up pull.
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1677815858)
I think this change would also need a release note, though it could be done in a follow-up pull.
💬 petertodd commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1677834108)
@iBeizsley
> If 37% of hash rate is mining full RBF, enabling full RBF is (currently) a move away from mempool consistency with majority hash rate.
You are mistaken. Think about this in terms of information: the purpose of a Bitcoin node is to widely distribute information in the form of transactions and blocks.
Full-RBF miners want to learn about full-RBF replacements. Non-full-RBF miners don't care about full-RBF replacements. But it does the no harm to receive that information: they ju
...
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1677834108)
@iBeizsley
> If 37% of hash rate is mining full RBF, enabling full RBF is (currently) a move away from mempool consistency with majority hash rate.
You are mistaken. Think about this in terms of information: the purpose of a Bitcoin node is to widely distribute information in the form of transactions and blocks.
Full-RBF miners want to learn about full-RBF replacements. Non-full-RBF miners don't care about full-RBF replacements. But it does the no harm to receive that information: they ju
...
💬 theStack commented on pull request "test: refactor: support sending funds with outpoint result":
(https://github.com/bitcoin/bitcoin/pull/28264#discussion_r1293818111)
Thanks, done.
(https://github.com/bitcoin/bitcoin/pull/28264#discussion_r1293818111)
Thanks, done.
💬 theStack commented on pull request "test: refactor: support sending funds with outpoint result":
(https://github.com/bitcoin/bitcoin/pull/28264#discussion_r1293818657)
Creating two different txs is intentional here, as otherwise the "Update psbts, should only have data for one input and not the other" test below would fail (if both inputs are part of the same tx, all data is available to both nodes). Added a comment to clarify.
(https://github.com/bitcoin/bitcoin/pull/28264#discussion_r1293818657)
Creating two different txs is intentional here, as otherwise the "Update psbts, should only have data for one input and not the other" test below would fail (if both inputs are part of the same tx, all data is available to both nodes). Added a comment to clarify.
🤔 mzumsande reviewed a pull request: "net: transport abstraction"
(https://github.com/bitcoin/bitcoin/pull/28165#pullrequestreview-1573562580)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/28165#pullrequestreview-1573562580)
Concept ACK
💬 mzumsande commented on pull request "net: transport abstraction":
(https://github.com/bitcoin/bitcoin/pull/28165#discussion_r1291310726)
commit 8f5c65a464b7ed47939a055a4b65286d20a5b126:
Could rename to `Complete()` to `DeserComplete()`, `DoneReceivingMessage()` or somthing similar to make it clearer that this function refers to deserialization side, now that both direction are in one class.
(https://github.com/bitcoin/bitcoin/pull/28165#discussion_r1291310726)
commit 8f5c65a464b7ed47939a055a4b65286d20a5b126:
Could rename to `Complete()` to `DeserComplete()`, `DoneReceivingMessage()` or somthing similar to make it clearer that this function refers to deserialization side, now that both direction are in one class.
💬 mzumsande commented on pull request "net: transport abstraction":
(https://github.com/bitcoin/bitcoin/pull/28165#discussion_r1293749015)
Why the second condition within the context of this unit test - It's not like it could have sent the message partially before? (same for the other Check below)
(https://github.com/bitcoin/bitcoin/pull/28165#discussion_r1293749015)
Why the second condition within the context of this unit test - It's not like it could have sent the message partially before? (same for the other Check below)
💬 mzumsande commented on pull request "net: transport abstraction":
(https://github.com/bitcoin/bitcoin/pull/28165#discussion_r1293814156)
It seems confusing and not ideal that a function called `ReceiveMsgFrom` has so much code dealing with the Send part, and also the side effect of flushing the send message buffer, when the goal is just to create a header for `ser_msg` to be able to receive that, but not to send anything. For example, it should be possible to call `ReceiveMsgFrom` in situations where the send buffer has unrelated contents. Maybe it'd be better to just have the relevant code (i.e. the old `prepareForTransport` dup
...
(https://github.com/bitcoin/bitcoin/pull/28165#discussion_r1293814156)
It seems confusing and not ideal that a function called `ReceiveMsgFrom` has so much code dealing with the Send part, and also the side effect of flushing the send message buffer, when the goal is just to create a header for `ser_msg` to be able to receive that, but not to send anything. For example, it should be possible to call `ReceiveMsgFrom` in situations where the send buffer has unrelated contents. Maybe it'd be better to just have the relevant code (i.e. the old `prepareForTransport` dup
...
💬 theStack commented on pull request "test: refactor: support sending funds with outpoint result":
(https://github.com/bitcoin/bitcoin/pull/28264#issuecomment-1677849699)
Rebased on master (tiny merge conflict due to #28232) and tackled the comments https://github.com/bitcoin/bitcoin/pull/28264#discussion_r1293818657 and https://github.com/bitcoin/bitcoin/pull/28264#discussion_r1293818111.
(https://github.com/bitcoin/bitcoin/pull/28264#issuecomment-1677849699)
Rebased on master (tiny merge conflict due to #28232) and tackled the comments https://github.com/bitcoin/bitcoin/pull/28264#discussion_r1293818657 and https://github.com/bitcoin/bitcoin/pull/28264#discussion_r1293818111.
💬 iBeizsley commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1677864859)
> You are mistaken. Think about this in terms of information: the purpose of a Bitcoin node is to widely distribute information in the form of transactions and blocks.
That's one potential goal of a node runner, but not all node runners, and not the only goal.
In fact, as far as I'm aware, all estimates point to an overwhelming majority of nodes _not_ relaying.
Running a node is an absolute necessity to interact with Bitcoin without any trust or dependence on third parties. Running a no
...
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1677864859)
> You are mistaken. Think about this in terms of information: the purpose of a Bitcoin node is to widely distribute information in the form of transactions and blocks.
That's one potential goal of a node runner, but not all node runners, and not the only goal.
In fact, as far as I'm aware, all estimates point to an overwhelming majority of nodes _not_ relaying.
Running a node is an absolute necessity to interact with Bitcoin without any trust or dependence on third parties. Running a no
...
💬 petertodd commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1677882273)
> That's one potential goal of a node runner, but not all node runners, and not the only goal.
>
> In fact, as far as I'm aware, all estimates point to an overwhelming majority of nodes _not_ relaying.
Citation needed.
The default behavior of Bitcoin Core is to relay transactions, whether or not the node is a listening node. If you believe that the overwhelming majority of nodes have disabled transaction relay (eg via `-blocksonly`), you need to cite that claim. That is **definitely** n
...
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1677882273)
> That's one potential goal of a node runner, but not all node runners, and not the only goal.
>
> In fact, as far as I'm aware, all estimates point to an overwhelming majority of nodes _not_ relaying.
Citation needed.
The default behavior of Bitcoin Core is to relay transactions, whether or not the node is a listening node. If you believe that the overwhelming majority of nodes have disabled transaction relay (eg via `-blocksonly`), you need to cite that claim. That is **definitely** n
...
💬 ValeZAA commented on issue "Auto detect IPv6 connectivity":
(https://github.com/bitcoin/bitcoin/issues/28061#issuecomment-1677889352)
> Concept ACK. Last time I checked a lots of ISPs in Latvia still don't support IPv6.
It does not matter. Migration to ipv6 happened. And anyway, here everyone mobile or optical fibre ISPs support ipv6.
(https://github.com/bitcoin/bitcoin/issues/28061#issuecomment-1677889352)
> Concept ACK. Last time I checked a lots of ISPs in Latvia still don't support IPv6.
It does not matter. Migration to ipv6 happened. And anyway, here everyone mobile or optical fibre ISPs support ipv6.
💬 real-or-random commented on pull request "ci: Run "macOS 11.0 [gui, no tests] [jammy]" job on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28265#discussion_r1293849607)
Yes, artifacts will be deleted after 90 days, but the problem with artifacts is that [they can only be downloaded by jobs in the same *run*](https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#downloading-or-deleting-artifacts). So artifacts are a good way to pass data around within the same run, but they cannot be used for caching across runs.
But I agree that using GHCR feels wrong.... Its purpose is to publish images, so it has a bit of an "official" chara
...
(https://github.com/bitcoin/bitcoin/pull/28265#discussion_r1293849607)
Yes, artifacts will be deleted after 90 days, but the problem with artifacts is that [they can only be downloaded by jobs in the same *run*](https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#downloading-or-deleting-artifacts). So artifacts are a good way to pass data around within the same run, but they cannot be used for caching across runs.
But I agree that using GHCR feels wrong.... Its purpose is to publish images, so it has a bit of an "official" chara
...
💬 hernanmarino commented on pull request "Wallet : Allow user to navigate options while encrypting at creation":
(https://github.com/bitcoin-core/gui/pull/722#issuecomment-1677897506)
Rolled back to undo changes detected by @pablomartin4btc . Now changes are at commit 78660e72001a2561c7ad3026367a69f65414dbd9 , the last one ACK ed by @jarolrod and others.
(https://github.com/bitcoin-core/gui/pull/722#issuecomment-1677897506)
Rolled back to undo changes detected by @pablomartin4btc . Now changes are at commit 78660e72001a2561c7ad3026367a69f65414dbd9 , the last one ACK ed by @jarolrod and others.
💬 ismaelsadeeq commented on pull request "test doc: tests `acceptstalefeeestimates` option is only supported on regtest chain":
(https://github.com/bitcoin/bitcoin/pull/28157#discussion_r1293862321)
Thank you @jonatack, I was able to recreate the same Error.
b24ffb05e42ec13ade193c9d7bea0def4296a4a8 should fix this.
(https://github.com/bitcoin/bitcoin/pull/28157#discussion_r1293862321)
Thank you @jonatack, I was able to recreate the same Error.
b24ffb05e42ec13ade193c9d7bea0def4296a4a8 should fix this.
💬 iBeizsley commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1677913513)
> > That's one potential goal of a node runner, but not all node runners, and not the only goal.
> Citation needed.
>
> The default behavior of Bitcoin Core is to relay transactions
Yes, bad wording. The majority are non-listening. Point being that those whose primary goal is maximum relay of blocks and transactions would be listening to achieve that.
> Anyway, full-RBF is only relevant to nodes that relay. Even if your claim was true, it would be irrelevant to this discussion.
Full RBF is
...
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1677913513)
> > That's one potential goal of a node runner, but not all node runners, and not the only goal.
> Citation needed.
>
> The default behavior of Bitcoin Core is to relay transactions
Yes, bad wording. The majority are non-listening. Point being that those whose primary goal is maximum relay of blocks and transactions would be listening to achieve that.
> Anyway, full-RBF is only relevant to nodes that relay. Even if your claim was true, it would be irrelevant to this discussion.
Full RBF is
...
💬 YellowRoseCx commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1677914442)
> > You are mistaken. Think about this in terms of information: the purpose of a Bitcoin node is to widely distribute information in the form of transactions and blocks.
>
> That's one potential goal of a node runner, but not all node runners, and not the only goal.
>
> In fact, as far as I'm aware, all estimates point to an overwhelming majority of nodes _not_ relaying.
>
> Running a node is an absolute necessity to interact with Bitcoin without any trust or dependence on third parties. Runn
...
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1677914442)
> > You are mistaken. Think about this in terms of information: the purpose of a Bitcoin node is to widely distribute information in the form of transactions and blocks.
>
> That's one potential goal of a node runner, but not all node runners, and not the only goal.
>
> In fact, as far as I'm aware, all estimates point to an overwhelming majority of nodes _not_ relaying.
>
> Running a node is an absolute necessity to interact with Bitcoin without any trust or dependence on third parties. Runn
...
💬 petertodd commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1677969873)
> > The default behavior of Bitcoin Core is to relay transactions
>
> Yes, bad (incorrect) wording. The majority are (/appear to be) non-listening. Point being that those whose primary goal is maximum relay of blocks and transactions would be listening to achieve that.
You're arguing a logical fallacy here. You might as well argue that the vast majority of people don't even run nodes, so there's no reason for any node to distribute any transactions or blocks at all.
The fact is, nodes t
...
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1677969873)
> > The default behavior of Bitcoin Core is to relay transactions
>
> Yes, bad (incorrect) wording. The majority are (/appear to be) non-listening. Point being that those whose primary goal is maximum relay of blocks and transactions would be listening to achieve that.
You're arguing a logical fallacy here. You might as well argue that the vast majority of people don't even run nodes, so there's no reason for any node to distribute any transactions or blocks at all.
The fact is, nodes t
...