< fanquake_> no PR bot today?
< hebasto> provoostenator: thanks for adding release notes forhttps://github.com/bitcoin-core/gui/pull/4
< Guest60> Hii
< harding> achow101: Looking at https://github.com/bitcoin/bitcoin/pull/22154 , is there a reason besides similarity to how we use the 'bech32' string for using 'bech32m' as the address type string? I always thought it was confusing how we conflated bech32 with P2WPKH in the address-requesting interface. I guess it turned out fortunate that we only ended up using bech32 for one segwit version, but now using bech32m the same way seems to also imply that
< harding> we only intend to use it for one segwit version, and it still creates the same confusion where we have to explain bech32m and P2TR aren't the same thing, e.g. https://bitcoin.stackexchange.com/questions/100434/what-is-the-difference-between-native-segwit-and-bech32
< harding> (Sorry I didn't notice this prior to the PR being merged; I'm bringing it up here because, if there's any chance of fixing it, I think that it's best done before this gets released.)
< sipa> harding: i think output types should be distinguished based on sender's abilities to pay them, as you may need to construct different addresses for older/new sender software
< sipa> and in that regard, i think legacy/p2sh/bech32, and unfortunately, bech32m are probably the right choices
< sipa> now, p2sh was already very widespread when output types were introduced in the forst place, so no distinction is made between legacy anf.p2sh
< sipa> and imho the p2sh-segwit option is just a historical oddity, because at the time, the wallet itself couldn't be configured to prpduce segwit or not, and people wanted a way to opt in/out of that
< harding> sipa: you're saying that (in December 2021) if I run `getnewaddress bech32m` I should get a P2TR address, and (years from now) if I run `getnewaddress bech32m` I should get a P2FOO address because all I care about is whether or not the person who will be spending to me can support bech32m?
< sipa> yes
< harding> Hmm. Ok, I hadn't thought about that before. I'll think about it now. Thanks!
< ndeet> Hi there hope this is the right channel to ask a question about `rpcclienttimeout` afaics this is a setting for bitcoin-cli, so client side only. Is there a way to force RPC calls to be aborted if they take longer than X seconds? Use case is calling RPC via a webapp and the process times out in 30 seconds but bitcoind may take longer than that to
< ndeet> finish certain calls. So the webapp request dies with a timeout (and does not know the state of the command). But eventually bitcoind will finish anyway.
< sipa> if it turns out that this time around, sender actually ubiqutouously start support sending.to.unknown future bech32m addresses...
< ndeet> Specific problem: `sendtoaddress` called via RPC (on a very busy bitcoind node) in webapp, webapp http call dies after 30 secs with timeout because RPC did not respond yet; assumes call failed/server timeout but bitcoind finished the command after 50 secs
< harding> ndeet: I think you want https://github.com/bitcoin/bitcoin/pull/21056
< harding> ndeet: oh, maybe not.
< harding> ndeet: best place to ask for help is #bitcoin or the Bitcoin StackExchange
< ndeet> harding, I did not find that, I think exactly the same use case I need, thank you very much
< ndeet> also not sure why but I'm banned from #bitcoin although I just joined via web interface
< ndeet> anyway, thank you a lot and sorry for posting in the wrong channel
< ndeet> yeah, PR desc sounds like my issue but reading through it seems to be something else, will get proper account go to #bitcoin