The market needs a good DEX to maintain the fairness of participants. We have found such a method in a certain mathematical model and can't wait to share and discuss with you.

The optimized luck2 wallet has been released, which does not affect the nodes and wallets. The updated content are as follows:
1 The password input of the windows wallet is displayed as ***
2 Display the plotting status.

At present, luck2's system running well, and the source code will be opened in the near future.

The second round of testing has been released, and the testing method is the same as the first round.

This will enable 2 groups to continue mining, with ASIC mining specialists on the one side and your smaller CPU/GPU group on the other. 

hi there, it would be great if you post the progress and marketing plan on discord. Thanks 

It's dead. It's monopolized by a few miners.It's not luck at all.

Hello everyone, after our careful analysis of your opinions and careful thinking, we finally decided to keep the 50000 premine, and the rest will be burned after 2 days.
The remaining premine will be used for:
26400 - Reward for two-year seed servers: 1100 * 12 * 2 = 26400
23600 - used for community incentives for the past year

In addition, our recent development plan is as follows:
1 android decentralized wallet - the development of basic functions has been completed, and it can be released after the test is completed.
2 Enable multi-core mining - in the early days, we suggest the miner to open multi-instance mining on multi-core machines, which brought complexity to the operation of miners. In response to the urgent request of the majority of miners, multi-core mining on multi-core machines will be supported, this feature is currently being scheduled.

I see your point of view: the nodes.

Here is mine: the coins.

Maybe you fixed the node problem pools have, but you have a new problem - all the coins goes now to a single owner, instead of multiple owners. This is why I've said is worst than traditional PoW, instead of a pool getting 50% of mined coins (which will be spread among all individual miners) now we have 1 miner getting 50% of the coins, but we are pool free.

And not to be negligible, with this approach the scenario can go like this: Let's say I mine solo (because there are no pools involved) but since is not profitable for me because 1 single miner gets 50% of all block, I leave. So will do all the small miners, if is not profitable anymore and this will lead him to mine more and more blocks until probably he will mine 100% of the blocks.

Now tell me, where is the decentralization?

It is probably possible to create hidden, P2P-based mining pool on this coin.

At first, all nodes are solo mining as it is today, using official client. Then, people start noticing that they have to wait more and more time to receive their rewards. The overall difficulty to mine a block is getting harder, because there are more and more people mining this coin.

To solve this problem and receive something more frequently, people start cooperating with each other to produce something together and share their reward. To do this in a P2P-based, fully decentralized way, people start producing shares. A share is just a valid block with easier difficulty. So anyone can just modify original client a bit and start producing shares. The algorithm to achieve this is quite simple: if block hash is below share-difficulty, it is a valid share and can be broadcasted to pool nodes. If it also meets network difficulty, it can be broadcasted to the whole network.

Because some people are probably going to destroy all mining pools they can find, everything should be done in secret. So, to start with, people are sending shares only to explicitly listed nodes and to nobody else. To prevent detecting it by some adversary node sending shares to mining pool, the acceptance of the share is not announced to anyone (even "trusted pool nodes") explicitly. When pool node receives some block meeting share-difficulty and not meeting network-difficulty, it should respond with "block invalid" message if asked by anyone, but it should notice that the share is valid and prepare some transaction paying some coins to the share-creator.

After getting some shares from some nodes, each pool node independently broadcasts transaction paying nodes their rewards. It is a normal transaction, so there is nothing that adversaries can do to prove that it is a payment from mining pool. Also, as a normal transaction, other nodes can receive and broadcast it, so tracing the first node that produced this transaction seems to be impossible. Any inputs can be used to produce this transaction and also such transactions can be coinjoined, so finding the creator in a M inputs to N outputs transaction when M and N are greater than two is not possible with 100% accuracy.

There is nothing to lose using this method. Every pool node is also solo mining, shares are produced in the same way as normal blocks, except they have easier difficulty. To prevent spam, every node should decide how many times easier this difficulty should be. It is also possible to do some performance testing and just collect blocks locally to determine how many times easier this share-difficulty should be. Because everything that is needed to produce the next block is the hash of the previous one, it is also possible to run one instance of the original client and attach to it from many mining clients, getting only previous block header (and maybe also pending transactions or some stuff similar to getblocktemplate in Bitcoin). It is probably also possible to create some stratum-like protocol and produce only data needed by block headers, shared with every connected node.

