feature request: add litecoin support

[losh11]

Neutrino currently does not support litecoin network, in either mainnet or testnet. It is frustrating to build litecoin software without even testnet support.

[Roasbeef]

In order to do this, we'd need to abstract away all PoW checking methods and a number of other
components around difficulty retargeting. The alternative path is to maintain a fork.

[ghost]

@losh11 @Roasbeef Practically the one main change needed for Litecoin to work is btcutil/gcs/builder/builder.go needs the constant DefaultP changing from 19 to 20. Is there a way to programmatically configure this on the fly without resorting to the entire fork of btcsuite (ltcsuite). ?

[ghost]

Having had time to think & discuss this some more (thanks @losh11), I realised that Builder.DefaultP does not need to be changed, as 'p' is passed in to most Builder methods. So the handful of places Neutrino uses Builder could be changed to pass in an appropriate 'p' value dependent on whether Bitcoin or Litecoin is the active mode.

@Roasbeef would it be acceptable to abstract&extend chainParams adding a coin identifier (Bitcoin/Litecoin) and a defaultP setting? Also a change to checkProofOfWork for Litecoin mode. I would like to submit a pull request to this effect.

[cfromknecht]

@Wowee0 why would P value need to different for litecoin? Further, why would the P value be modified without also modifying the value of M?

[ghost]

I did a lot of debugging in Neutrino to find out why received Litecoin cFilterHeaders would not match the expected checkpoint, eventually tracked it down to the output of builder.BuildBasicFilter. Diffing gcs/builder.go between btcsuite/btcutil and ltcsuite/ltcutil/ indicates that the P value of 20 was used for LTCD (M was not changed). After making the change on the Neutrino side they matched.
That's the best I can do to answer your questions @cfromknecht.

[cfromknecht]

Thanks @Wowee0, yes that does appear to be what happened and makes sense why they wouldn’t match up.

That being said, my recommendation would be to correct the value to 19 in ltcsuite/ltcutil. Users that have cfindex enabled will need to drop and reindex, but that only needs to happen once.

Given that there hasn’t been an official deployment on litecoin, I think would be best to keep the implementation consistent with BIP158. Note that if litecoind were to pull in changes from upstream, it would have M=19, and the two implementations would differ for the same filter type.

A significant amount of research was invested into the parameter choices, with the goal of minimizing the overall filter size. This write up by sipa explains the choices of the parameters in BIP158 https://gist.github.com/sipa/576d5f09c3b86c3b1b75598d799fc845

Above that, any future optimizations created for BIP158-parameterized filters may not backport as readily, and may require more code duplication if the parameters are distinct

[ghost]

Thanks @cfromknecht your suggestion has been implemented in ltcutil & ltcd.
Please could you review the following proposal for enabling litecoin support in Neutrino. It boils down to having litecoin genesis block details and using the ltcsuite CheckProofOfWork method.

Neutrino/blockmanager.go/CheckHeaderSanity :
if configured for litecoin,
copy the block header into a ltcutil.block and call ltcsuite.ltcd.blockchain.CheckProofOfWork
Neutrino/query.go/GetBlock :
if configured for litecoin,
copy the block into a ltcutil.block and call ltcsuite.ltcd.blockchain.CheckBlockSanity

LND/config.go :
allow the configuration of Neutrino=1
LND/chainparams.go/applyLitecoinParams :
apply some litecoin chainparams settings that were missed in the original implementation, namely:
GenesisBlock information
PowLimitBits and PowLimit

The proposed code changes can be viewed here:
lightningnetwork/lnd@master...Wowee0:litecoin_hacks
master...Wowee0:litecoin_hacks

[benthecarman]

NACK

[losh11]

@benthecarman do you have a reason for the NACK?

[benthecarman]

@benthecarman do you have a reason for the NACK?

as @Roasbeef stated it will require more complexity around important code.

Also there's no reason to support shitcoins

[losh11]

Also there's no reason to support shitcoins

This isn't the place to argue over this. That being said LND already supports the litecoin chain... and supports all features, excluding neutrino. We would just like to see feature parity between the chains.