Question for masto-bitcoin: which one is more likely to be merged first into mainstream bitcoin, SIGHASH_NOINPUT or Neutrino?

@ott0disk what do you mean by "mainstream bitcoin"? E.g. noinput requires a soft fork, but neutrino works just fine on Bitcoin with no consensus changes (although a consensus change would eliminate mild problems with it related to bandwidth-wasting attacks and extra software logic to limit those problems).

@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.

@ott0disk the way Bitcoin Core would handle Neutrino (BIPs 157/158) is as a server rather than a client, and I think all the details are worked out on that side and a PR is open, so I'd give it moderate odds of being included in 0.19 (~Oct 2019). Noinput would probably be bundled with a Schnorr soft fork, which I expect would be at least one release later (plus additional months for signaling and activation, call it about two years from now at least). These are just guesses.

@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 In fact from the discussion i had the other day at the meetup i understood that one of the type filters is specifically designed for LN but is impossible/really_hard to implement as-is in Bitcoin Core, effectively reducing the usefulness of neutrino. *keeps digging*

@ott0disk I'm not familar with that argument. Both the current design and the previous design are easy for Bitcoin Core. The PR for the current design builds the filters for the whole chain in less than an hour on consumer-grade laptops. The current design is also even better for LN than the old design AFAIK, although it does require extra client logic to deal with bandwidth wasting attacks.
@ott0disk I think type 0x01 might be a hold over from an earlier design. AFAIK, there's now only one recommended filter, prevout scriptPubKey + output scriptPubKey.

@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

@ott0disk the channel close tx cointains the txid of the channel open transaction, so as long as you tracked the confirmation of the channel open (which is required, since unconfirmed channels aren't safe) you have the data to locate the spending tx and its outputs.

@harding so the filter looks like
prevOut_scriptPubkey -> funding_tx.vout[outIndex].scriptPubKey +
output_scriptPubkey -> commitmentX.vout[to_remoteIndex].scriptPubkey

The `to_remote` is a simple P2WPKH and doesn't change at every commitment. Well thanks for the info David!

@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 :)

@ott0disk I don't understand what you're saying. Alice opens a channel to Bob by paying P2WSH address x. The filter for block y matches this and so Alice and Bob get the outpoint for that UTXO. Later the filter for block z also matches address x because the channel has been closed. Alice and Bob use the outpoint to locate the close tx in that block and see if it's the correct close state. If not, the generate a breach remedy (justice) tx using its disclosed key.

@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.

@ott0disk correct (and sorry for the confusion!), as long as you know either the scriptPubKey being paid or the scriptPubKey that's being spent from, you can use a filter to find matches.

@ott0disk Neutrino is almost merged by now. Never underestimate how long soft-forks will take :P Even if it is a three line patch like NOINPUT

@ott0disk Use #bitcoin next time if you want visibility ;) I just noticed this post from your profile. Not sure if "neutrino" (you mean client-side filters?) is already merged. If not, it will certainly take less time than a soft-fork like NOINPUT.

Sign in to participate in the conversation

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!