💬 ajtowns commented on pull request "Make provably unsignable standard P2PK and P2MS outpoints unspendable.":
(https://github.com/bitcoin/bitcoin/pull/28400#issuecomment-1914102082)
> > Fun challenge for everyone: can you link to a specific bare multisig UTXO that has been created within the past year (let's say, since block 769785) where the prunable detection in this PR would hit? Looking at an UTXO snapshot from now (block 827855), from all the 749496 P2MS UTXOs that have been created since the start of the year 2023, I haven't managed to find a _single_ one which is provably unspendable.
>
> they have provided a list: https://gist.github.com/russeree/85fb9519e0a1fc16
...

💬 ajtowns commented on pull request "Make provably unsignable standard P2PK and P2MS outpoints unspendable.":
(https://github.com/bitcoin/bitcoin/pull/28400#issuecomment-1914110506)
> So this would make all current and future STAMPS unspendable? Or just future ones? How would this affect other potential legitimate use cases?

Most STAMPS txs are spendable and are not affected by this PR. As I understand it, that protocol sets up a 1-of-3 multisig, where of the keys is valid (providing a spendable path) and the other two are used for data, and are thus provably unspendable about 50% of the time as the data doesn't match a valid secp point. The only times those txs become u
...

🤔 stratospher reviewed a pull request: "test: p2p: check disconnect due to lack of desirable service flags"
(https://github.com/bitcoin/bitcoin/pull/29279#pullrequestreview-1848022516)
tested ACK ff5f994.

💬 stratospher commented on pull request "test: p2p: check disconnect due to lack of desirable service flags":
(https://github.com/bitcoin/bitcoin/pull/29279#discussion_r1469196012)
ff5f994: nit: `NODE_NONE` here too?

💬 theDavidCoen commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1914214959)
I keep reading ideological points and no one insists on a very basic thing:
consistency.
This PR should be merged because:
1. The code has been tested and it works.
2. Flags that activate a feature should be always set to false. The Bitcoin users (node operators) should be in charge and establish their node's policies actively.

An example:
with version 26.0 we now have the ability to activate v2 transport Protocol, which is a great improvement for Bitcoin.
In order to do that, the users
...

💬 dexX7 commented on pull request "Make provably unsignable standard P2PK and P2MS outpoints unspendable.":
(https://github.com/bitcoin/bitcoin/pull/28400#issuecomment-1914218855)
Concept ACK.

Note, however, that pubkeys can be modified to be valid and still be used to store data, for example by using a byte that is shuffled until the pubkey becomes valid.

💬 naumenkogs commented on pull request "p2p: adaptive connections services flags":
(https://github.com/bitcoin/bitcoin/pull/28170#discussion_r1469260564)
9f36e591c551ec2e58a6496334541bfdae8fdfe5

i see that this is a copy-paste from another place, but since it's technically green (and i want to sure it still makes sense after your change), can you explain what is this about? especially `the returned desirable service flags are guaranteed to not change dependent on state`

👍 naumenkogs approved a pull request: "p2p: adaptive connections services flags"
(https://github.com/bitcoin/bitcoin/pull/28170#pullrequestreview-1848123617)
ACK 27f260aa6e04f82dad78e9a06d58927546143a27

💬 naumenkogs commented on pull request "p2p: adaptive connections services flags":
(https://github.com/bitcoin/bitcoin/pull/28170#discussion_r1469267141)
6ed53602ac7c565273b5722de167cb2569a0e381

if you touch it again, i suggest removing `GetServicesFlagsIBDCache` definition here rather than in the last commit. At this point it's already unused. Saves some review time.

💬 naumenkogs commented on pull request "p2p: adaptive connections services flags":
(https://github.com/bitcoin/bitcoin/pull/28170#discussion_r1469274352)
aff7d92b1500e2478ce36a7e86ae47df47dda178

would be nice to test reacting to reorgs.

💬 glozow commented on pull request "test: ensure output is large enough to pay for its fees":
(https://github.com/bitcoin/bitcoin/pull/29283#discussion_r1469286220)
Does it need to be cast to an `int` maybe?

💬 Sjors commented on pull request "Stratum v2 Template Provider (take 2)":
(https://github.com/bitcoin/bitcoin/pull/28983#issuecomment-1914277528)
(I plan to rebase this after some other stuff is merged)

💬 vostrnad commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1914287655)
@theDavidCoen "Default off everything" is not at all how Bitcoin Core development works. If it did, the node would by default not communicate with the network (`-networkactive`), broadcast wallet transactions (`-walletbroadcast`), persist the mempool between restarts (`-persistmempool`) etc. It would also mean you can just rename an option (e.g. `-permitbaremultisig` to `-disablebaremultisig`) to force the opposite default.

How it actually (usually) works is the default parameters are changed
...

💬 glozow commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1469291356)
Maybe add tests where you (successfully) configure the node's wallet using `-maxfeerate`?

💬 glozow commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1469296961)
1000 is redundant

💬 glozow commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1469293744)
Similarly, it would be good to test that both maxfee and maxfeerate requirements must be met.

💬 Sjors commented on pull request "Silent payment index (for light wallets and consistency check)":
(https://github.com/bitcoin/bitcoin/pull/28241#issuecomment-1914312450)
Will do soon(tm)

✅ willcl-ark closed an issue: "Unable to open wallet UI with ubuntu 23.10"
(https://github.com/bitcoin/bitcoin/issues/29311)

💬 willcl-ark commented on issue "Unable to open wallet UI with ubuntu 23.10":
(https://github.com/bitcoin/bitcoin/issues/29311#issuecomment-1914316466)
I think we can close this out for now as it appears to have been a `fontconfig` issue which is now resolved.

💬 naumenkogs commented on pull request "Nuke adjusted time from validation (attempt 2)":
(https://github.com/bitcoin/bitcoin/pull/28956#issuecomment-1914324428)
ACK ff9039f6ea876bab2c40a06a93e0dd087f445fa2

After a few attempts, I haven't found a way to trigger a consensus fork through adjusted time. It's not like this could "infect" half of the network (legacy) through block propagation or something. Because of that, if there was/is a legacy way to exploit it (say an overflow in `nTimeOffset` calculation), this new code won't make it worse.