I'm posting one last time because I have a bit special respect for billaue:


I may very well be narrow-minded, but I'm 100% sure about this: the most important principle for a cryptocurrency is decentralization of trust. That's why Bitcoin was born, and that's what Monero and other very few legitimate coins stand upon. Any sort of premine just goes right against that principle, no matter what. Developments may need funding, but it can be collected through donations and other ways. Premine as a development fund is just wrong because it creates a special privilege for those controlling the premined coins. Every single effort should be made to decentralize any trust. In fact, Bitcoin and Monero are completely trustless.

I think you're ignorant of this important truth. I admire your skill as a developer (the Python-based GUI wallet and the miner look well engineered), but I believe you're being fooled by Sumoshi. I remember you mentioned previously that you weren't really strongly for or against the idea of premine. I guess your main interest has been only in the programming aspect, but your contribution as a developer will not be fully appreciated if you are on a wrong project.


One doesn't need to contact Monero devs nor obtain a permission to make a donation. The donation address is known in public.

This is fantastic news.



And I have to add:

We have just created a new mining pool for Sumokoin.
High end server, low fee 0.6, central EU


https://Easyhash.io


It would be great if some of you fellow sumokoin miners would come help us get the hashrate up.

This creates further doubt about their true intent. You don't want to talk about your premine, because that's the most shady and ugly essence of Sumokoin. Premine is never justified, and your desire to distract people's attention from it just confirms my doubt.

People, please remember that premine is completely different from the usual donation-based funding model used in other legitimate currencies like Bitcoin and Monero. Donations are collected from the free will of the community members in agreement of who controls the fund and for what purpose to use it. With premine, an unfair financial advantage for the developers is **baked into the protocol**, putting them in a privileged and powerful position. This is practically the same as the dev tax employed in Zcash, which is run by a for-profit company. Is Sumokoin an FOSS project, or a scam run by a for-profit company? I believe the latter is the case.

Thanks to the premined coins being still locked, there's a way to eliminate this accusation: do a hard fork that bans the use of those premine outputs as inputs. Then Sumokoin can become a legitimate currency. Otherwise, I keep calling you as scammers.


OK, "in a couple of days" does that mean 2 days? A week? A month? Or more? You keep damaging your credibility by delaying the release of the source code. The best action for you to do now is to immediately retract the release by deleting the download link.

I understand your concerns. For the premine, as those coins are locked so we have some time to consider about this project, I think it's good as we can leave before the wallet is unlocked.

The miner was released about a week ago, we need Vu to confirm when its source code will be released.

Actually, we all expect devs to be more active. There is less and less information about this project recently (except for the miner).

Need more time to confirm if this is a legit project or not. Give them some time to answer. Don't conclude in haste.

Bill is the wallet-dev. He will read this for sure.

Guys, over at the Sumokoin Telegram we're having a discussion about new potential safety features for Sumokoin. These are suggestions made by some members of the community - we do not speak for the developers nor for the community as a whole. With this in mind, we'd like to hear what everyone else over here thinks about the following:

Emergency Withdrawal: The idea is to have a "fake" wallet password which, if you were to divulge it to someone and that person were to use the "fake" password to access your wallet, an Emergency Withdrawal would be triggered, automatically and instantly withdrawing all of your SUMO to a secondary safe wallet known only to you. Alternatively, instead of having a "fake" password for this, there could be some sort of simple puzzle (like mouse-clicking on 3 or 4 small images in a certain order) that only the wallet owner knows how to solve. You would be required to solve the puzzle before or after accessing the wallet with your password. If the puzzle is not solved correctly, even though the correct password is entered, the Emergency Withdrawal is triggered and all SUMO are transferred to the safe secondary wallet. (This would help against some keylogging attempts.)

Escrow Contract: The idea behind this is to avoid situations where trusted third-party payment escrow providers are tempted to steal the funds when a large transaction is involved, thereby reducing trust in the ecosystem and causing significant losses. With an Escrow Contract, the escrow service provider would never be in control of the escrowed funds. The buyer/seller/escrow would all initiate an Escrow Contract, and a special Escrow Address would be geenrated, after which the buyer would send the funds to that Escrow Address. The escrow provider would then receive a password, which he can use to do only one of two things: either release the funds from the Escrow Address to the merchant, or return the funds to the buyer if the seller does not deliver the goods. The escrow provider has no way of withdrawing the funds to his own address nor of using them any other way. Upon releasing the funds, the escrow provider receives his agreed-upon fee for his services.

Risk Management Feature: Large merchants have a lot to risk. If they lose access to their wallet or an unauthorized party gains access to it, their losses can be catastrophic. Some merchants might choose to control their risks by spreading out their balance across multiple Wallets so that if one is compromised, at least the remaining walltes should be OK. The Risk Management Feature would do exactly that: the merchant would create extra wallets, and whenever they receive a transfer to their main wallet, the transfer amount would be broken up into equal chunks, each of which is sent to one of the other wallts. For example: merchant creates 3 extra wallets, in addition to their main wallet, making for 4 wallets in total. Merchant then activates the Risk Management Feature in their main wallet and and inputs the addresses of the 3 extra wallets in their settings. Now the merchant receives a transfer of, say, 100 SUMO, to his main wallet (the one with Risk Management enabled). The Risk Management system automatically divides the payment into four chunks of 25 SUMO each. One chunk remains in his primary wallet, the second chunk goes to the second wallet, third chunk to third wallet, and fourth chunk to fourth wallet.

Let us know your thoughts and opinions, and please consider using the follwing Strawpoll to let us know which of the three features above you find most interesting: http://www.strawpoll.me/13658630

And make sure to let us know if you have any other ideas - you can do it here or in Telegram. Thanks.

Find below a current short term roadmap (for the next few months).
If anyone wants a higher resolution of the image please message me on telegram
Any suggestions/ideas for improving the layout on this or the next one are more than welcome