Re: [ANN] [SUMO] SUMOKOIN - 🔏 Digital Cash For High-Confidential Transactions 🔏
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.
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.
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.
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.
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!