💬 darosior commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1873490509)
@pox in the post you link Peter Todd argues against v3 transactions in 3 points:
1. [v3 does not fix all pinning vectors](https://petertodd.org/2023/v3-transactions-review#v3-transactions);
2. Using CPFP is [less optimal than using RBF](https://petertodd.org/2023/v3-transactions-review#replace-by-fee);
3. ["Anchor Outputs Are a Danger to Mining Decentralization"](https://petertodd.org/2023/v3-transactions-review#anchor-outputs-are-a-danger-to-mining-decentralization) :tm:
If we tune down t
...
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1873490509)
@pox in the post you link Peter Todd argues against v3 transactions in 3 points:
1. [v3 does not fix all pinning vectors](https://petertodd.org/2023/v3-transactions-review#v3-transactions);
2. Using CPFP is [less optimal than using RBF](https://petertodd.org/2023/v3-transactions-review#replace-by-fee);
3. ["Anchor Outputs Are a Danger to Mining Decentralization"](https://petertodd.org/2023/v3-transactions-review#anchor-outputs-are-a-danger-to-mining-decentralization) :tm:
If we tune down t
...
💬 Willtech commented on issue "Tor ephemeral hidden service rejuvenation":
(https://github.com/bitcoin/bitcoin/issues/17491#issuecomment-1873498851)
We think that is what the configuration is for, less digging in files. If we must all configuration can be added strictly by command line.
(https://github.com/bitcoin/bitcoin/issues/17491#issuecomment-1873498851)
We think that is what the configuration is for, less digging in files. If we must all configuration can be added strictly by command line.
💬 petertodd commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1873500161)
@darosior You keep on saying that RBF is not incentive compatible.
Question: in my article, in the context of replace-by-fee for lightning commitment transactions, are you claiming that *those* replacements are not incentive compatible?
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1873500161)
@darosior You keep on saying that RBF is not incentive compatible.
Question: in my article, in the context of replace-by-fee for lightning commitment transactions, are you claiming that *those* replacements are not incentive compatible?
💬 petertodd commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1873503767)
@darosior
> The v3 relay regime isn't perfect, it's just 100x better for this application than the current one. This is not a reason not to do v3.
Are you claiming that the anchor outputs in existing Lightning anchor channels are subject to transaction pinning?
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1873503767)
@darosior
> The v3 relay regime isn't perfect, it's just 100x better for this application than the current one. This is not a reason not to do v3.
Are you claiming that the anchor outputs in existing Lightning anchor channels are subject to transaction pinning?
💬 darosior commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1873508568)
> @darosior You keep on saying that RBF is not incentive compatible.
> Question: in my article, in the context of replace-by-fee for lightning commitment transactions, are you claiming that those replacements are not incentive compatible?
I think there's been much confused talk about "incentive compatibility" in the past. It depends "what for" and "compared to what".
I'm not claiming that your proposal to pre-sign a bunch of transactions at different feerates is not incentive-compatible,
...
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1873508568)
> @darosior You keep on saying that RBF is not incentive compatible.
> Question: in my article, in the context of replace-by-fee for lightning commitment transactions, are you claiming that those replacements are not incentive compatible?
I think there's been much confused talk about "incentive compatibility" in the past. It depends "what for" and "compared to what".
I'm not claiming that your proposal to pre-sign a bunch of transactions at different feerates is not incentive-compatible,
...
💬 petertodd commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1873517708)
> > @darosior You keep on saying that RBF is not incentive compatible.
> > Question: in my article, in the context of replace-by-fee for lightning commitment transactions, are you claiming that those replacements are not incentive compatible?
>
> I think there's been much confused talk about "incentive compatibility" in the past. It depends "what for" and "compared to what".
>
> I'm not claiming that your proposal to pre-sign a bunch of transactions at different feerates is not incentive-
...
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1873517708)
> > @darosior You keep on saying that RBF is not incentive compatible.
> > Question: in my article, in the context of replace-by-fee for lightning commitment transactions, are you claiming that those replacements are not incentive compatible?
>
> I think there's been much confused talk about "incentive compatibility" in the past. It depends "what for" and "compared to what".
>
> I'm not claiming that your proposal to pre-sign a bunch of transactions at different feerates is not incentive-
...
💬 petertodd commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1873518209)
While I'm at it, Concept NACK, due to the problems outlined in https://petertodd.org/2023/v3-transactions-review and https://petertodd.org/2023/v3-txs-pinning-vulnerability
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1873518209)
While I'm at it, Concept NACK, due to the problems outlined in https://petertodd.org/2023/v3-transactions-review and https://petertodd.org/2023/v3-txs-pinning-vulnerability
📝 LarryRuane opened a pull request: "bitcoin-cli help detail to show full help for all RPCs"
(https://github.com/bitcoin/bitcoin/pull/29163)
Prints to stdout a concatenation of full help text as if you had run `bitcoin-cli help` on every RPC. This allows you to search help text when you can't remember the name of an RPC.
For example, suppose you remember there is an RPC that shows you orphaned chain branches but can't remember its name. This PR allows you to run:
```
bitcoin-cli help detail | less
```
and then search for "orphan", you'd immediately find `getchaintips`. It shows the category before each RPC's help text, which a
...
(https://github.com/bitcoin/bitcoin/pull/29163)
Prints to stdout a concatenation of full help text as if you had run `bitcoin-cli help` on every RPC. This allows you to search help text when you can't remember the name of an RPC.
For example, suppose you remember there is an RPC that shows you orphaned chain branches but can't remember its name. This PR allows you to run:
```
bitcoin-cli help detail | less
```
and then search for "orphan", you'd immediately find `getchaintips`. It shows the category before each RPC's help text, which a
...
💬 rot13maxi commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#discussion_r1439121126)
have we seen protocols using `<data> OP_DROP` in the wild, or is this a pre-emptive check?
(https://github.com/bitcoin/bitcoin/pull/28408#discussion_r1439121126)
have we seen protocols using `<data> OP_DROP` in the wild, or is this a pre-emptive check?
💬 wizkid057 commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1873573115)
Approach ACK.
Don't let perfect be the enemy of good. Spam is already filtered at various levels in the code, and has been for over a decade. All this PR does is apply an existing limit on datacarriersize to data carrying of a different form of data carrying that is clearly an unintended exploit. This is a no brainer place to start with correcting that.
Discussion about OCEAN seems quite off topic here (perhaps only except for it being the only pool using this PR in practice), but it's
...
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1873573115)
Approach ACK.
Don't let perfect be the enemy of good. Spam is already filtered at various levels in the code, and has been for over a decade. All this PR does is apply an existing limit on datacarriersize to data carrying of a different form of data carrying that is clearly an unintended exploit. This is a no brainer place to start with correcting that.
Discussion about OCEAN seems quite off topic here (perhaps only except for it being the only pool using this PR in practice), but it's
...
💬 ns-xvrn commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1873584540)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1873584540)
Concept ACK
💬 Willtech commented on issue "Signmessage doesn't work with segwit addresses":
(https://github.com/bitcoin/bitcoin/issues/10542#issuecomment-1873646556)
Key is not address is fine the address is a cryptographic construct the feature is to be able to use the address to sign and verify messages.
(https://github.com/bitcoin/bitcoin/issues/10542#issuecomment-1873646556)
Key is not address is fine the address is a cryptographic construct the feature is to be able to use the address to sign and verify messages.
💬 eragmus commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1873670326)
> OCEAN has _not_ paid any miners anything that wasn't derived from the rewards from blocks found by the pool. The "bonus" shown is not something paid from other funds (investors or otherwise), it's just that the reward system's sharelog is not yet full, so shares are weighted more heavily since there are fewer in the log, and we're showing that delta as "a bonus".
Thanks for clarifying the source of the bonus. If Ocean reps don't provide the actual information, then obviously people will spec
...
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1873670326)
> OCEAN has _not_ paid any miners anything that wasn't derived from the rewards from blocks found by the pool. The "bonus" shown is not something paid from other funds (investors or otherwise), it's just that the reward system's sharelog is not yet full, so shares are weighted more heavily since there are fewer in the log, and we're showing that delta as "a bonus".
Thanks for clarifying the source of the bonus. If Ocean reps don't provide the actual information, then obviously people will spec
...
💬 stratospher commented on pull request "test: create deterministic addrman in the functional tests":
(https://github.com/bitcoin/bitcoin/pull/29007#discussion_r1439231283)
nice! done.
(https://github.com/bitcoin/bitcoin/pull/29007#discussion_r1439231283)
nice! done.
🤔 shaavan reviewed a pull request: "init: handle empty settings file gracefully"
(https://github.com/bitcoin/bitcoin/pull/29144#pullrequestreview-1800095106)
> Thus I proposed a different solution for non-interactive users who are manually modifying the file. See https://github.com/bitcoin/bitcoin/pull/29144#pullrequestreview-1798109497.
Stating that the file is JSON-formatted and auto-generated gives bitcoind users another hint over what they can and can't do.
I see your point, @furszy
But I think my points still apply to creating an "auto-generated" file.
1. A regular user might not tinker with their settings file regularly and hence the
...
(https://github.com/bitcoin/bitcoin/pull/29144#pullrequestreview-1800095106)
> Thus I proposed a different solution for non-interactive users who are manually modifying the file. See https://github.com/bitcoin/bitcoin/pull/29144#pullrequestreview-1798109497.
Stating that the file is JSON-formatted and auto-generated gives bitcoind users another hint over what they can and can't do.
I see your point, @furszy
But I think my points still apply to creating an "auto-generated" file.
1. A regular user might not tinker with their settings file regularly and hence the
...
💬 darosior commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1873789701)
> 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 blackmail vector: "
...
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1873789701)
> 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 blackmail vector: "
...
💬 t-bast commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1873793179)
> 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 mention thos
...
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1873793179)
> 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 mention thos
...
💬 maflcko commented on issue "`./configure` fails for clang-14 on Ubuntu 23.10":
(https://github.com/bitcoin/bitcoin/issues/29161#issuecomment-1873858150)
That is a bug in clang-14, fixed in 15. Reproducer:
```cpp
template <class A>
struct ch {
static consteval unsigned w() { return {}; };
static constexpr unsigned bar{w()};
};
int main() {}
(https://github.com/bitcoin/bitcoin/issues/29161#issuecomment-1873858150)
That is a bug in clang-14, fixed in 15. Reproducer:
```cpp
template <class A>
struct ch {
static consteval unsigned w() { return {}; };
static constexpr unsigned bar{w()};
};
int main() {}
📝 darosior opened a pull request: "fuzz: avoid underflow in `coins_view` target"
(https://github.com/bitcoin/bitcoin/pull/29164)
Catching the exception in `AddCoin` and continuing will lead to the calculated memory usage of the cache to be out of sync (lower by the size of the existing coin). If we later remove more coins, this can lead to an underflow and the sanitizer will trip on a later overflow when we add back to `cachedCoinsUsage`. See https://github.com/bitcoin/bitcoin/pull/28216#issuecomment-1872991949.
I found this while rebasing #28216 but another way of exposing this mistake is to simply run the cache sanit
...
(https://github.com/bitcoin/bitcoin/pull/29164)
Catching the exception in `AddCoin` and continuing will lead to the calculated memory usage of the cache to be out of sync (lower by the size of the existing coin). If we later remove more coins, this can lead to an underflow and the sanitizer will trip on a later overflow when we add back to `cachedCoinsUsage`. See https://github.com/bitcoin/bitcoin/pull/28216#issuecomment-1872991949.
I found this while rebasing #28216 but another way of exposing this mistake is to simply run the cache sanit
...
💬 darosior commented on pull request "fuzz: a new target for the coins database":
(https://github.com/bitcoin/bitcoin/pull/28216#issuecomment-1873876560)
Rebased on top of #29164 to fix the above.
(https://github.com/bitcoin/bitcoin/pull/28216#issuecomment-1873876560)
Rebased on top of #29164 to fix the above.
💬 maflcko commented on issue "`./configure` fails for clang-14 on Ubuntu 23.10":
(https://github.com/bitcoin/bitcoin/issues/29161#issuecomment-1873883731)
I don't understand why this isn't caught by CI. Maybe libc++ somehow works around the bug in the corresponding clang?
Not sure how to fix it. The easiest would obviously be to bump the minimum required to clang-15. However, I am not sure if that works for macOS users.
(https://github.com/bitcoin/bitcoin/issues/29161#issuecomment-1873883731)
I don't understand why this isn't caught by CI. Maybe libc++ somehow works around the bug in the corresponding clang?
Not sure how to fix it. The easiest would obviously be to bump the minimum required to clang-15. However, I am not sure if that works for macOS users.