Skip to content

Releases: litecoincash-project/litecoincash

Litecoin Cash v0.16.4

07 Apr 12:17
Compare
Choose a tag to compare

Introduction

This release is optional for all users.

It introduces Rialto, our E2EE chat platform, and activates the Rialto network on testnet only. This release is incapable of voting for Rialto activation on mainnet.

It should be entirely safe to use this wallet on mainnet, but as ever, back up your wallet.dat first.

Getting on testnet

As this release resets testnet, any old testnet wallets you may have won't work.

The fresh testnet only has a few hundred blocks and will sync very fast. It should not be necessary to manually add nodes as we have a fresh DNS seed running for testnet.

Windows users should have an additional option in the start menu, "LitecoinCash Core (testnet)". For other users, start the wallet with testnet=1 in litecoincash.conf, or with --testnet as a commandline argument.

To acquire testnet funds (tLCC), you can mine SHA256d or MinotaurX on low difficulty. For convenience, Windows binaries for our cpuminer-multi port, which supports both algos, are included in this release. Hive Mining is also enabled with a super-fast 40 block bee maturation time.

Alternatively, ask an LCC team member and we'll send you some coins.

Setting up Rialto Chat

The Rialto Chat client runs as a separate application to the main wallet. After installing the LCC wallet, download the Rialto Chat installer for your platform. Alternatively, it's very easy to build from source if you prefer.

In order for Rialto Chat to talk to the wallet, RPC access details must be set. In your wallet's litecoincash.conf, set at minimum these lines:

server=1                # Respond to RPC commands
rpcuser=rpctest         # RPC username (replace)
rpcpassword=rpctest     # RPC password (replace)
rpcallowip=127.0.0.1    # Only allow RPC access from 127.0.0.1
rpcbind=127.0.0.1       # Only listen for RPC connections on 127.0.0.1
rpcport=9000            # RPC port
testnet=1               # Force testnet
maxtipage=999999999     # Set max tip age large (useful if you want to mine through a testnet stall)

NOTE FOR WINDOWS QT WALLET USERS: To get to your litecoincash.conf easily, in the wallet go Settings->Options and click the Open Configuration File button near the bottom.

Next, to tell Rialto Chat the required parameters, edit settings.json in the Rialto application data directory.

By default this can be found at:

  • %APPDATA% on Windows
  • $XDG_CONFIG_HOME or ~/.config on Linux
  • ~/Library/Application Support on macOS

The default contents of settings.json are as follows, and match the litecoincash.conf details above:

{"host":"127.0.0.1","port":9000,"user":"rpctest","password":"rpctest"}

We will definitely investigate a more automated installation before mainnet activations.

Using Rialto Chat

Before you can chat with Rialto, you need to register a Rialto Nick. 5-20 character nicks are affordable by all, with 3 and 4 character "prestige" nicks costing a lot more.

On testnet, the current registration costs are:

  • 5-20 characters: 10 tLCC
  • 4 characters: 500 tLCC
  • 3 characters: 10000 tLCC