However, the simplest possible way is just sending blocks. It is compatible with all clients. So, the node is solo mining and sending some shares to some trusted nodes. At the beginning, it is possible to communicate with some other miners owned by the same miner. Later it is possible to trust someone for a while and send some shares to it. If after some time the node receives some coins, it is marking such node as trustworthy and still sending shares to it. If not, it is marking it as a solo-only node and choose another node. In this way it is possible to find modified clients in a P2P-way instead of some centralized way.

It looks like the block rewards are added to a state channel

Why? What about one client trying to calculate higher and higher luck all the time? How you can distinguish one node trying different luck all the time from many nodes trying many luck values?

Yes, but it can be one mining address and one node with the highest luck selected during the first phase. And it can be shared with everyone else. And then you will have a choice: mining using your solo luck or mining using pool's luck (which will be probably higher, because for example pool will always choose the highest luck provided by all connected miners).

Why multiplying it by 100 is necessary? Pool operators do not have to mine everything by themselves. All they have to do is validating shares received from miners and for validation you do not have to multiply everything by 100. Minimal requirements for validation would be almost the same as for seed nodes.

By the way, I can see higher and higher pool pressure in my own case. For example at the beginning I mined something around 20 coins per day. Now I am mining something around one coin per day. Sooner or later, when more people will come, it will become one coin per week, per month and then maybe even per year. And then me and other people will sooner or later create or join pools, because it will be more profitable to get some coins regularly than nothing.

Also, pools do not have to be centralized. Maybe something like P2pool will be possible on this coin, for example when each miner will add its own address into shared coinbase. It could also be based on smart contracts, something like "if you provide some header having luck higher than target, you can get some coins from this address".

I guess that "maxluck" is the maximum luck value for all mining nodes in the whole network. It means that instead single, simple proof of work, everyone is calculating some luck and the max value is broadcasted to the network. So: the more nodes you have, the more chances are that you will hit "maxluck". And the more luck you have, the more chances you have to hit the next block.

To sum it up: in proof of work you are calculating the lowest block hash meeting the target and then you can broadcast it when you find it. In luck, you are calculating the highest luck value and then you broadcast it. So there is really not a big difference between mining blocks using proof of work and mining it using luck. Shares in proof of work are basically the same as luck here. You can create some pool and encourage people to find the highest luck and pay them accordingly to their luck. Later, you can just choose the highest luck and encourage everyone to mine on it, because there are the highest chances of finding a block. And since there are many miners trying to mine on the same luck, it will probably be found faster than every solo miner, because you have "difficulty*numberOfMiners" instead of "difficulty*1", so it is "numberOfMiners" times easier to mine a block.

I hope I am wrong, but it seems that creating pools will still be possible here and they will be profitable.

Since the source code is not yet opened, here is a brief description of the mining algorithm of the Luck project.
Mining parameters:
    alpha -> The mining difficulty parameter of the first phase, that is, hash(first header, first nonce) <alpha
    luck -> After the first phase is completed, luck = f(header, first nonce)
    basis -> Difficulty base of the second phase of mining.
    beta -> The mining difficulty parameter of the second phase, that is, hash(second header, second nonce) <beta, where beta = basis * (maxluck / (maxluck-luck)) ^ 2.

The algorithm of the mining process as:
1. alpha, basis = pre_compute (difficulty adjustment strategy, the current block generation is too fast, reduce alpha and basis; the current block generation is too slow, increase alpha and basis. When the difficulty of the first phase is too large, reduce the basis; when the second phase is too difficult, increase the basis)

2. Find a suitable firstNonce such that hash(first header, firstNonce) <alpha

3. Calculate the luck value by luck = f(header, firstNonce)

4. Calculate the difficulty parameter of the second phase beta = basis * (maxluck / (maxluck-luck)) ^ 2

5. Find a suitable secondNonce such that hash(second header, secondNonce) <beta.

6. Pack the parameters into the block to complete the mining

From the above process, it can be seen that as the luck value increases in the second phase, the difficulty of mining in the second phase will decrease sharply. For example, when multiple nodes cooperate in mining, the luck value is more likely to be a medium luck value; when they do not cooperate, the luck value of the highest luck value will be significantly greater than the middle luck value during cooperation, so the difficulty of the node with the highest luck value in the second phase will be drastically reduced.

Another note: Since each mining process is divided into two phases and and cannot be executed in parallel, there is no way to start multi-threaded mining in one mining program. For multi-core machines, you can increase the CPU utilization by enabling multiple mining programs.