[ANN] Litecoin - a lite version of Bitcoin. Launched!

[Monopoly]

Nice prices for Litecoin ........ this is skyrocketing and surprises without explanation ..... i bought so many coins at $1

[1714244923]

1714244923

[1714244923]

1714244923

[1714244923]

1714244923

[1714244923]

1714244923

[thrasher]

I work on Litecoin Core and know about this testnet issue, I was the one who also made a post advising users to stop mining on 0.8.7.x and upgrade to 0.10.2.2 whilst also setting up a private pool to orphan the version 2 chain. After our notification and to encourage others to begin mining, I lowered my testnet pools mining intensity. In doing so, version 2 blocks got the lead again which lasted in a small fork. If you actually looked at testnet recently, you would see that this issue has now been corrected and my pool settings will permanently stay like this until I see no more 0.8.x miners (subject to availability obviously). The block height is currently at 646208 in which I'm currently connected to over 25 nodes (similar to the dedicated testnet node we have setup), all reflecting this. This can also be verified by a block explorer site like http://blockchains.io/ltct/blocks/

Also, please don't make ridiculous claims that we don't know what we are doing, we know very well what is in Litecoin Core, including the causation of this and we know how to resolve issues like this (as shown above) and is why we contacted all pools to make sure that mainnet encounters a smooth transition for BIP66 activation (which has had 0 problems). Your concern stating that 'if somebody managed to split the testnet that far there maybe a bug lurking in the code that could be used to split the mainnet' is clearly unfounded and shows inadequate knowledge of how this issue occurs. If people could do it on mainnet, they would. BTW, this issue also occurred on Bitcoin's testnet https://blog.blocktrail.com/2015/06/bitcoin-testnet-is-forking-19-blocks-deep-and-counting/, admittedly it isn't a good thing to have happen on testnet, but both Bitcoin and Litecoin devs were extremely focused on mainnet BIP66 activation, as testnet is low priority which can always be reset accordingly if things go haywire (which has been done in the past).

I'm sorry thrasher, but I still think that you seem to be missing the root cause of the problem exhibited on the Litecoin testnet. I'll write it in single sentence in a separate paragraph to avoid it getting lost in a wall of text.

The problem with the new 0.10.* nodes seem to be that they maintain the mutual connections but under certain circumstances cease to listen or distribute the newly mined blocks.

Running a single pool that overwhelms the combined competition from all the old 0.8.* nodes is a neat workaround and a temporary safety measure. But they still have the advantage that they correctly pass the mined blocks amongs themselves and properly cumulate the hashing power of the individual nodes into their (sub-)net-wide hashing power.

This cumulation ceased occurring on the 0.10.* sub-net, so the net-wide hashing power is no longer the sum of the individual hashing powers of the nodes that were actively mining. Before you started or restarted your pool I was CPU-mining on my several test nodes and I nearly immediately noticed the stalls after upgrading from 0.8.* to 0.10.*.

I'm currently in the process of moving, so I'm back to running a single node and thus I cannot easily reproduce this problem or search the logs of orphaned transactions.

But I believe the bug is still there and as soon as you stop your pool it will reoccur.

The remaining questions are:

1) is this bug new to Litecoin codebase or was imported from the Bitcoin codebase,

2) is this bug exploitable on the mainnet or is particular to the testnet behavior where it temporarily switches to minimum difficulty under certain conditions.

None of what you said is unexpected behavior. During the fork, there were a majority of 0.8 nodes relaying version 2 blocks being mined and no version 3 blocks being mined. This caused the v0.10 nodes to appear 'hung'. If you checked the nodes log file, you would see many ERROR: ContextualCheckBlockHeader : rejected nVersion=2 block errors signifying that your node is receiving blocks but is not going to process it due the BIP66 enforcement. During the fork incident, there were some people who upgraded their 0.8 nodes to become 0.10 nodes but had the 0.8 chain data and were attempting to relay it to 0.10 nodes, which they obviously rejected. This is only solved by the people who upgraded their nodes from 0.8.x running -reindex to rebuild a valid chain, in accordance with the BIP66 ruleset which 0.10 supports, or they simply wait until the valid v3 chain takes over, forcing a reorg and and they will start accepting the blocks again.

