< 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>
(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