josie

> A single-function API for sending that takes care of everything (even the scan-pubkey grouping, sort ftw!) seems a good idea to me. yeah, the more I thought about it,...

> Do you think it's an acceptable choice if we just drop n_outputs from the struct and store the output directly as instance This is much simpler. Also agree that...

@S3RK I think this change could go in as-is, but IIRC from #28560 , there are places we are creating a `CMutableTransaction` just so we can pass it to `FundTransaction`....

ACK https://github.com/bitcoin/bips/pull/1537/commits/ff9feab538e7f814a694ad92f4487f998649b920 LGTM, clears up the confusion I had regarding `OP_PUSHBYTES_x` vs `OP_PUSHDATA1 x`.

Following suggestions from @willcl-ark , @ryanofsky and @hebasto , I've been testing this patch (which is just a slight modification of @ryanofsky 's): ```diff --- a/depends/toolchain.cmake.in +++ b/depends/toolchain.cmake.in @@ -92,6...

(Background discussion for context: https://delvingbitcoin.org/t/revisiting-bip21/630) Thanks for starting this! Conceptually, I agree with the updates but I think we can get a bigger win by advising the use of HRPs...

> This is similarly untrue, the only difference is it reduces the characters used for future instructions, but whether it supports future instructions or not, both do. No, they are...

> I'm not really super excited to bake "future addresses will use bech32m" into the spec in that way, because at some point we're gonna want "bech32n" While certainly not...

> To be clear, I think we should "whitelist the set of addresses that are allowed in the root" either way. Effectively, this is what you get with my proposal:...

I think there are two separate topics here: 1. "I need to process the entire blockchain for [an external application like electrs, data analysis, etc]" 2. We can probably make...