[ANN] [SUMO] SUMOKOIN - 🔏 Digital Cash For Highly-Confidential Transactions 🔏

[fuzzyd]

Another interesting project. Since I am quite fond of Monero I see no reason why I shouldn't embrace Sumocoin also. ('Embrace' is admittedly an overstatement - little fish like myself can really only afford to tickle).

[Madinvestor]

Glad to see the project going forward, community is slowly but surely growing !
Nice to see this article about Sumokoin !

https://microcapcrypto.com/sumokoin/

https://t.me/joinchat/F8RH2kPmFCnA-igHBKSCAA

Join the community on Telegram !!!

[Germining]

Since a lot of talking is going on on telegram the forum got really quiet...

Go on and join our chat, we are almost 100 ppl!

[danycoman]

Hello everyone!

At this moment we have    up  pools:
------------------------------------

http://chrc.mine-pool.ro/ ==>0.5%fee

http://bcn.mine-pool.ro/  ==>0.5%fee

http://sumo.mine-pool.ro/ ==>0.4%fee
------------------------------------
Thank you for your interest!

Do not forget! We are with you 12/24! Support live!

Daniel

Support mine-pool.ro

[sumogr]

Hello everyone!

At this moment we have    up  pools:
------------------------------------

http://chrc.mine-pool.ro/ ==>0.5%fee

http://bcn.mine-pool.ro/  ==>0.5%fee

http://sumo.mine-pool.ro/ ==>0.4%fee
------------------------------------
Thank you for your interest!

Do not forget! We are with you 12/24! Support live!

Daniel

Support mine-pool.ro

Thank you danycoman for adding Sumokoin to your pool.
However you must have a misconfig to your script regarding our coin cause the displayed global hashrate is wrong

[danycoman]

Hello everyone!

At this moment we have  up  pools:
------------------------------------

http://chrc.mine-pool.ro/ ==>0.5%fee (tested ok)

http://bcn.mine-pool.ro/  ==>0.5%fee (tested ok)

http://sumo.mine-pool.ro/ ==>0.4%fee (tested ok)

------------------------------------
Thank you for your interest!

Do not forget! We are with you 12/24! Support live!

Daniel

Support mine-pool.ro

Fixed error http://sumo.mine-pool.ro/ ==>0.4%fee (tested ok)

[xs.over]

Botnet-coin.
Almost >95% network hashrate is from large botnet 2Mh

[Germining]

Botnet-coin.
Almost >95% network hashrate is from large botnet 2Mh

You've analysed lots of coins depending on their hashrate, so it would be nice, to give some more information...

Almost all coins with a lot of hashrate not used on official pools you seem to call "botnet-coin". How do you know?

[JC1DA]

Botnet-coin.
Almost >95% network hashrate is from large botnet 2Mh

A statement without any proofs.

[Germining]

New topic: who of you is mining sumo? What rig do you use? Lets do a little tech-talk?