Whilst we were in the process of taking over the invalid chain, we setup a dedicated node which people could connect to via addnode or -connect in order to bypass any issues until the v3 chain became the main one (as what was explained in my announcement). Also, since the pool is GPU mining as it was guaranteed to take over the v2 at the time, your CPU mining nodes would of experienced issues finding blocks because of the adjusted difficulty which might of appeared to you as 'stalling.' if the pool were to experience downtime. As explained previously, I attempt to operate the pool with high uptime but there may be periods of X minutes to possibly even an hr or two until it comes back online which may also appear to you as 'stalling'. FYI, the pool will continue to operate until the v2 miners upgrade.

If you start up a node and do a fresh sync now, you'll encounter no issues since ALL nodes (0.8 and 0.10) are on the same chain. Note, if the pool does go do down and the v2 chain does take over, a 'hung' node is possible until blocks start getting mined again, which is totally expected behavior and nothing to be concerned about (apart from the fact that we need more 0.10 testnet miners). And to address your other concern, we use the same block propagation and relaying code as Bitcoin core so this behavior isn't Litecoin specific, nor network specific.

Also, let me reiterate, if this was an actual issue, Bitcoin and Litecoin's main network would be experiencing issues (which they are not). Relaying of blocks and transactions to other nodes fine.

[chriswen]

So 20 days until the halvening. Anyone excited?

[TheMage]

So 20 days until the halvening. Anyone excited?

[2112]

None of what you said is unexpected behavior. During the fork, there were a majority of 0.8 nodes relaying version 2 blocks being mined and no version 3 blocks being mined. This caused the v0.10 nodes to appear 'hung'. If you checked the nodes log file, you would see many ERROR: ContextualCheckBlockHeader : rejected nVersion=2 block errors signifying that your node is receiving blocks but is not going to process it due the BIP66 enforcement. During the fork incident, there were some people who upgraded their 0.8 nodes to become 0.10 nodes but had the 0.8 chain data and were attempting to relay it to 0.10 nodes, which they obviously rejected. This is only solved by the people who upgraded their nodes from 0.8.x running -reindex to rebuild a valid chain, in accordance with the BIP66 ruleset which 0.10 supports, or they simply wait until the valid v3 chain takes over, forcing a reorg and and they will start accepting the blocks again.

Whilst we were in the process of taking over the invalid chain, we setup a dedicated node which people could connect to via addnode or -connect in order to bypass any issues until the v3 chain became the main one (as what was explained in my announcement). Also, since the pool is GPU mining as it was guaranteed to take over the v2 at the time, your CPU mining nodes would of experienced issues finding blocks because of the adjusted difficulty which might of appeared to you as 'stalling.' if the pool were to experience downtime. As explained previously, I attempt to operate the pool with high uptime but there may be periods of X minutes to possibly even an hr or two until it comes back online which may also appear to you as 'stalling'. FYI, the pool will continue to operate until the v2 miners upgrade.

If you start up a node and do a fresh sync now, you'll encounter no issues since ALL nodes (0.8 and 0.10) are on the same chain. Note, if the pool does go do down and the v2 chain does take over, a 'hung' node is possible until blocks start getting mined again, which is totally expected behavior and nothing to be concerned about (apart from the fact that we need more 0.10 testnet miners). And to address your other concern, we use the same block propagation and relaying code as Bitcoin core so this behavior isn't Litecoin specific, nor network specific.

Also, let me reiterate, if this was an actual issue, Bitcoin and Litecoin's main network would be experiencing issues (which they are not). Relaying of blocks and transactions to other nodes fine.

