💬 07510480632 commented on issue "[Feature] Allow gettxout to return information for spent outputs":
(https://github.com/bitcoin/bitcoin/issues/9641#issuecomment-1876001414)
heloelo289@gmail.com
(https://github.com/bitcoin/bitcoin/issues/9641#issuecomment-1876001414)
heloelo289@gmail.com
💬 luke-jr commented on pull request "Change Luke Dashjr seed to dashjr-list-of-p2p-nodes-maybe-malware.us":
(https://github.com/bitcoin/bitcoin/pull/29145#issuecomment-1876019669)
The DNS seeds resolve to IPs of random peers. It's entirely possible (and apparently reality) that some of those host malware. Putting `maybe-malware` in the name cautions users who might put the domain in a browser, that whatever loads could be malicious.
It seems like a low-cost improvement to avoid abuse IMO, but if there's a hard objection to it, I can come up with another domain for it.
(https://github.com/bitcoin/bitcoin/pull/29145#issuecomment-1876019669)
The DNS seeds resolve to IPs of random peers. It's entirely possible (and apparently reality) that some of those host malware. Putting `maybe-malware` in the name cautions users who might put the domain in a browser, that whatever loads could be malicious.
It seems like a low-cost improvement to avoid abuse IMO, but if there's a hard objection to it, I can come up with another domain for it.
💬 dergoegge commented on pull request "PoC: fuzz chainstate and block managers":
(https://github.com/bitcoin/bitcoin/pull/29158#discussion_r1441013417)
https://joshua.hu/fuzzing-with-memfd-createfd-fmemopen-syscall-function
The author of this post found that a ram disk is slower🚀
I/O syscalls are avoided with fmempopen and everything simply happens in userland.
(https://github.com/bitcoin/bitcoin/pull/29158#discussion_r1441013417)
https://joshua.hu/fuzzing-with-memfd-createfd-fmemopen-syscall-function
The author of this post found that a ram disk is slower🚀
I/O syscalls are avoided with fmempopen and everything simply happens in userland.
💬 luke-jr commented on pull request "Update libsecp256k1 subtree for 0.4.1 release":
(https://github.com/bitcoin/bitcoin/pull/29169#issuecomment-1876071373)
It makes a minor difference of reporting the correct version number. I agree with @hebasto on using the tag, but also agree with @fanquake on not having a policy that we must use tags.
(https://github.com/bitcoin/bitcoin/pull/29169#issuecomment-1876071373)
It makes a minor difference of reporting the correct version number. I agree with @hebasto on using the tag, but also agree with @fanquake on not having a policy that we must use tags.
💬 murchandamus commented on pull request "wallet, rpc: document and update `sendall` behavior around unconfirmed inputs":
(https://github.com/bitcoin/bitcoin/pull/28979#issuecomment-1876074359)
I don’t know why it could be failing here, it doesn’t seem to make sense that it would. Could you try to rebase?
(https://github.com/bitcoin/bitcoin/pull/28979#issuecomment-1876074359)
I don’t know why it could be failing here, it doesn’t seem to make sense that it would. Could you try to rebase?
💬 wizkid057 commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1876205236)
Interesting standard. I don't see anyone else disclosing their employer, investors, etc when replying here... and there are _definitely_ people commenting here who have clear conflicts of interest (mostly against this PR). So, I'm going to reject the entire premise of a suggestion that OCEAN associated people alone be required to disclose that. Perhaps if I see some more broad application of such a thing, I'd reconsider, but otherwise it's a pointless and ridiculous ask.
That said, I figure
...
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1876205236)
Interesting standard. I don't see anyone else disclosing their employer, investors, etc when replying here... and there are _definitely_ people commenting here who have clear conflicts of interest (mostly against this PR). So, I'm going to reject the entire premise of a suggestion that OCEAN associated people alone be required to disclose that. Perhaps if I see some more broad application of such a thing, I'd reconsider, but otherwise it's a pointless and ridiculous ask.
That said, I figure
...
💬 eragmus commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1876219233)
> That said, I figured my own affiliation was beyond obvious having been in the Bitcoin space for well over a decade, having previously run the Eligius pool with Luke, etc.
Not all of us, like myself, are so familiar with the mining ecosystem, so I had no idea who you were until I realized it for myself coincidentally.
> Interesting standard. I don't see anyone else disclosing their employer, investors, etc when replying here... Perhaps if I see some more broad application of such a thing, I'd
...
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1876219233)
> That said, I figured my own affiliation was beyond obvious having been in the Bitcoin space for well over a decade, having previously run the Eligius pool with Luke, etc.
Not all of us, like myself, are so familiar with the mining ecosystem, so I had no idea who you were until I realized it for myself coincidentally.
> Interesting standard. I don't see anyone else disclosing their employer, investors, etc when replying here... Perhaps if I see some more broad application of such a thing, I'd
...
💬 dzyphr commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1876220282)
Concept ACK
The current state of the datacarriersize exploit allows users of non-Bitcoin-related protocols to piggyback off of the good will of full node runners. Regular users pay for every single vByte and unrelated protocol users do not. This occurs while the unrelated protocol spams the UTXO set, creating an non-scalable setting for anyone looking to run infrastructure. Being as that a dense full node graph is vital to the success of Bitcoin as a network, it would be detrimental to continue
...
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1876220282)
Concept ACK
The current state of the datacarriersize exploit allows users of non-Bitcoin-related protocols to piggyback off of the good will of full node runners. Regular users pay for every single vByte and unrelated protocol users do not. This occurs while the unrelated protocol spams the UTXO set, creating an non-scalable setting for anyone looking to run infrastructure. Being as that a dense full node graph is vital to the success of Bitcoin as a network, it would be detrimental to continue
...
💬 petertodd commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1876316575)
On Wed, Jan 03, 2024 at 02:42:45AM -0800, Gloria Zhao wrote:
> > This kind of thinking is precisely the problem: you've listed a bunch of potential problems, without any discussion of how actual protocols are impacted by those problems.
>
> Peter, please read the [RBF improvements mailing list thread](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html) to get up to date on users' problems with RBF.
>
> Yes, v3 makes no sense if you think RBF is perfect today. I ag
...
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1876316575)
On Wed, Jan 03, 2024 at 02:42:45AM -0800, Gloria Zhao wrote:
> > This kind of thinking is precisely the problem: you've listed a bunch of potential problems, without any discussion of how actual protocols are impacted by those problems.
>
> Peter, please read the [RBF improvements mailing list thread](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html) to get up to date on users' problems with RBF.
>
> Yes, v3 makes no sense if you think RBF is perfect today. I ag
...
💬 petertodd commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1876380772)
On Wed, Jan 03, 2024 at 02:10:22AM -0800, Bastien Teinturier wrote:
> Thanks for your answers @petertodd.
>
> I think we may be talking a bit past each other in some of those comments, because most of this is too vague and ignores important low-level details.
> I'll try to highlight the most important high-level points below.
>
> > So if Alice wants to broadcast a commitment transaction, her version of the fee variants all take the funds for the fees from her balance, and Bob has given Alice a
...
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1876380772)
On Wed, Jan 03, 2024 at 02:10:22AM -0800, Bastien Teinturier wrote:
> Thanks for your answers @petertodd.
>
> I think we may be talking a bit past each other in some of those comments, because most of this is too vague and ignores important low-level details.
> I'll try to highlight the most important high-level points below.
>
> > So if Alice wants to broadcast a commitment transaction, her version of the fee variants all take the funds for the fees from her balance, and Bob has given Alice a
...
💬 maflcko commented on pull request "wallet, rpc: document and update `sendall` behavior around unconfirmed inputs":
(https://github.com/bitcoin/bitcoin/pull/28979#discussion_r1441426330)
I presume `self.def_wallet` is not equal to `self.wallet`, so a mempool sync is missing here, to allow for the transaction to "propagate" through the full validation interface queue.
(https://github.com/bitcoin/bitcoin/pull/28979#discussion_r1441426330)
I presume `self.def_wallet` is not equal to `self.wallet`, so a mempool sync is missing here, to allow for the transaction to "propagate" through the full validation interface queue.
🤔 stratospher reviewed a pull request: "net, cli: use v2transport for manual/addrfetch connections, add to -netinfo"
(https://github.com/bitcoin/bitcoin/pull/29058#pullrequestreview-1803647850)
tested ACK fb5bfed. addrfetch + manual connections aren't frequent and it would be useful to have this for transition to v2 one day.
used `-connect`, `-addnode`, `-seednode` and observed reconnections happening if other peer was v1 and no reconnection if other peer was v2. an interesting behaviour which i realised made sense was to keep retrying with v2 when latency issue failures happen on tor.
```
2024-01-04T06:14:58Z [net:debug] trying v2 connection "xyz" lastseen=0.0hrs
2024-01-04
...
(https://github.com/bitcoin/bitcoin/pull/29058#pullrequestreview-1803647850)
tested ACK fb5bfed. addrfetch + manual connections aren't frequent and it would be useful to have this for transition to v2 one day.
used `-connect`, `-addnode`, `-seednode` and observed reconnections happening if other peer was v1 and no reconnection if other peer was v2. an interesting behaviour which i realised made sense was to keep retrying with v2 when latency issue failures happen on tor.
```
2024-01-04T06:14:58Z [net:debug] trying v2 connection "xyz" lastseen=0.0hrs
2024-01-04
...
📝 Retropex opened a pull request: "doc: revert clarify -datacarriersize"
(https://github.com/bitcoin/bitcoin/pull/29173)
The latest update of the help text of `-datacarriersize` is incorrect.
The purpose of this standardization rule is not to target only the data contained in the raw scriptPubKey, but all forms of arbitrary data.
It is incorrect to change the description of this option if an attempt to update it was made without being merged.
Context:
The [first inscription](https://mempool.space/block/000000000000000000029730547464f056f8b6e2e0a02eaf69c24389983a04f5) appeared December 14, 2022 at the h
...
(https://github.com/bitcoin/bitcoin/pull/29173)
The latest update of the help text of `-datacarriersize` is incorrect.
The purpose of this standardization rule is not to target only the data contained in the raw scriptPubKey, but all forms of arbitrary data.
It is incorrect to change the description of this option if an attempt to update it was made without being merged.
Context:
The [first inscription](https://mempool.space/block/000000000000000000029730547464f056f8b6e2e0a02eaf69c24389983a04f5) appeared December 14, 2022 at the h
...
💬 ChrisMartl commented on pull request "doc: revert clarify -datacarriersize":
(https://github.com/bitcoin/bitcoin/pull/29173#issuecomment-1876707992)
ACK
(https://github.com/bitcoin/bitcoin/pull/29173#issuecomment-1876707992)
ACK
💬 ajtowns commented on pull request "doc: revert clarify -datacarriersize":
(https://github.com/bitcoin/bitcoin/pull/29173#issuecomment-1876721138)
NACK. Docs should describe what the code does, not what we might like it to do.
(https://github.com/bitcoin/bitcoin/pull/29173#issuecomment-1876721138)
NACK. Docs should describe what the code does, not what we might like it to do.
💬 maflcko commented on pull request "doc: revert clarify -datacarriersize":
(https://github.com/bitcoin/bitcoin/pull/29173#issuecomment-1876721749)
> Then a [second patch](https://github.com/bitcoin/bitcoin/pull/28408), this time eligible for a merge, was released on September 5, 2023
>
> Finally @maflcko changed the description on June 8, 2023.
I changed the documentation to match the code in June. Otherwise, there would be a mismatch between the code and the documentation. I am not sure why it would be beneficial to re-introduce the mismatch.
I have no objection to changing the code (along with the documentation). However, I thin
...
(https://github.com/bitcoin/bitcoin/pull/29173#issuecomment-1876721749)
> Then a [second patch](https://github.com/bitcoin/bitcoin/pull/28408), this time eligible for a merge, was released on September 5, 2023
>
> Finally @maflcko changed the description on June 8, 2023.
I changed the documentation to match the code in June. Otherwise, there would be a mismatch between the code and the documentation. I am not sure why it would be beneficial to re-introduce the mismatch.
I have no objection to changing the code (along with the documentation). However, I thin
...
💬 t-bast commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1876742224)
> No, that is not how Lightning works. With anchor outputs, beyond the basic fee level, fees are paid by whichever side wants to pay them, potentially both parties at once.
You're confusing fees paid directly by the commitment transaction (which are always paid by the channel initiator, regardless of whose commitment transaction it is) and fees paid by CPFP-ing the anchor output. Which doesn't make any sense to me since you're advocating for removing the CPFP part! I guess we're just talking
...
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1876742224)
> No, that is not how Lightning works. With anchor outputs, beyond the basic fee level, fees are paid by whichever side wants to pay them, potentially both parties at once.
You're confusing fees paid directly by the commitment transaction (which are always paid by the channel initiator, regardless of whose commitment transaction it is) and fees paid by CPFP-ing the anchor output. Which doesn't make any sense to me since you're advocating for removing the CPFP part! I guess we're just talking
...
💬 maflcko commented on pull request "fuzz: set `nMaxOutboundLimit` in connman target":
(https://github.com/bitcoin/bitcoin/pull/29172#issuecomment-1876742834)
lgtm ACK 46d7113ec1389eb78d7cd44425ecc22dda9b67bf
(https://github.com/bitcoin/bitcoin/pull/29172#issuecomment-1876742834)
lgtm ACK 46d7113ec1389eb78d7cd44425ecc22dda9b67bf
💬 1ma commented on pull request "doc: revert clarify -datacarriersize":
(https://github.com/bitcoin/bitcoin/pull/29173#issuecomment-1876752317)
ACK. The change that is being reverted was a covert attempt at shrugging off the responsibility of addressing [CVE-2023-50428](https://nvd.nist.gov/vuln/detail/CVE-2023-50428) in Bitcoin Core.
There is even an open PR to address it, https://github.com/bitcoin/bitcoin/pull/28408. Exploits must be addressed by changing the C++ code, not the project's documentation.
(https://github.com/bitcoin/bitcoin/pull/29173#issuecomment-1876752317)
ACK. The change that is being reverted was a covert attempt at shrugging off the responsibility of addressing [CVE-2023-50428](https://nvd.nist.gov/vuln/detail/CVE-2023-50428) in Bitcoin Core.
There is even an open PR to address it, https://github.com/bitcoin/bitcoin/pull/28408. Exploits must be addressed by changing the C++ code, not the project's documentation.
💬 maflcko commented on pull request "doc: revert clarify -datacarriersize":
(https://github.com/bitcoin/bitcoin/pull/29173#issuecomment-1876780967)
> ACK. The change that is being reverted was a covert attempt at shrugging off the responsibility of addressing [CVE-2023-50428](https://nvd.nist.gov/vuln/detail/CVE-2023-50428) in Bitcoin Core.
> There is even an open PR to address it, #28408. Exploits must be addressed by changing the C++ code, not the project's documentation.
This PR was opened and the CVE was filed *after* the documentation change, so it is not possible that the documentation change was made in response to either of thos
...
(https://github.com/bitcoin/bitcoin/pull/29173#issuecomment-1876780967)
> ACK. The change that is being reverted was a covert attempt at shrugging off the responsibility of addressing [CVE-2023-50428](https://nvd.nist.gov/vuln/detail/CVE-2023-50428) in Bitcoin Core.
> There is even an open PR to address it, #28408. Exploits must be addressed by changing the C++ code, not the project's documentation.
This PR was opened and the CVE was filed *after* the documentation change, so it is not possible that the documentation change was made in response to either of thos
...