(Don't forget to ask team members for free tLCC as needed!)

Nick registration is done from within the Rialto Chat client. The button is found here:

regnicks

After registering a nick, wait a few minutes for at least one block to happen, then click the Refresh Nicks button. You can then chat with your chosen nick, and the client will automatically keep using that nick for future sessions.

About Rialto

Introduction

Many chat systems purport to be end-to-end encrypted. Centralised and commercial solutions are vulnerable to external pressures, or may simply lie to you. They appear to work, until they don't. Can that cryptography be trusted?

Open source solutions exist, and may or may not be centralised. Can that cryptography be trusted?

More generally, what cryptography can we trust? We posit that of all cryptosystems in the world today, the cryptographic primitives used in cryptocurrencies such as LCC and BTC are those we trust the most, because we all still have our coins. This is a simple, visceral proof that secp256k1 ECC keypairs are indeed secure.

The idea behind Rialto is to use these exact same cryptographic primitives to build a trustable E2EE chat system. In fact, Rialto introduces no new dependencies into the LCC codebase; we already had everything we need.

Note that Rialto messaging happens entirely off chain. Only nickname registration happens on-chain; in this way, every wallet builds up a White Pages database mapping Rialto users to public keys. This ensures newly joining or reindexing clients will build a full White Pages, and that registrations are subject to all pre-existing transaction validation.

As well as the global White Pages, wallets store a list of their own Rialto nicks (for which the wallet has the private key), and a local block list. These databases are stored using wrapper classes around the existing LevelDB system used to store the chainstate.

Storing actual chat messages on-chain is neither required not desirable. We're not interested in having to wait for the next block in order to send or receive a chat message.

Rather, Rialto leverages the other, lesser-talking-about benefit of cryptocurrencies: As well as a blockchain, we have a brilliantly resilient and battle-tested peer-to-peer network.

This is especially true in the case of LCC, as our Hive Mining system requires wallets to stay online, bolstering the P2P network significantly compared to other cryptocurrencies.

Rialto messages propagate between peers in exactly the same way as new mempool transactions are passed around, using the existing inv/getdata flow.

Cryptosystem

A Rialto message has a 3-layer envelope, as shown below:

Rialto cryptosystem

The core part of the encryption is ECIES, which is used to generate the Layer 2 envelope in the diagram above.

Our choice of ECIES internal algorithms reflects our approach of using the primitives already present in the codebase: AES-256-CBC encryption, SHA512 key derivation, and HMAC-SHA256 message authentication code.

One of the strengths of the ECIES approach is that it is impossible to tell by examining a message in transit who either the sender or recipient are. Therefore, every wallet must attempt to decrypt every message in order to tell if the recipient is a nick which is local to that wallet. Note that to prevent network-based inference of recipients in the case where an adversary controls a disproportionate number of network nodes, an incoming encrypted message is still forwarded to all peers even if the wallet was able to decode it.

ECIES also provides a certain amount of forward secrecy. Even if an attacker captured all encrypted messages in the hope of later decrypting them, and a user's private key was subsequently compromised, the attacker could not decrypt previously captured messages sent by that user. This is due to the use of a fresh ephemeral secp256k1 private key during every encryption, which is instantly discarded.

The HMAC feature of the ECIES implementation allows a message recipient to positively identify that they are the intended recipient of a message, but does not guarantee the sender is who they claim to be. For this reason, the inner Layer 1 (plaintext) envelope includes a message signature that the recipient verifies against the sender's public key from the Rialto White Pages.

A combination of non-free nick registration cost, local block lists, and a Minotaur proof-of-work component in the outer Layer 3 envelope, should together minimise spam.

The proof-of-work component is designed to only require about 1 second of solve time on average hardware so as not to unduly inconvenience users. This uses our faster and less taxing Minotaur hash rather than MinotaurX.

Two potential types of replay attack are also prevented. The first is a mischievous user observing traffic and causing messages to repeat by extracting the encrypted Layer 2 envelope, repackaging it with new proof-of-work, and rebroadcasting it. This would not enable them to identify sender or recipient, or to decrypt the plaintext, but would enable them to cause network congestion and for the confused message recipient to receive the same message over and over.

This attack is thrawted by requiring the timestamp in the Layer 3 envelope, which forms part of the date the proof-of-work hashes, must match the timestamp present in the Layer 1 (plaintext) inner envelope.

The other attack would be for a legitimate message recipient to reuse the message signature from the Layer 1 plaintext to cause a message they had just received themselves to be rebroadcast to another recipient, fraudulently claiming it came from the original sender.

This is prevented by the presence of the recipient nick in the Layer 1 inner envelope as well as the sender nick, and the fact that the message signature must sign both these fields.

Convenience vs Privacy

There are several comfy features, common to modern chat systems, which we have not currently implemented. ...

Read more

Litecoin Cash v0.16.3

08 Sep 15:47
Compare
Choose a tag to compare

Introduction

This release, which is an essential upgrade for all users, enables voting to activate Hive 1.2 and MinotaurX on mainnet.

The voting period will open at 1200 UTC, 16 Sept 2021. This is expected to be shortly after the halving which will occur at block 2520000. To hasten network activation of our new features, please upgrade before then!

It should be safe to install this version over your current wallet; but as always, back up your wallet.dat first just in case.

MinotaurX and other pow changes

We have built a custom multidimensional mining system to allow us to easily add additional block types. This should fully cure the block stalls that we've seen, which were due to strategic hashpower destination switching on the part of certain sha256d pools.

MinotaurX is a successor to our Minotaur hash algorithm from Ring, and is designed to lock out GPU mining and provide a new CPU mining dimension on LCC.

MinotaurX attempts to follow Satoshi's original "one machine, one vote" vision; on a multicore CPU, devoting additional cores to mining quickly results in diminishing returns. On some architectures, mining on half the available cores gives a higher aggregated hashrate than using all of them.

You can mine LCC with MinotaurX using our cpuminer-multi fork: https://github.com/litecoincash-project/cpuminer-multi/

Our cpuminer supports mining to all main address formats (P2PKH, P2SH, bech32).

Windows and Raspberry Pi cpuminer binaries are available below as part of this release. For Linux or Mac, follow the build instructions at the above repo, in order to optimise the miner for your hardware.

We expect that MinotaurX mining pools will appear shortly, and it is very unlikely that solo mining on mainnet would be profitable. However, here's an example command line for solo mining:

cpuminer.exe -a minotaurx -o http://127.0.0.1:23452 -O rpctest:rpctest --threads=1 --coinbase-addr=MEpvFVw6TRRaC7vUFrUZ5R8ZNENmfepdVT

This would work with a litecoincash.conf set as below:

server=1
rpcbind=127.0.0.1
rpcallowip=127.0.0.1
rpcuser=rpctest
rpcpassword=rpctest
rpcport=23452
powalgo=minotaurx

The 2 pow methods work independently; there is no strict sequencing required, so no miner on either pow method ever needs to idle.

The difficulty adjustment algorithm is changed to LWMA with appropriate parameters. Both pow mining dimensions use their own independent difficulty target. The change in difficulty algo will mean a difficulty reset on UASF activation.

The max future time window for blocks has been tightened. This is partially wallet policy; by running this wallet you're able to benefit from the stricter DEFAULT_MAX_TIME_ADJUSTMENT already. However, the other associated setting (and the most critical one), MAX_FUTURE_BLOCK_TIME, is set by consensus rather than policy and must be activated via the UASF to avoid potential unwanted hardforks.

Block frequencies and economic changes

The target overall block frequency remains 75 seconds (1.25 mins). Within a 5 minute period, where we would previously expect to see 2 sha256d blocks and 2 Hive blocks, we now anticipate 1 sha256 block, 1 MinotaurX block, and 2 Hive blocks.

Following UASF activation, Hive rewards will increase by 50%, while pow rewards will reduce by 50%. Therefore, the Hive honeypot will rise, while realtime bee lifespan will remain unchanged. This should increase the amount of Beekepers on the blockchain and allow more people to Hive mine. In addition, due to the less inflationary nature of hive mining, overall coin inflation will be reduced. The community fund contribution for creating bees has been raised from 10% to 15%, but remains completely optional and doesn't affect the number of bees you create.

Hive 1.2: Leveling the field

The inner hive hash now uses Minotaur. This brings the LCC Hive implementation in line with Ring.

Minotaur is more suitable than MinotaurX for this purpose. Minotaur is approx 14 times slower than the previous inner hive hash algorithm (sha256d), which helps ensure fairness.

Before this change, inner hashing was so fast that once accounting for network speed, beekeepers of large hives would be able to check their hives for a winning bee, and submit the resulting block, with insufficient difference to the time it takes a beekeeper with a relatively small hive to do the same.

This lent an unfair advantage to large hive miners, as identified by DOTTAT and others. Slowing down the inner hash in a linear fashion means more speed difference between large and small hive beekeepers, helping to even out the difference between them.

Because this slowdown results largely from L2 cache teardown induced by Minotaur, rather than outright computational load, no significant energy usage increase is anticipated over Hive 1.1.

The change in inner hash requires a Hive difficulty reset on UASF activation, although the effective custom Hive difficulty algorithm itself remains unchanged.

All bees alive or maturing before activation, will survive activation and will be able enjoy the expanded honeypot explained above.

Note to sha256d ASIC miners

As part of our multi-pow implementation, we have elected to take back control of the 32-bit block version field.

It was previously observed that some ASIC miners would abuse ~13 high bits of the version fields to give them extra nonce space.

This will no longer be tolerated, and block versions are validated more tightly. To ensure your blocks don't get rejected, we recommend using the exact version field value that getblocktemplate gives you.

RPC / Config changes

getblockheader and getblock will now show the algo for a given pow block.

Block templates differ between MinotaurX and sha256d blocks. Therefore, the getblocktemplate RPC method accepts a new parameter, powalgo, to specify either minotaurx or sha256d:

getblocktemplate '{"powalgo":"minotaurx"}'

or

getblocktemplate '{"powalgo":"sha256d"}'

This allows the same wallet to host miners on both algorithms simultaneously.

However, in order to avoid inconveniencing miners and pool operators who aren't able to easily change their mining software to support the additional parameter, you can alternatively specify powalgo as either a command-line wallet parameter:

./litecoincashd -powalgo=minotaurx

or in litecoincash.conf:

powalgo=minotaurx

If you don't specify powalgo at all, and keep your entire config as it is, the wallet will default to sha256d mining - again, this is to minimise any inconvenience for existing pool operators and other service providers.

For maximum versatility, even if you specify powalgo via conf or command-line, you can still override that setting by passing the powalgo argument to getblocktemplate.

getblockchaininfo will now show the latest block's difficulty for both sha256d and MinotaurX. The MinotaurX difficulty field is named "minotaurxdifficulty", but for maximum compatibility with existing 3rd party software the sha256d difficulty field is still named just "difficulty".

In a similar manner to getblocktemplate, getdifficulty and getnetworkhashps also accept a powalgo argument, and assume the wallet's default pow algo if this argument is not passed.

Call help on any of these RPC calls to see the changes.

Litecoin Cash v0.16.2.3

18 Aug 16:54
Compare
Choose a tag to compare

You DON'T need to upgrade to this release if you're only interested in using LCC mainnet.

This release resets testnet with tweaked economic parameters. It also incorporates a rollback of inner Hive hash to Minotaur (not MinotaurX), which is more suitable for this purpose.

PoW mining remains MinotaurX and sha256d.

As this is a reset, you won't be able to use your old testnet wallet or tLCC coins.

It should be safe to install this over your current wallet; but as always, back up your wallet.dat first just in case.

The fresh testnet chain will sync very quickly.

After a period of public testing and review, a future release (0.16.3) will enable voting for activation of these features on mainnet.

Litecoin Cash v0.16.2.2

11 Aug 14:06
Compare
Choose a tag to compare

You only need to update to this release if you are hive mining on testnet.

Without resetting testnet, this release fixes a memory leak in the hive check threads.

It should be safe to install this over your current wallet; but as always, back up your wallet.dat first just in case.

Litecoin Cash v0.16.2.1

27 Jun 18:59
dc80c78
Compare
Choose a tag to compare

You DON'T need to upgrade to this release if you're only interested in using LCC mainnet.

This release resets testnet to correct a difficulty adjustment issue. As this is a reset, you won't be able to use your old testnet wallet or tLCC coins.

It should be safe to install this over your current wallet; but as always, back up your wallet.dat first just in case.

The fresh testnet chain will sync very quickly.

After a period of public testing and review, a future release (0.16.3) will enable voting for activation of these features on mainnet.

Litecoin Cash v0.16.2

15 May 21:15
Compare
Choose a tag to compare

Introduction

This release introduces several new features to testnet, which will soon make it to mainnet. You DON'T need to upgrade to this release if you're only interested in using LCC mainnet.

It should be safe to install this over your current wallet; but as always, back up your wallet.dat first just in case.

Testnet has been RESET. You won't be able to use your old testnet wallet or tLCC coins; they're all gone!

The fresh testnet chain is initially less than 1000 blocks, so will sync very quickly. All below features are active on testnet right now.

After a period of public testing and review, a future release (0.16.3) will enable voting for activation of these features on mainnet.

MinotaurX and other pow changes

We have built a custom multidimensional mining system to allow us to easily add additional block types. This should fully cure the block stalls that we've seen, which were due to strategic hashpower destination switching on the part of certain sha256d pools.

We've learnt a lot from our experience with Minotaur, our custom hash algorithm used on the experimental Ring chain. Our improved version, MinotaurX, has succeeded in locking out GPU mining once again, and this will provide a new CPU mining dimension on LCC. You can call it "minx" if you like, we don't mind! We must say a big thanks to the Neoncoin team, with whom we worked on improving Minotaur, for their collaborative assistance with this development.

MinotaurX attempts to follow Satoshi's original "one machine, one vote" vision; on a multicore CPU, devoting additional cores to mining quickly results in diminishing returns. On some architectures, mining on half the available cores gives a higher aggregated hashrate than using all of them.

You can mine tLCC with MinotaurX using our cpuminer-multi fork: https://github.com/litecoincash-project/cpuminer-multi/

Our cpuminer now supports mining to all main address formats (P2PKH, P2SH, bech32).

A Windows cpuminer binary is available below as part of this release. For Linux or Mac, follow the build instructions at the above repo.

Here's an example command line for solo mining:

cpuminer.exe -a minotaurx -o http://127.0.0.1:23452 -O rpctest:rpctest --threads=1 --coinbase-addr=tFHXkzmL1fCAUwzQpAgEPUZdxb2pArwJgu

This would work with a litecoincash.conf set as below:

testnet=1
server=1
rpcbind=127.0.0.1
rpcallowip=127.0.0.1
rpcuser=rpctest
rpcpassword=rpctest
rpcport=23452
powalgo=minotaurx

We expect that MinotaurX mining pools will appear shortly; it is very unlikely that solo mining on mainnet will be practical, and for this reason we haven't included the in-wallet solo miner familiar from Ring.

The 2 pow methods work independently; there is no strict sequencing required, so no miner on either pow method ever needs to idle.

The difficulty adjustment algorithm is changed to LWMA with appropriate parameters. Both pow mining dimensions use their own independent difficulty target. The change in difficulty algo will mean a difficulty reset on UASF activation.

The max future time window for blocks has been tightened. This is partially policy; mainnet users are able to benefit from the stricter DEFAULT_MAX_TIME_ADJUSTMENT already. However, the other associated setting (and the most critical one), MAX_FUTURE_BLOCK_TIME , is consensus rather than policy and must be activated via the UASF to avoid potential unwanted hardforks.

Block frequencies

The target overall block frequency remains 75 seconds (1.25 mins). Within a 5 minute period, where we would previously expect to see 2 sha256d blocks and 2 Hive blocks, we now anticipate 1 sha256 block, 1 MinotaurX block, and 2 Hive blocks.

Therefore, Hive honeypot and realtime bee lifespan should remain unchanged. Block rewards also remain unchanged.

Note to sha256d ASIC miners

As part of our multi-pow implementation, we have elected to take back control of the 32-bit block version field.

It was previously observed that some ASIC miners would abuse ~13 high bits of the version fields to give them extra nonce space.

This will no longer be tolerated, and block versions are validated more tightly. To ensure your blocks don't get rejected, we recommend using the exact version that getblocktemplate gives you.

Hive 1.2: Leveling the field

The inner hive hash now uses MinotaurX. This brings the LCC Hive implementation in line with Ring.

MinotaurX is much slower than the previous inner hive hash algorithm.

Before this change, inner hashing was so fast that once accounting for network speed, beekeepers of large hives would be able to check their hives for a winning bee, and submit the resulting block, with insufficient difference to the time it takes a beekeeper with a relatively small hive to do the same.

This lent an unfair advantage to large hive miners, as identified by DOTTAT and others. Slowing down the inner hash in a linear fashion means more speed difference between large and small hive beekeepers, helping to even out the difference between them.

Because this slowdown results largely from L2 cache teardown induced by MinotaurX, rather than outright computational load, no significant energy usage increase is anticipated over Hive 1.1.

The change in inner hash requires a Hive difficulty reset on UASF activation, although the very effective custom Hive difficulty algorithm itself remains unchanged.

Note that for testnet expediency, the bee maturation period is only 40 blocks.

RPC / Config changes

getblockheader and getblock will now show the algo for a given pow block.

Block templates differ between MinotaurX and sha256d blocks. Therefore, getblocktemplate accepts a new parameter, powalgo, to specify either minotaurx or sha256d:

getblocktemplate '{"powalgo":"minotaurx"}'

or

getblocktemplate '{"powalgo":"sha256d"}'

This allows the same wallet to host miners on both algorithms simultaneously.

In order to avoid inconveniencing miners and pool operators who aren't able to easily change their mining software to support the additional parameter, you can alternatively specify powalgo as either a command-line wallet parameter or in litecoincash.conf.

For maximum versatility, even if you specify powalgo via conf or command-line, you can still override that setting by passing the powalgo argument to getblocktemplate.

getblockchaininfo will now show the latest block's difficulty for both sha256d and MinotaurX. The MinotauX difficulty field is named "minotaurxdifficulty", but for maximum compatibility with existing 3rd party software the sha256d difficulty field is still named just "difficulty".

In a similar manner to getblocktemplate, getdifficulty also accepts a powalgo argument, and gives difficulty for the wallet's default pow algo if this argument is not passed.

Call help on any of these RPC calls to see the changes.

Reviewing the changes

The key commit is here.

As is our custom, every changed line or block is marked with a specially formatted comment. If you prefer to browse code rather than git history, search the codebase for "// LitecoinCash: MinotaurX" to see all our changes.

Important Reminders

  • Unless he signs something with an appropriately early key, Craig Wright is not Satoshi Nakamoto, and you can safely ignore him.
  • Get your vaccination if it's available.
  • Practice safe forking; transfer your funds (e.g. LTC) to a new address before importing the private key of the old address to claim funds on a fork (e.g. LCC). This applies to ANY fork - including ours.

Litecoin Cash v0.16.1.3

11 Feb 11:48
Compare
Choose a tag to compare

This is mostly a quality-of-life release, but due to a fix for an occasional Hive checking issue is strongly recommended for all beekeepers.

  • Added maxoutboundconnections commandline/config argument. Defaults to the previously hardcoded value of 8.
  • Fixed intermittent startup crash observed on fast machines with SSD chainstate
  • Fixed MacOS UI scaling issues
  • Hive tab layout tweaked to allow full wallet display on lower-res screens
  • Fixed incorrect ICC profiles in PNGs
  • Fixed occasional binning issue

Litecoin Cash v0.16.1.2

26 Nov 15:10
Compare
Choose a tag to compare

This release brings the power of multi-threaded hive checking to the core wallet. It does not change consensus rules, but is strongly recommended for all beekeepers.

In addition, new early-abort tests ensure that your hive won't waste time working on a stale block when it could be trying to find a fresh one.

Three new command-line/config-file parameters are available:

-hivecheckdelay : Time between Hive checks in ms. This should be left at default unless performance degradation is observed (default: 1)

-hivecheckthreads= : Number of threads to use when checking bees, -1 for all available cores, or -2 for one less than all available cores (default: -2)

-hiveearlyabort : Abort Hive checking as quickly as possible when a new block comes in. This should be left enabled unless performance degradation is observed. (default: true)

These options can also be checked and set via new RPC commands gethiveparams and sethiveparams (see full RPC documentation at https://hive.litecoinca.sh/rpc/).

In 99% of cases, the default options should work fine for you.

Multithreaded hive checking does not depend on any particular distribution of bees across BCTs. All bees are pooled together and then binned into threads, so it doesn't matter if you have a large number of low value BCTs, a small number of large value BCTs, or any mixture -- you still benefit from the same speedup.

Special acknowledgements for this release go to the LCC Release Staging team, and particularly DOTTAT and rabTAI for extensive testing and feature ideas, and to uross for building Pi binaries.

Litecoin Cash v0.16.1.1

20 Sep 21:39
Compare
Choose a tag to compare

This update is recommended for QT (desktop) wallet users on all platforms.

It provides correct GI and honeypot display either side of Hive 1.1 activation, with thanks to DOTTAT.

Thanks to uross for the Raspberry Pi builds.

Litecoin Cash v0.16.1.0

20 Sep 18:42
Compare
Choose a tag to compare

This is an essential update for all users.

This release is capable of activating Hive 1.1 consensus rules on mainnet.