@harding mainstream bitcoin as in 'included in some release of bitcoin-core'. It's a good point that noinput requires a soft fork while neutrino doesn't, but it was my understanding that Neutrino still some flaws to iron out - I'll do more research on this.
@harding yes Bitcoin Core would handle the client side filtering from a server side POV, which means pre-generating filters for all the blocks and be ready to serve them to the light client (we still call them SPV?). Looking at BIP158 i see it a bit ill-defined: for example signalling NODE_COMPACT_FILTERS requires knowledge of type 0x00 and 0x01 but the latter isn't defined in the document. I'll keep digging the ML as it's a bit hard to find info on the filter types.
@harding okay, i wonder if the 0x00 type is really useful in the LN context, you know the prevout scriptPubKey but not the output spending it; unless you opened a channel using `option_upfront_shutdown_script` which forces the closing TX to have the specified scriptPubKey
@harding while this works nicely i see a problem though: the `to_remote` output might be trimmed out from the commitment (due to fees and channel balance) so you wouldn't notice if that is being published (if you follow only the `to_remote`) this is a problem if you also happen to have in-flight HTLCs that you should fail/fullfill with a 2-nd stage transaction. I guess the trick is to add those outputs to the filter too :)
@harding oh then the filter is able to match just on the outpoint, whether it's the one of the opening channel tx or the prev_out in the case of the closing channel tx. I've read the '+' in your comment as an actual concatenation.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!