Sadly, not much communication had occurred in our discussion.

Forget about v2 blocks. The forks occur with exclusively v3 blocks with all nodes running 0.10.2.2.

The RPC command "getchaintips" doesn't lie (amongst many more trivial forks):

Code:

    {
        "height" : 642020,
        "hash" : "f979424831796342c3cd4cce98d33b1c6d2bc7e908270114fbd01d9110120f20",
        "branchlen" : 542,
        "status" : "valid-fork"
    },

Valid fork of 542 blocks (all of them v3) is not a symptom of normal operation. This is a symptom of grave failure of convergence to the consensus. Regretfully I'm in the process of moving, therefore I cannot post the similar, but non-identical forks that occurred on other nodes that I had running at that time.

Probably by running a single-address & single-node pool you are precluding the bug from reoccurring. This is a workaround, not a fix. I see your post as an explanation of the theory of operation, you don't seem to be even interested in reproducing the bug. And the bug will probably reoccur as soon as you stop pool mining on the testnet.

[thrasher]

None of what you said is unexpected behavior. During the fork, there were a majority of 0.8 nodes relaying version 2 blocks being mined and no version 3 blocks being mined. This caused the v0.10 nodes to appear 'hung'. If you checked the nodes log file, you would see many ERROR: ContextualCheckBlockHeader : rejected nVersion=2 block errors signifying that your node is receiving blocks but is not going to process it due the BIP66 enforcement. During the fork incident, there were some people who upgraded their 0.8 nodes to become 0.10 nodes but had the 0.8 chain data and were attempting to relay it to 0.10 nodes, which they obviously rejected. This is only solved by the people who upgraded their nodes from 0.8.x running -reindex to rebuild a valid chain, in accordance with the BIP66 ruleset which 0.10 supports, or they simply wait until the valid v3 chain takes over, forcing a reorg and and they will start accepting the blocks again.

Whilst we were in the process of taking over the invalid chain, we setup a dedicated node which people could connect to via addnode or -connect in order to bypass any issues until the v3 chain became the main one (as what was explained in my announcement). Also, since the pool is GPU mining as it was guaranteed to take over the v2 at the time, your CPU mining nodes would of experienced issues finding blocks because of the adjusted difficulty which might of appeared to you as 'stalling.' if the pool were to experience downtime. As explained previously, I attempt to operate the pool with high uptime but there may be periods of X minutes to possibly even an hr or two until it comes back online which may also appear to you as 'stalling'. FYI, the pool will continue to operate until the v2 miners upgrade.

If you start up a node and do a fresh sync now, you'll encounter no issues since ALL nodes (0.8 and 0.10) are on the same chain. Note, if the pool does go do down and the v2 chain does take over, a 'hung' node is possible until blocks start getting mined again, which is totally expected behavior and nothing to be concerned about (apart from the fact that we need more 0.10 testnet miners). And to address your other concern, we use the same block propagation and relaying code as Bitcoin core so this behavior isn't Litecoin specific, nor network specific.

Also, let me reiterate, if this was an actual issue, Bitcoin and Litecoin's main network would be experiencing issues (which they are not). Relaying of blocks and transactions to other nodes fine.

Sadly, not much communication had occurred in our discussion.

Forget about v2 blocks. The forks occur with exclusively v3 blocks with all nodes running 0.10.2.2.

The RPC command "getchaintips" doesn't lie (amongst many more trivial forks):

Code:

    {
        "height" : 642020,
        "hash" : "f979424831796342c3cd4cce98d33b1c6d2bc7e908270114fbd01d9110120f20",
        "branchlen" : 542,
        "status" : "valid-fork"
    },

Valid fork of 542 blocks (all of them v3) is not a symptom of normal operation. This is a symptom of grave failure of convergence to the consensus. Regretfully I'm in the process of moving, therefore I cannot post the similar, but non-identical forks that occurred on other nodes that I had running at that time.

