Topic: [ANN] Litecoin - a lite version of Bitcoin. Launched! - page 279. (Read 1467295 times)

  1/2ing Day

Edit: Simple Machines, then & now =

Yup, happy halving day!

How is this thread only 140 pages?!? 

Happy halving day everyone! 

Anyway LTC no mather what we will see 20 dollar soon

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

halves in 12 days.
price should go up!

Where's all the Litceoin hype ? lol

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.

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

So 20 days until the halvening. Anyone excited?

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.

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

Litecoin lead the way...and litecoin is the winner 

LITECOIN.ID | http://www.litecoin.id
[Litecoin dot Id]
Domain name Litecoin for Sale
[Identity] Id for Litecoin
contact us : [email protected]
Twitter : http://www.twitter.com/litecoindotid

If it's true so we are waiting for BtC to $30K

waiting for LTC to 50 $

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.

Always the best for me. Or its the one that comes up next.

Have you launched the new wallet? What I mean is, there will not be a wallet.dat file until the program is executed the first time. Just an idea.

So I have Yosemite Operating System on a Mac.

I cannot find the Litecoin wallet.dat file.

There is no Litecoin folder under the Applications Support folder under the home library.

There is no "Library" folder under the Admin user and thus no Applications Support folder.

The Applications Support folder under Guest user is empty.

I have gone through all the other system folders and found nothing.

When I "show package contents of Litecoin-LQ" I see Litecoin folders/docs but not the wallet.dat file.

I am trying to restore an older wallet.dat file from a external hard drive but cannot find the one that exists somewhere on my computer that I will need to replace.

Any HELP would be much appreciated!

Thanks in advance.