💬 LarryRuane commented on pull request "bitcoin-cli help detail to show full help for all RPCs":
(https://github.com/bitcoin/bitcoin/pull/29163#issuecomment-1874278059)
Force pushed to add release note (not sure if this is important enough to have a release note for, but just in case), and also updated the `help help` text to document the `detail` argument:
```
$ bitcoin-cli help help
help ( "command" )
List all commands, or get help for a specified command.
Arguments:
1. command (string, optional, default=all commands) The command to get help on, or "detail" for full help on all commands
Result:
"str" (string) The help text
```
(https://github.com/bitcoin/bitcoin/pull/29163#issuecomment-1874278059)
Force pushed to add release note (not sure if this is important enough to have a release note for, but just in case), and also updated the `help help` text to document the `detail` argument:
```
$ bitcoin-cli help help
help ( "command" )
List all commands, or get help for a specified command.
Arguments:
1. command (string, optional, default=all commands) The command to get help on, or "detail" for full help on all commands
Result:
"str" (string) The help text
```
💬 glozow 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-1874280212)
> I've chosen a domain name that is explicitly verbose about its purpose
Er, how is "maybe malware" the purpose of the seeder? It seems like this would just confuse/alarm users, maybe choose something else instead. I don't think adding a log filter makes sense either.
(https://github.com/bitcoin/bitcoin/pull/29145#issuecomment-1874280212)
> I've chosen a domain name that is explicitly verbose about its purpose
Er, how is "maybe malware" the purpose of the seeder? It seems like this would just confuse/alarm users, maybe choose something else instead. I don't think adding a log filter makes sense either.
💬 stratospher commented on pull request "test/BIP324: functional tests for v2 P2P encryption":
(https://github.com/bitcoin/bitcoin/pull/24748#discussion_r1439634994)
nice! done.
(https://github.com/bitcoin/bitcoin/pull/24748#discussion_r1439634994)
nice! done.
💬 stratospher commented on pull request "test/BIP324: functional tests for v2 P2P encryption":
(https://github.com/bitcoin/bitcoin/pull/24748#discussion_r1439635162)
added a [description](https://github.com/bitcoin/bitcoin/blob/42203f84bba7e4ba206c9f951c3f4b6922a44f81/test/functional/test_framework/v2_p2p.py#L260-L265) and also an [extra assert](https://github.com/bitcoin/bitcoin/blob/42203f84bba7e4ba206c9f951c3f4b6922a44f81/test/functional/test_framework/p2p.py#L326) to make sure we don't receive b"" as an application layer message.
(https://github.com/bitcoin/bitcoin/pull/24748#discussion_r1439635162)
added a [description](https://github.com/bitcoin/bitcoin/blob/42203f84bba7e4ba206c9f951c3f4b6922a44f81/test/functional/test_framework/v2_p2p.py#L260-L265) and also an [extra assert](https://github.com/bitcoin/bitcoin/blob/42203f84bba7e4ba206c9f951c3f4b6922a44f81/test/functional/test_framework/p2p.py#L326) to make sure we don't receive b"" as an application layer message.
💬 dergoegge commented on pull request "PoC: fuzz chainstate and block managers":
(https://github.com/bitcoin/bitcoin/pull/29158#issuecomment-1874318288)
Thanks for working on this!
One alternative that I have considered before (for chainstate fuzzing) is to abstract and further modularize `BlockManager`, which would allow us to have an `InMemoryBlockManager` for tests (especially useful for fuzzing but also nice in unit tests).
This would require a bunch of work:
* Breaking up the friendship between `BlockManager`, `Chainstate` & `ChainstateManager`
* Abstracting `BlockManager`'s interface away from being file based
* Hiding access to
...
(https://github.com/bitcoin/bitcoin/pull/29158#issuecomment-1874318288)
Thanks for working on this!
One alternative that I have considered before (for chainstate fuzzing) is to abstract and further modularize `BlockManager`, which would allow us to have an `InMemoryBlockManager` for tests (especially useful for fuzzing but also nice in unit tests).
This would require a bunch of work:
* Breaking up the friendship between `BlockManager`, `Chainstate` & `ChainstateManager`
* Abstracting `BlockManager`'s interface away from being file based
* Hiding access to
...
💬 brunoerg commented on pull request "p2p: Allow whitelisting outgoing connections":
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1439666464)
Same reason: https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1437020771
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1439666464)
Same reason: https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1437020771
💬 petertodd commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1874336752)
@darosior
> > The largest lightning channels out there are about 5BTC. Even if you were willing to bump fees, all the way to spending the entire 5BTC towards fees, you'd need just 68 different fee variants to go all the way from 1sat/vbyte to spending the full 5BTC on fees, with a 25% increase for each each fee variant.
>
> So you'd potentially hand to your supposedly untrusted channel partner a signature for a transaction burning your whole 4.95BTC balance to fees? This trivially opens a
...
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1874336752)
@darosior
> > The largest lightning channels out there are about 5BTC. Even if you were willing to bump fees, all the way to spending the entire 5BTC towards fees, you'd need just 68 different fee variants to go all the way from 1sat/vbyte to spending the full 5BTC on fees, with a 25% increase for each each fee variant.
>
> So you'd potentially hand to your supposedly untrusted channel partner a signature for a transaction burning your whole 4.95BTC balance to fees? This trivially opens a
...
💬 brunoerg commented on pull request "p2p: Allow whitelisting outgoing connections":
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1439677728)
I'll leave it as is for now.
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1439677728)
I'll leave it as is for now.
💬 sipa commented on pull request "fuzz: rule-out too deep derivation paths in descriptor parsing targets":
(https://github.com/bitcoin/bitcoin/pull/28832#issuecomment-1874377138)
utACK a44808fb437864878c2d9696b8a96193091446ee
(https://github.com/bitcoin/bitcoin/pull/28832#issuecomment-1874377138)
utACK a44808fb437864878c2d9696b8a96193091446ee
💬 brunoerg commented on pull request "p2p: Allow whitelisting outgoing connections":
(https://github.com/bitcoin/bitcoin/pull/27114#issuecomment-1874398255)
Force-pushed addressing https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1411359535
(https://github.com/bitcoin/bitcoin/pull/27114#issuecomment-1874398255)
Force-pushed addressing https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1411359535
💬 petertodd commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1874400590)
> > Now, as for the choosing a feerate in advance problem, I explained fully in my article, showing how it's quite easy to pre-sign every conceivable feerate because there just aren't that many of them. In fact, you could easily pre-sign feerates all the way to making the channel uneconomical to close, because you've spent every cent towards fees. This is not a problem.
>
> That proposal ignores important drawbacks on the lightning side. I'm actually quite surprised that you don't even mentio
...
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1874400590)
> > Now, as for the choosing a feerate in advance problem, I explained fully in my article, showing how it's quite easy to pre-sign every conceivable feerate because there just aren't that many of them. In fact, you could easily pre-sign feerates all the way to making the channel uneconomical to close, because you've spent every cent towards fees. This is not a problem.
>
> That proposal ignores important drawbacks on the lightning side. I'm actually quite surprised that you don't even mentio
...
🤔 sipa reviewed a pull request: "Wallet: don't underestimate the fees when spending a Taproot output"
(https://github.com/bitcoin/bitcoin/pull/26573#pullrequestreview-1800853604)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/26573#pullrequestreview-1800853604)
Concept ACK
💬 sipa commented on pull request "Wallet: don't underestimate the fees when spending a Taproot output":
(https://github.com/bitcoin/bitcoin/pull/26573#discussion_r1439716924)
Same here.
(https://github.com/bitcoin/bitcoin/pull/26573#discussion_r1439716924)
Same here.
💬 sipa commented on pull request "Wallet: don't underestimate the fees when spending a Taproot output":
(https://github.com/bitcoin/bitcoin/pull/26573#discussion_r1439721581)
Seems better to use `GetSizeOfCompactSize` here.
(https://github.com/bitcoin/bitcoin/pull/26573#discussion_r1439721581)
Seems better to use `GetSizeOfCompactSize` here.
💬 sipa commented on pull request "Wallet: don't underestimate the fees when spending a Taproot output":
(https://github.com/bitcoin/bitcoin/pull/26573#discussion_r1439722015)
Nit: leave -> leaf
(https://github.com/bitcoin/bitcoin/pull/26573#discussion_r1439722015)
Nit: leave -> leaf
💬 petertodd commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1874428462)
> Responding to https://petertodd.org/2023/v3-transactions-review
>
> In general, I agree that RBF is a great fee-bumping mechanism. The entire point of v3 and EA is to make RBF more useful and less prone to pinning, and to enable us to use it in conjunction with CPFP while eliminating some of the inefficiency.
>
> We seem to have entirely different perspectives about what RBF's limitations are today. Pointing out limitations in RBF is not intended as a personal attack. There is no intenti
...
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1874428462)
> Responding to https://petertodd.org/2023/v3-transactions-review
>
> In general, I agree that RBF is a great fee-bumping mechanism. The entire point of v3 and EA is to make RBF more useful and less prone to pinning, and to enable us to use it in conjunction with CPFP while eliminating some of the inefficiency.
>
> We seem to have entirely different perspectives about what RBF's limitations are today. Pointing out limitations in RBF is not intended as a personal attack. There is no intenti
...
💬 instagibbs commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1874445551)
moving to delving thread as we're essentially debating an LN spec at this point: https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340/3
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1874445551)
moving to delving thread as we're essentially debating an LN spec at this point: https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340/3
💬 petertodd commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1874451089)
> moving to delving thread as we're essentially debating an LN spec at this point: https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340/3
We are not debating the LN spec.
The LN spec doesn't use V3 transactions, and as of anchor channels, is not vulnerable to the problems V3 transactions aims to solve. As I mentioned in my post, package relay would be helpful to anchor channels. But of course, package relay does not depend on V3.
This discussion is not about general B
...
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1874451089)
> moving to delving thread as we're essentially debating an LN spec at this point: https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340/3
We are not debating the LN spec.
The LN spec doesn't use V3 transactions, and as of anchor channels, is not vulnerable to the problems V3 transactions aims to solve. As I mentioned in my post, package relay would be helpful to anchor channels. But of course, package relay does not depend on V3.
This discussion is not about general B
...
💬 mzumsande commented on pull request "Nuke adjusted time (attempt 2)":
(https://github.com/bitcoin/bitcoin/pull/28956#discussion_r1439748605)
I think the the addition should be done before the division to handle rounding effects better, like it's done in `timedata`. If the two relevant offsets are, for example, 3 and 5, the median with this code would be 3.
(https://github.com/bitcoin/bitcoin/pull/28956#discussion_r1439748605)
I think the the addition should be done before the division to handle rounding effects better, like it's done in `timedata`. If the two relevant offsets are, for example, 3 and 5, the median with this code would be 3.
💬 instagibbs commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1874472046)
As noted in delving, pinning is not solved for anchor channels: If an adversary splits the view of which commitment transaction is broadcasted, the remote copy can become the pin since the defender is unable to propagate their spend of the remote commit tx anchor.
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1874472046)
As noted in delving, pinning is not solved for anchor channels: If an adversary splits the view of which commitment transaction is broadcasted, the remote copy can become the pin since the defender is unable to propagate their spend of the remote commit tx anchor.