💬 Sjors commented on pull request "net: Replace libnatpmp with built-in PCP+NATPMP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#issuecomment-2133341499)
> generating a new nonce every time for every mapping
That doesn't seem like a good idea. IIUC the nonce is used to recognise the requesting application, and to distinguish a renew request from some other app trying to use the same port.
(https://github.com/bitcoin/bitcoin/pull/30043#issuecomment-2133341499)
> generating a new nonce every time for every mapping
That doesn't seem like a good idea. IIUC the nonce is used to recognise the requesting application, and to distinguish a renew request from some other app trying to use the same port.
💬 laanwj commented on pull request "net: Replace libnatpmp with built-in PCP+NATPMP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#issuecomment-2133347999)
> That doesn't seem like a good idea. IIUC the nonce is used to recognise the requesting application, and to distinguish a renew request from some other app trying to use the same port.
It's not supposed to be a good idea, but i wonder if it works around the issue with your router, if they implemented the protocol wrongly. i honestly have no idea what could be the problem here i'm just guessing.
(https://github.com/bitcoin/bitcoin/pull/30043#issuecomment-2133347999)
> That doesn't seem like a good idea. IIUC the nonce is used to recognise the requesting application, and to distinguish a renew request from some other app trying to use the same port.
It's not supposed to be a good idea, but i wonder if it works around the issue with your router, if they implemented the protocol wrongly. i honestly have no idea what could be the problem here i'm just guessing.
💬 hebasto commented on pull request "util: add VecDeque":
(https://github.com/bitcoin/bitcoin/pull/30161#issuecomment-2133351751)
Concept ACK.
(https://github.com/bitcoin/bitcoin/pull/30161#issuecomment-2133351751)
Concept ACK.
💬 maflcko commented on issue ""bitcoin-cli" does not exist, while "bitcoind" does in ~/bitcoin/src folder":
(https://github.com/bitcoin/bitcoin/issues/30180#issuecomment-2133377482)
What is the output when you re-build the project? (Something like `make clean && make`)
(https://github.com/bitcoin/bitcoin/issues/30180#issuecomment-2133377482)
What is the output when you re-build the project? (Something like `make clean && make`)
💬 Sjors commented on pull request "net: Replace libnatpmp with built-in PCP+NATPMP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#issuecomment-2133381489)
I thought perhaps the issue was that miniupnpd checks whether at least half the lease time went by and would refuse if not. But looking through the source code it doesn't appear to care about that. There's a few places that can trigger a `PCP_ERR_NO_RESOURCES` reply, but so far those don't offer an obvious explanation.
(https://github.com/bitcoin/bitcoin/pull/30043#issuecomment-2133381489)
I thought perhaps the issue was that miniupnpd checks whether at least half the lease time went by and would refuse if not. But looking through the source code it doesn't appear to care about that. There's a few places that can trigger a `PCP_ERR_NO_RESOURCES` reply, but so far those don't offer an obvious explanation.
💬 Sjors commented on pull request "net: Replace libnatpmp with built-in PCP+NATPMP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1615998227)
RPC -> RFC (in a few other places too)
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1615998227)
RPC -> RFC (in a few other places too)
💬 hebasto commented on pull request "util: add VecDeque":
(https://github.com/bitcoin/bitcoin/pull/30161#issuecomment-2133434672)
> It's not a full drop-in replacement...
Then, perhaps, it's a good chance to avoid `size_t` for parameter and return types in the interface?
See: [Signed and Unsigned Types in Interfaces](https://www.aristeia.com/Papers/C++ReportColumns/sep95.pdf)
(https://github.com/bitcoin/bitcoin/pull/30161#issuecomment-2133434672)
> It's not a full drop-in replacement...
Then, perhaps, it's a good chance to avoid `size_t` for parameter and return types in the interface?
See: [Signed and Unsigned Types in Interfaces](https://www.aristeia.com/Papers/C++ReportColumns/sep95.pdf)
📝 brunoerg opened a pull request: "rpc: net: follow-ups for #30062"
(https://github.com/bitcoin/bitcoin/pull/30183)
- Change `addrman` to reference to const since it isn't modified (https://github.com/bitcoin/bitcoin/pull/30062#discussion_r1612272793).
- Improve documentation of `mapped_as`/`source_mapped_as` in `getrawaddrman` RPC by mentioning that both fields will be only available if asmap flag is set. It is the same message for `mapped_as` field in `getpeerinfo`.
(https://github.com/bitcoin/bitcoin/pull/30183)
- Change `addrman` to reference to const since it isn't modified (https://github.com/bitcoin/bitcoin/pull/30062#discussion_r1612272793).
- Improve documentation of `mapped_as`/`source_mapped_as` in `getrawaddrman` RPC by mentioning that both fields will be only available if asmap flag is set. It is the same message for `mapped_as` field in `getpeerinfo`.
💬 theStack commented on pull request "test: MiniWallet: respect passed feerate for padded txs (using `target_weight`)":
(https://github.com/bitcoin/bitcoin/pull/30162#discussion_r1616064751)
Each byte in the output script counts as four weight units, so with the padding method used here, we can only ever increase the weight by multiples of four. If the weight of the unpadded tx is not a multiple of four already (i.e. tx.get_weight() % 4 != 0), it will also not be after the padding and the best we can do is to be not more off than 3 WUs in the worst case.
It would be nice if we could somehow do exact padding with weight unit precision, but to my knowledge there is no general way t
...
(https://github.com/bitcoin/bitcoin/pull/30162#discussion_r1616064751)
Each byte in the output script counts as four weight units, so with the padding method used here, we can only ever increase the weight by multiples of four. If the weight of the unpadded tx is not a multiple of four already (i.e. tx.get_weight() % 4 != 0), it will also not be after the padding and the best we can do is to be not more off than 3 WUs in the worst case.
It would be nice if we could somehow do exact padding with weight unit precision, but to my knowledge there is no general way t
...
💬 theStack commented on pull request "test: MiniWallet: respect passed feerate for padded txs (using `target_weight`)":
(https://github.com/bitcoin/bitcoin/pull/30162#discussion_r1616064960)
We need a running node to create a MiniWallet instance, so unfortunately doing these checks in an unit test wouldn't work. I considered putting it into an existing functional test but wouldn't know which one to pick, so creating a new MiniWallet-specific test where features can tested independently seemed to make the most sense.
(https://github.com/bitcoin/bitcoin/pull/30162#discussion_r1616064960)
We need a running node to create a MiniWallet instance, so unfortunately doing these checks in an unit test wouldn't work. I considered putting it into an existing functional test but wouldn't know which one to pick, so creating a new MiniWallet-specific test where features can tested independently seemed to make the most sense.
💬 theStack commented on pull request "test: MiniWallet: respect passed feerate for padded txs (using `target_weight`)":
(https://github.com/bitcoin/bitcoin/pull/30162#discussion_r1616065138)
Passing `target_weight` with an absolute `fee` should still work fine. There is arguably less reason now to do so as passing a `fee_rate` is likely more convenient for most use-cases, but I don't think we have to disallow padding txs with an absolute fee.
(https://github.com/bitcoin/bitcoin/pull/30162#discussion_r1616065138)
Passing `target_weight` with an absolute `fee` should still work fine. There is arguably less reason now to do so as passing a `fee_rate` is likely more convenient for most use-cases, but I don't think we have to disallow padding txs with an absolute fee.
💬 theStack commented on pull request "test: MiniWallet: respect passed feerate for padded txs (using `target_weight`)":
(https://github.com/bitcoin/bitcoin/pull/30162#discussion_r1616065536)
The actual weight can be larger by at most 3 WUs, [see comment above](https://github.com/bitcoin/bitcoin/pull/30162#discussion_r1616064751).
(https://github.com/bitcoin/bitcoin/pull/30162#discussion_r1616065536)
The actual weight can be larger by at most 3 WUs, [see comment above](https://github.com/bitcoin/bitcoin/pull/30162#discussion_r1616064751).
✅ kosuodhmwa closed an issue: ""bitcoin-cli" does not exist, while "bitcoind" does in ~/bitcoin/src folder"
(https://github.com/bitcoin/bitcoin/issues/30180)
(https://github.com/bitcoin/bitcoin/issues/30180)
💬 kosuodhmwa commented on issue ""bitcoin-cli" does not exist, while "bitcoind" does in ~/bitcoin/src folder":
(https://github.com/bitcoin/bitcoin/issues/30180#issuecomment-2133532648)
solved, was a mistake of me. thank you anyway :-)
(https://github.com/bitcoin/bitcoin/issues/30180#issuecomment-2133532648)
solved, was a mistake of me. thank you anyway :-)
💬 sipa commented on pull request "util: add VecDeque":
(https://github.com/bitcoin/bitcoin/pull/30161#issuecomment-2133774404)
@hebasto I do prefer to stay compatible with the `std::deque` interface, even if just for matching behavior users would expect.
(https://github.com/bitcoin/bitcoin/pull/30161#issuecomment-2133774404)
@hebasto I do prefer to stay compatible with the `std::deque` interface, even if just for matching behavior users would expect.
👍 itornaza approved a pull request: "consensus: fix `OP_1NEGATE` handling in `CScriptOp`"
(https://github.com/bitcoin/bitcoin/pull/29589#pullrequestreview-2081224349)
tested ACK 0abf50a71b0439ee7f4e94c548b29d726c58477a
Examined all changes from 3fb1b7043a7150f70a4cf1e172968e32c056dc79 up to this commit using `git difftool 3fb1b70 0abf50a` on the changed files. Did a code review on the changes that touches consensus code in`src/script/script.h` as well as the associated test file `test/functional/test_framework/script.py`.
The changes in the python test functions `encode_op_n` and `decode_op_n` are now one to one compatible with the consensus`EncodeOP_N
...
(https://github.com/bitcoin/bitcoin/pull/29589#pullrequestreview-2081224349)
tested ACK 0abf50a71b0439ee7f4e94c548b29d726c58477a
Examined all changes from 3fb1b7043a7150f70a4cf1e172968e32c056dc79 up to this commit using `git difftool 3fb1b70 0abf50a` on the changed files. Did a code review on the changes that touches consensus code in`src/script/script.h` as well as the associated test file `test/functional/test_framework/script.py`.
The changes in the python test functions `encode_op_n` and `decode_op_n` are now one to one compatible with the consensus`EncodeOP_N
...
💬 itornaza commented on pull request "consensus: fix `OP_1NEGATE` handling in `CScriptOp`":
(https://github.com/bitcoin/bitcoin/pull/29589#discussion_r1616232765)
Non-blocking comment: Maybe move the `assert` line at the beginning of this member function so it is even more similar to its `EncodeOP_N` counterpart.
(https://github.com/bitcoin/bitcoin/pull/29589#discussion_r1616232765)
Non-blocking comment: Maybe move the `assert` line at the beginning of this member function so it is even more similar to its `EncodeOP_N` counterpart.
💬 itornaza commented on pull request "test: Add `leaf_version` parameter to `taproot_tree_helper()`":
(https://github.com/bitcoin/bitcoin/pull/29371#issuecomment-2133824938)
trACK 3d4dda0b26d3e003d282be1e30e64055750a792e
(https://github.com/bitcoin/bitcoin/pull/29371#issuecomment-2133824938)
trACK 3d4dda0b26d3e003d282be1e30e64055750a792e
💬 brunoerg commented on pull request "fuzz: wallet: add target for spkm migration":
(https://github.com/bitcoin/bitcoin/pull/29694#issuecomment-2133888537)
cc: @achow101
(https://github.com/bitcoin/bitcoin/pull/29694#issuecomment-2133888537)
cc: @achow101
🤔 BrandonOdiwuor reviewed a pull request: "net: log connections failures via SOCKS5 with less severity"
(https://github.com/bitcoin/bitcoin/pull/30064#pullrequestreview-2081391076)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/30064#pullrequestreview-2081391076)
Concept ACK