Probably by running a single-address & single-node pool you are precluding the bug from reoccurring. This is a workaround, not a fix. I see your post as an explanation of the theory of operation, you don't seem to be even interested in reproducing the bug. And the bug will probably reoccur as soon as you stop pool mining on the testnet.

Plenty of discussion has taken place, with explanations, not theories on why this happens regarding BIP66 enforcement and how IsSuperMajority soft-forks work which is what this all stemmed from and you didn't seem to understand that and thought it was a bug (and still do). The Litecoin developers and I are very interested in potential issues, but not ones which have a rational explanation. Not to mention it seems as though you take pride in posting doom posts in 'Litecoin is dead' threads or saying that the Litecoin developers don't care about testnet issues, so your initial intentions seem to be hostile. As I have repeatedly said, my mining pool is 'not precluding the bug', its simply used as a majority wins solution to ensure v3 blocks make up the main chain until more miners join in. During testnet pool down time and v2 miners continuing block propagation, there WILL be forks until the majority of testnet miners are mining v3 blocks, this is exactly how consensus works (majority wins) and is unavoidable until then. To reiterate once again, If v2 blocks are mined and no v3 blocks are, all 0.10 nodes will reject the v2 blocks as per BIP66 enforcement consensus rule and will idle until v3 blocks are mined - obviously resulting in a fork as the 0.8 nodes will happily accept the v2 blocks. For production networks, simply look at the Bitcoin and Litecoin main networks to see incentivised mining propagation of version 3 blocks, and also notice how there is NO issues with v2 miners and also no consensus issues.

With the example you pasted, that is an example of a time period where there were v2 forks and a conquenence of a fork, which is easily resolved by either connecting to a node with a higher block sync or starting your client with -reindex (as what was announced here: https://litecointalk.org/index.php?topic=26793.0 NOTE: the block height).

As it stands now, I'm currently connected to 93 nodes, in which almost all other nodes are fully synced to the highest block (both 0.8 and 0.10 nodes). Note, this was taken from a dedicated Litecoin testnet node, not the mining pool relaying node, being a good reflection of network consensus status:

"height" : 660012,
"hash" : "bb017d63fb3f35f8204d4bb9e69969109fe73227a33e571eb5e443391d6e2e32",
"branchlen" : 0,
"status" : "active"

Once again, there is absolutely no 'grave failure of convergence to the consensus' bug otherwise you would see the same thing on Bitcoin and Litecoin's main networks.

[Belligerent Fool]

Where's all the Litceoin hype ? lol

[kingscrown]

Where's all the Litceoin hype ? lol

halves in 12 days.
price should go up!

[hoie6060]

Where's all the Litceoin hype ? lol

halves in 12 days.
price should go up!

Look like the price is still low, bu rebounding from the bottom.

[ValleyOfTheWolves]

Anyway LTC no mather what we will see 20 dollar soon

[TheMage]

Happy halving day everyone! 

[coblee]

Yup, happy halving day!

How is this thread only 140 pages?!? 

[Testing Crypto]

  1/2ing Day

Edit: Simple Machines, then & now =

[Nthused]

Halving day and nothing happened to price lol fingers crossed though.

[Wekkel]

Halvings are buy before the rumor, sell before the news.

[ValleyOfTheWolves]

This ain't bullshit coin this is Litecoin we wil see positive signs in short time

[TheMage]

This ain't bullshit coin this is Litecoin we wil see positive signs in short time

Sorry I couldnt resist after reading that 

[ValleyOfTheWolves]

This ain't bullshit coin this is Litecoin we wil see positive signs in short time

Sorry I couldnt resist after reading that 

exactly

[kprell40]

 Like some free litecoin go to faucet
 http://moonliteco.in/?ref=f45753ff1352

[Furio]

Anyway LTC no mather what we will see 20 dollar soon

Due enlighten us in your wisdom, how can you know