Topic: [ANN] [SUMO] SUMOKOIN - 🔏 Digital Cash For Highly-Confidential Transactions 🔏 - page 170. (Read 202442 times)

Join Telegram, Bill Aue will help you as soon as he sees your message. Are you on Mac ? Maybe I could help, I never had a issue yet

So, I have an issue running the GUI wallet. It starts up, starts to sync and then the transparent window stating it may take a long time to sync NEVER closes even though the screens behind that one shows the sync is complete.

Any help would be appreciated.

Sure it is. But since the diff is high already, I would mine and buy some on cryptopia. That is what I did/do.

Anyone mining Sumokoin? Is it profitable?

Every opinion would be gladly appreciated so feel free to join telegram right here https://t.me/joinchat/F8RH2kPmFCnA-igHBKSCAA

For anyone interested, designers are currently working on a more professional version of the SUMO logo in the Telegram. If you'd like to share your comments and ideas on what the logo should look like, or if you'd like to vote on the proposed designs, feel free to join.

Great, thanks! So we have two potential features:

1) Two-factor authentication for the wallet
2) A "view only" password that allows you to view your balance without being able to make any transactions (as suggested by Sumoshi).

Sounds good.

Yes, the idea was never for these suggested features to supersede nor be prioritized over the more fundamental features that you referred to in your post. The goal is to get some brainstorming going for additional features that can be added once the current dev roadmap goals are achieved.


I disagree, however, that smart features need to wait until a relative degree of mass adoption is achieved. I think cryptocurrencies are at a point where mass adoption will be easier to achieve if we can first convince the merchants to accept them, rather than try to convince users to buy with them. The latter of course would be preferrable, but it would take a long, long time. Mobile wallets and the other features you referred to, and which the dev's are working on right now, are extremely important for making use easier. But even if everyone wanted to pay using SUMO, it won't matter if the merchants don't trust that their coins will be safe in their wallet; they just won't accept any payments that way or, in a best case scenarion, they will accept payments but with a substantial additional fee applied on top of what they would regularly charge when using other, safer payment methods.

Ease-of-use features and safety features must go hand in hand in my opinion. We can convince thousands of people to use SUMO for payment, but it won't matter if no merchants feel confident enough to accept it. Convince 10 merchants to use sumo, on the other hand, and you automatically raise awareness of the coin and expose it to thousands or tens of thousands of potential buyers - at which point ease-of-use features would become critical if the users are to use the coin, so they must be ready.

1. I don't think any fake password is workable in such cases and we don't intend to design a wallet for that specifically.

2. 2FA, in the contrast, is completely feasible and we have plan to incorporate it to the GUI wallet in some future release. We'll study other wallets for proper implementation.

Thanks for all suggestions @syncmaster913n

Hi Sumoshi, thanks for replying.


This is generally called "plausible deniability". It's something found in cryptographic software such as the old TrueCrypt and I think also VeraCrypt, where you can create a hidden partition on your drive and have a special way for accessing it, while also having a "fake" partition to which you give the password in case of interrogation. It's a very popular concept among people who value their privacy and are afraid of government or other type of prosecution. The concept of plausible deniability is as follows:

1) You are asked by government representatives to divulge your password.
2) If you say "no I won't", you are prosecuted for not co-operating.
3) But if you give them a "fake" password, and the money is automatically transferred out of the wallet when the fake password is used (perhaps leaving behind a few SUMO to make it look more real, but transferring out like 99.9% of the balance - up to debate), you have officially complied with the law.
4) Since the "Fake password" feature would be completely optional, no one can prove that you had it enabled. You have officially complied with the law (ie. no one can say that you did not co-operate), but your funds are safe. This is "plausible deniability": you have complied with the law (because no one will believe you if you just say "I forgot the password"), but at the same time you have not compromised your SUMO.



You are right, the fake password would not help against keyloggers; the fake password can only help in the scenario described above. What can potentially help against keyloggers (I'm not a developer, so correct me if any of my logic here is incorrect) is the other part I mentioned, which is the "puzzle" that needs solving. Essentially it would be like two-factor authentication for your wallet, with emergency withdrawal built-in. So basically:

1) You can (optionally, or by default - up for debate) enable two-factor authentication for your wallet.
2) With 2FA enabled, you would not only need to enter your regular pass phrase to access the wallet, but also an additional 3 or 4 digit PIN that you have to enter before logging in. The PIN does not give you access to the wallet and it has no way of decrypting the wallet. The PIN is only an extra check.
3) You enter the PIN with your mouse, and the PIN numbers are shuffled, so in case a keylogger registers on-screen click locations, it won't know which PIN digits you clicked (I'm sure this can be by-passed, but the idea is to make it much harder, not impossible).
4) After entering the PIN with your mouse, you enter your regular wallet pass-phrase, which decrypts your wallet. At this point, a check is performed to see if the PIN entered before is correct.
5) If the PIN is correct, you have regular access to your wallet. If the PIN was incorrect, emergency withdrawal to a secondary wallet is initiated automatically.

I hope this makes it clear. Again, I don't know if this can be done on the blockchain, so please let me know.

Also, the idea for a "view only" password is very cool, too.



I understand, thanks. This feature can be disregarded then.



Good point about the fees. This feature is probably the least useful, so I think it can be discarded as well. One point I'd like to make though is that surveys are not always a good idea (sometimes they are horrible). People often don't have a clue what they want to use. If you had surveyed people in 2008 whether they wanted something like Bitcoin to exist and whether they would buy it, probably every single one would say "no" except for a few geeks. Surveys are good in some situations when for example you want to change something that already exists and which people are using. But when introducing completely new features/technology, I think surveys can often be counter-productive. Plus, people sometimes naturally find new uses for features, other than the original use the feature was intended for, making surveys even more tricky. This is just a general observation, not relating to the Risk Management Feature (I agree this feature probably has no real use cases.)

1. Lite/mobile wallets are our priority at next stage.

2. GUI cold wallet signed/transfer will be implemented very soon.

Thanks for input.


We may have an option to create and run view-only wallet along with true wallet though it may make thing a bit complicated for management. We'll have to discuss this.

These proposed "smart" implementations are nice and cool albeit geek stuff. However, it's pointless to have them if the primary use case (i.e. functioning as cash) is not allowed to gain a foothold first and foremost. Transacting with (fiat) cash is easily accomplished P2P (person-to-person) and "on the go" by simply handing over physical notes to someone in exchange for goods/services or in conducting other forms of trading. Unfortunately, we can't do the same with cryptos. The closest thing would be to utilize a device that most (if not all) people already carry with them all the time -- mobile phones. In fact, we already transact with fiat currencies through these devices nowadays.

I hope the devs will not lose focus and deploy first and foremost the tools/apps that matter at this stage which are:

1. a simple, reliable, secure and private mobile wallet that connects to a trusted and secure node by default (for user friendliness out of the box) with an option to connect to a private node running at home or other locations that the user has control over (for advanced/paranoid users)

2. GUI cold wallet/offline signing implementation so that users don't start losing their stash while in the process of accumulating tokens.

Smart features could then follow thereafter...when Sumo will have achieved a relative degree of mass adoption. Otherwise, it will just be another speculative blockchain-based token like everything else before it (hopefully the devs have learned this lesson). Believe it or not, BTC's value/market cap is still largely fueled by speculation after eight years running and not by its touted primary use case which is as cash or cash-like. Which businesses/sevices/goods can you pay with BTC on a day to day basis to date?

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.

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)

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

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.

Hi Kanati, thanks for the reply!


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



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.



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

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.

 

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.

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