I minded one or two weeks myself (only a short time and just for the fun of it... with my "gaming setup" - a 1070

[novy]

so no bounties at all in near future?

[bzyzny]

@Germining

Yeah the Pascal cards are great for cryptonight mining, my 1060 only uses about 55W and runs cool, so I am not worried about leaving it mining when not gaming. Sumo network hash rate has been pretty steady, but gradually climbing. Easy mining will not last much longer I think.

[syncmaster913n]

104 telegram members and growing. Everyone please join us there, that's where all the news and latest info about Sumokoin is.

[syncmaster913n]

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 make sure to also let us know if you have any other ideas - you can do it here or in Telegram. Thanks.

[Kanati]

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

SOS transfer: 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 SOS transfer would be triggered, automatically and instantly withdrawing all of your SUMO to a secondary wallet that only you know about. 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, the SOS transfer is initiated and all SUMO are transferred to the secondary wallet. (This would help against some keylogging attempts.)

Embeded Escrow: 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 Embeded Escrow feature, the escrow service provider would never be in control of the escrowed funds. The buyer/seller/escrow would initiate an Escrow Transaction, and a special Escrow Address would be created, after which the buyer would send the funds to the Escrow Address. The escrow provider would then receive a password, which can be used to do only one of two things: either release the funds from the Escrow Address to the seller, 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 or 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 separate wallts 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 3 wallet addresses in the 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.

Please let us know what you think, and please consider using the follwing Strawpoll to let us know which of the three features you find most interesting: http://www.strawpoll.me/13658077/r

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

I don't do Telegram so I will offer my 2 cents worth of advice here -

SOS transfer:
Interesting idea! If you decide to do it I would recommend that this feature be optional, and disabled by default. Why? Two main reasons - 1. it increases administration complexity in an already steep learning curve for average users; 2. by increasing the complexity of the code you are increasing the attack surface for hackers.

Embeded Escrow:
This one is tricky because it does not make provision for possible collusion between the escrow provider and one or the other part. I think the best solution would be a 100% automated, but that would require some foolproof method to assure that ownership was actually transferred for the funds to be released (maybe something like online integration with shipping company tracking numbers or online title registration for property?). I think this would be really difficult to do since some degree of centralization (bonded escrow, reputation, whatever...) would be required, and it certainly would not work in every situation.

Risk Management Feature:
Personally I would not throw a lot of energy into this one since I don't think it offers much benefit over doing the same thing manually. The merchant has to do the bookkeeping entry anyway, so they could just as easily attach different wallets to the ledger themselves if risk management is a concern.

 

[syncmaster913n]

Hi Kanati, thanks for the reply!

I don't do Telegram so I will offer my 2 cents worth of advice here -

SOS transfer:
Interesting idea! If you decide to do it I would recommend that this feature be optional, and disabled by default. Why? Two main reasons - 1. it increases administration complexity in an already steep learning curve for average users; 2. by increasing the complexity of the code you are increasing the attack surface for hackers.

Yes, this would definitely be an optional feature (like all other features suggested in the post above). Good point about complexity, too.

Embeded Escrow:
This one is tricky because it does not make provision for possible collusion between the escrow provider and one or the other part. I think the best solution would be a 100% automated, but that would require some foolproof method to assure that ownership was actually transferred for the funds to be released (maybe something like online integration with shipping company tracking numbers or online title registration for property?). I think this would be really difficult to do since some degree of centralization (bonded escrow, reputation, whatever...) would be required, and it certainly would not work in every situation.

Collusion is always possible with Escrow I guess, and I'm not sure there is much to be done about it, other than maybe have two Escrow parties involved, but that still doesn't guarantee anything - although it does become possible and much easier to execute with the Escrow Contract than it would be otherwise, it seems. The main reasoning behind this feature is to address the specific, rare but highly damaging, cases, where the escrow provider runs away with the money when a large transaction is involved. Plus, it might give beginners new to using escrow more confidence, knowing that there's a limit to what the escrow provider can do. And I agree that integration with shipping companies would be very difficult at this point, particularly since there's nothing to stop a merchant from sending an empty package and claiming it contained the goods. So just to be clear: this solution is not to solve all possible problems with Escrow - just the specific problem of escrow providers running away with the money.

Risk Management Feature:
Personally I would not throw a lot of energy into this one since I don't think it offers much benefit over doing the same thing manually. The merchant has to do the bookkeeping entry anyway, so they could just as easily attach different wallets to the ledger themselves if risk management is a concern.

Very good point. It does seem like this feature might be the least useful of all. Thanks man!

[Madinvestor]

I personnally like this idea a lot !

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


And I am waiting to know how the devs are feeling about it..

And come join us on Telegram, we are now 103 members and growing.

[syncmaster913n]

Yes, it seems that the emergency withdrawal option is the one with the most support from some community members in Telegram. Hopefully we'll have a dev's comment tomorrow on this

[bitcoingue]

Thank you for listing the proposals, 3 of many to come...

Emergency withdrawal seems a really interesting feature. A fake wallet password opens the fake wallet: everything looks like the real wallet, you can even make a withdrawal but of course, no koins are really sent using the fake wallet (and the emergency withdrawal runs in the background)

[sumoshi]

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.

Here are some arguments just cross to my mind, pls debate:

1. Emergency Withdrawal: I'm not sure what context for someone to use the "fake" password? In a raid? And in this case when it become a standard feature, true password and second wallet will be revealed one way or another, right?

It also cannot prevent keylogger if you use the true password every time to access your wallet. However, I think a "view only" password can be a good feature that you can enter to view balance, txs and keep master password safe, how do you think?

2. Escrow Contract: If I got it correctly, it should be a kind of smartcontract (any third-party involved is out of our scope). I don't think we can tackle to such topic anytime soon.

3. Risk Management Feature: First, pls note that sending coins to other wallets means merchants have to pay fees. Second, I'm not sure if merchants really wants the feature without actual use cases and proper surveys.