tmacshaq
It was pointless to discuss this issue unless there was anything realistic attack.

Putting extra extra layers of extra protection only makes access difficult, but since GalacticTrade controls these layers, they are never enough. As I said, the most important thing to do here is that the user chooses a sufficiently secure password. This applies to all systems including hardware wallets.

tmacshaq Your app literally just hands it to whoever asks for it.

That being so comes from trust in the security scheme anyway. This is a challenge, if you think the current security scheme is insecure, you can join this challenge. Simple, isn't it?

      I already mentioned this. The difference with other systems is they have a whole layer of security and attacker has to breach first. Like someone needs to break into my house and take my hardware wallet first before they can enter the password!

        tmacshaq Yes, that's exactly the difference. Instead of relying on extra extra extra layered security systems of other systems, in GalacticTrade you only provide a strong password for your own security without trusting GalacticTrade. Only in this way will you have full control.

            galactictrade I like your spin on the "no trust" part but its completely irrelevant. Your basically punting a tricky security problem to your own users and allowing them to shoot themselves in the foot. The thing in security you should not do. Users using your GalacticTrade will be mislead into thinking it works like any other software except its missing a whole layer of security. I cannot think of one system that is designed this way and I don't think its because everyone else is stupid.

                tmacshaq

                I answer for the last time, thinking that you are not malicious in these comments, only the lack of information.

                tmacshaq I cannot think of one system that is designed this way and I don't think its because everyone else is stupid.

                GalacticTrade uses the same authentication scheme I linked. I did not invent anything new, I used the safest way already.
                https://www.blockchain.com/learning-portal/how-it-works

                As I said, if you have any claim that there are any security issues, you can show it with evidence and take your imagination one step further in your comments.

                See you in the comments on another topic!

                      galactictrade I just randomly logged in to galactic.trade account I didn't create. The password was "test".

                      You left out some key details in your comparison to blockchain.com. blockchain.com doesn't let their users create an account with "test" as password. Also when you log back in Blockchain requires you to enter the 41 character wallet ID not your username. This is basically another mandatory secure password. Its very easy for people to attack your users accounts if they can guess the username because you use to lookup their data.

                      FWIW I think it's very inconsiderate to Stellar users to publish something so half baked and insecure. Your way too cavalier about security. Its really scary since you called your thing is "completely safe". If you think your users have to actually lose money to an attack before you admit a security hole you should absolutely not be building software that handle other peoples money

                        As far as I can remember, the original Stellar account viewer had this exact same issue, right out of the gate.
                        The encrypted blobs where available for anyone who asked for them, so as soon as a new account was registered on the ledger, people did a reverse federation lookup to get the username, used the username to get the blob, and slurped away all STRs from accounts with weak passwords. This took seconds.

                          dzham

                          The way I think they dealt with it was to do the 2FA check before giving out the blob.

                            galactictrade Oh I see your the guy who did StellarPay. You won 450,000 XLM in SCF #2 and we never hear about StellarPay again. Now you come for second serving with different account. I see what Freitag means now about cash grab. I also see your perspective now. Win the SCF then sweep it under rug so people forget it about it. Hey if theres a security hole but no one will use it, is it still bad? 😆

                              2FA feature has been activated. You can start using this feature by going to the Account> 2FA page.

                              Also, the minimum password length requested from the user during registration was set to 10.

                              The next update is the "Loan" system, which works completely with Stellar smart contracts, which makes GalacticTrade special. I plan to release the "Loan" update within 24-48 hours unless something goes wrong.

                              Stay tuned!

                              Until 2FA is required to use your thing or you do BlockChain's wallet ID the security issue above still applies. If you read dzham's response again 2FA has to be done before giving out the blob.

                              Here's another hack where you compromise security for the sake of "convenience". Your app stores the users private key in cleartext as the "data" field in Local Storage. Again no other apps do this- not Blockchain not Stellarport. Again not something I'd expect from an app that's "completely secure"

                                tmacshaq If you read dzham's response again 2FA has to be done before giving out the blob.

                                You write here the claims you have produced using your imagination from the very beginning. Encrypted data (blob) is never presented to the user without entering the 2FA code. It is only a waste of time for you to come here and make negative comments even if you have not tested this.

                                Here is a small clip of how it works
                                https://cl.ly/ab34a42cb77b

                                tmacshaq Your app stores the users private key in cleartext as the "data" field in Local Storage.


                                This claim is unreal like the other. There is no private key data which is stored as a "cleartext".

                                tmacshaq Until 2FA is required to use your thing or you do BlockChain's wallet ID the security issue above still applies.

                                Forcing users to log in with a long id harms user experience. Minimum password length is 10 and it is pretty enough to keep them safe. I do not have a plan like login with long and complex ID instead of username. 2FA feature is here for those who want extra security.

                                      Hey guys, I know you are looking forward to P2P Loans system, the unique feature of GalacticTrade!

                                      P2P Loans system is almost ready and I'm working hard to get it live immediately. Before I go live, I want to make sure that all contracts are working smoothly and securely, and that the instructions are correct, so I have to test each step several times.

                                      I can't wait to release it and get feedback from you. No doubt that it will be released before the voting begins (who knows maybe tomorrow). Stay tuned!

                                      P2P loans system is online!

                                      Available lends:

                                      Apply to loan :

                                      https://galactic.trade/loans/available/lend

                                      How the contracts work in the borrowing process is explained in detail. However, since this is insufficient, I am preparing a visual model that users will understand how it works before the process starts.

                                      Here is briefly what they are:

                                      2 contracts ensure that the funds of the lender and borrower parties are secure before the match.

                                      onExpire contract is activated
                                      if your loan offer does not match and automatically sends
                                      the loan or colleteral, which is the amount you deposit or
                                      lock for the loan contract, back to your GalacticTrade
                                      account within X days.

                                      onIncomplete contract ensures
                                      that the escrow account, which has been specially activated
                                      for you and has enough funds to operate, will merge into
                                      GalacticTrade if you do not complete all the steps necessary
                                      to publish the loan offer. This contract is valid only if
                                      the onExpire contract is invalid.

                                      The 5 contracts manage the post-match payment to the borrower, the repayment from the borrower to the lender, the delay and cancellation status.

                                      onPayment contract is
                                      contract ensures that the loan amount is transferred
                                      to the borrower.

                                      onCancel contract
                                      becomes active as a result of discontinuance of
                                      transactions on both sides of the borrower and
                                      lender and closes the escrow account created for the
                                      transaction (Merge account)

                                      onRepay contract ensures
                                      that the debt paid is sent to the lender and the
                                      locked collateral is sent to the borrower back if
                                      the debt is paid. Also, after these transactions,
                                      the escrow account created for the loan is closed
                                      for use. (Account merge)

                                      onDelay contract becomes
                                      active if the borrower fails to pay the debt on time
                                      and sends the entire amount of collateral under the
                                      account of the lender. Also, after these
                                      transactions, the escrow account created for the
                                      loan is closed for use. (Account merge)

                                      onIncomplete contract becomes active if the escrow accounts do not trade on either side and wait for the expire period and abandon the transaction. The escrow account merges back to GalacticTrade.

                                      GalacticTrade prepares and delivers contracts for the two parties and sends it to the Stellar network when the time comes. Borrower and lender can run these contracts (preAuthTx) and complete the loan, even if the GalacticTrade platform disappears.

                                      If the bids to the opened loans are not completed on time, the bid will be canceled automatically and the loan will be open to everyone again. Similarly, if the request to create a loan offer is not completed within a certain period of time, the escrow account (s) created for the loan offer will be closed automatically.

                                      You can ask your questions about the loans system here or via GalacticTrade.

                                        galactictrade The approach is quite exciting. But it's a prototype, right? I wouldn't roll out such a system on the mainnet without thoroughly describing the process from a UX perspective. Currently, it looks more like a playground for developers with all those scary contracts.

                                        Also, I don't understand the collateral requirements and don't see a forced liquidation option – arguably the most complex part of the lending systems. For example, I deposit BTC tokens pegged on Stellar to the lending contract as collateral for an XLM loan. First of all, the system should automatically detect the exchange rate and set minimum collateral requirements. For example, Maker requires at least 150% of the loan value to be collateralized. And if tomorrow XLM suddenly jumps 10% against BTC (which is definitely possible as history shows), the system should automatically send the margin call notification to the borrower with a proposal to increase the collateral position. If the borrower fails to increase collateral or repay the loan, and the collateral percentage is lower than a certain threshold (say, 130%), the position should be automatically liquidated.

                                        Without such an emergency liquidation system, lenders are not protected at all and nobody will use such p2p loans for volatile pairs. Maybe it makes sense for USD/EUR or USD/NGNT pairs due to the low volatility of the underlying fiat markets, but the orderbooks on Stellar lack liquidity. So I doubt that lenders will risk their fiat-pegged tokens for less than, say, 10% rate even on short-term loans.

                                        That's a good starting point, but please don't roll out this on the mainnet until you make sure that both sides of the deal are protected. It may really hurt the ecosystem if people start using it and lose their money. There is a reason why there are no lending/margin projects on Stellar. We don't have such flexible smart contracts and on-chain oracles. I'd say that second-layer solutions are better suited for this purpose.

                                            OrbitLens
                                            Hey,

                                            OrbitLens The approach is quite exciting. But it's a prototype, right? I wouldn't roll out such a system on the mainnet without thoroughly describing the process from a UX perspective. Currently, it looks more like a playground for developers with all those scary contracts.

                                            Yes, this is the first concrete example of how P2P lending can be made possible with Stellar's Multisignature, Atomicity, Sequence and Time Bounds features. The reason I post it on the public network comes from numerous tests I have done to make sure the contracts are working smoothly. I am preparing the GalacticTrade testnet subdomain version for those who want to test the contracts deeper.

                                            OrbitLens Also, I don't understand the collateral requirements and don't see a forced liquidation option – arguably the most complex part of the lending systems. For example, I deposit BTC tokens pegged on Stellar to the lending contract as collateral for an XLM loan. First of all, the system should automatically detect the exchange rate and set minimum collateral requirements. For example, Maker requires at least 150% of the loan value to be collateralized. And if tomorrow XLM suddenly jumps 10% against BTC (which is definitely possible as history shows), the system should automatically send the margin call notification to the borrower with a proposal to increase the collateral position. If the borrower fails to increase collateral or repay the loan, and the collateral percentage is lower than a certain threshold (say, 130%), the position should be automatically liquidated.

                                            This is called dynamic "margin calls". This mechanism exists in many projects that use Ethereum smart contracts, but risk management is left entirely to the contract there, and if there is an error in the contract, people's funds may disappear and I have seen this many times. Therefore, the "margin calls" mechanism is left optional in some projects. This is something I am working on and trying to find a solution, but it is not a must. The risk-taking party can secure itself by adjusting the haircut, interest and maturity values according to the risks envisaged before starting the credit transaction. Trying to make dynamic "margin calls" with existing Stellar features will complicate this system and lead users to sign numerous contracts.

                                            OrbitLens Without such an emergency liquidation system, lenders are not protected at all and nobody will use such p2p loans for volatile pairs. Maybe it makes sense for USD/EUR or USD/NGNT pairs due to the low volatility of the underlying fiat markets, but the orderbooks on Stellar lack liquidity. So I doubt that lenders will risk their fiat-pegged tokens for less than, say, 10% rate even on short-term loans.

                                            If Lender thinks that the value of the asset he accepts is fluctuating, he can determine a loan period, haircut value and interest value and protect himself. Here, they determine the risks of the lender and the borrower themselves and accept this and start this process. I am working on different solutions to protect both sides, but my priority is that both parties always approve something on the system at the minimum level.

                                            OrbitLens That's a good starting point, but please don't roll out this on the mainnet until you make sure that both sides of the deal are protected. It may really hurt the ecosystem if people start using it and lose their money. There is a reason why there are no lending/margin projects on Stellar. We don't have such flexible smart contracts and on-chain oracles. I'd say that second-layer solutions are better suited for this purpose.

                                            Yes, as I said, this system is a working concrete example of P2P lending and borrowing possible on Stellar, and no doubt that it will continue to evolve and improve. Perhaps we will see new CAPs and side-chains that will steer this, and then much more dynamic contracts will be possible.

                                            The reason I posted it on Mainnet was to show that the contracts are more than theoretical. It's really easy to control it with the limits I set. For example, to be able to open a lending-buying offer for a maximum of $ 50. I am sure that this worry will disappear with the TESTNET version I will release.

                                            The only thing I think might be a problem here for a long time is "surge pricing". That's why I set the maximum credit period to 30 days in the current version. When the network enters the "surge pricing" mode and the preAuthTxs are sent to the network, if the predetermined transaction fee for the contracts is insufficient, it will receive the error "tx_insufficient_fee" until the network becomes normal, but this does not prevent the contracts from still being valid because it does not affect the sequence number of the escrow account.

                                                        galactictrade Would love to see a solution that proposes contracts with dynamic forced liquidation. I'd use it myself. Without this feature the lenders will be too cautious – require huge collateral for short-term contracts only.

                                                        BTW, are you going to introduce public API for this to allow p2p lending and matching for trading bots?

                                                            galactictrade The only thing I think might be a problem here for a long time is "surge pricing". That's why I set the maximum credit period to 30 days in the current version. When the network enters the "surge pricing" mode and the preAuthTxs are sent to the network, if the predetermined transaction fee for the contracts is insufficient, it will receive the error "tx_insufficient_fee" until the network becomes normal, but this does not prevent the contracts from still being valid because it does not affect the sequence number of the escrow account.

                                                            Just a small comment here..

                                                            Since protocol v11, the fee you specify isn't the one you will pay, but the maximum fee you are willing to pay. You can set it to something rather high, and in most cases you will pay a lot less.

                                                            And @OrbitLens might know more about when the fee bumping will arrive.

                                                                OrbitLens

                                                                OrbitLens Would love to see a solution that proposes contracts with dynamic forced liquidation. I'd use it myself. Without this feature the lenders will be too cautious – require huge collateral for short-term contracts only.

                                                                Yes, I will try to find a model for this that does not cause user experience problems.

                                                                OrbitLens BTW, are you going to introduce public API for this to allow p2p lending and matching for trading bots?

                                                                Yes, I can offer this as a public API. It will be sufficient to sign and send contracts (XDRs) by using the API with any Stellar library (eg js-stellar-base). Of course, I need to prepare a solid documentation for this. What kind of scenario do you have for trading bots?