Jump to content

pftq

Member
  • Content Count

    314
  • Joined

  • Days Won

    2

Everything posted by pftq

  1. There's some nice arbitrage opportunities going on right now between Bitstamp / the rest of the market and Bitstamp's IOU on the Ripple Ledger. Just a few minutes ago there were asks of a hundred thousand in size for XRP selling at $0.44 when XRP on Bitstamp itself is already almost $0.46. You can view the orderbook on Ripple Ledger here: https://www.theworldexchange.net/ I mentioned Bitstamp and its IOUs for arbitrage a while back, but it hasn't really been a thing until recently again with the big price moves coming back.
  2. Added an alert for when the MAs cross on every intraday timeframe at the same time. It's something that seems to work only in crypto. Just got the first alert for XRP at $0.43
  3. Can Gatehub provide a list of all Ripple addresses they had secret keys stored for? That way we can compare against the list and avoid using any Ripple addresses that may be on it. Some users might have forgotten they imported an address to Gatehub, or they might have thought it was wiped from Gatehub using Gatehub's delete function, which may or may not have worked.
  4. You do realize that in 2-factor hinges on a secret key on that second device not being stolen or discovered? It is not that different than just having two secret keys or passwords. The authenticator just makes it so you don't ever send that second key around at risk of being stolen. But in a situation like the recent Gatehub hack, if your secret keys are stored anyway on someone else's server, you're no better off having 2-factor (because the secret key underpinning that second factor is also stored and stealable just like the first). If you were careful enough not to let the secret keys be exposed to a third party, then it is the same as just as what we already have.
  5. What feature are you referring to? As far as I recall, this was how account setup always was (except now we confirmed the "no way for them to recover" is not true).
  6. I tried to do this with https://www.theworldexchange.net - if someone wants to fork the project on Github and do variations of it, it's free. For example, the more advanced features are exposed under Advanced Settings in the upper right and includes this documentation:
  7. Just got first bottom signals since BTC fell back below $8K - for those waiting out the pullback for an entry. So far flagged on EOS, ZEC, and LTC but I usually look at is a macro indicator for crypto overall if I get at least a handful.
  8. Took a while to read through this whole thread, but agree with some older users here this was a ticking time bomb. I had my concerns here in the past as well, basically that you should never trust having your private keys stored on any service whether encrypted or not: Personally I would create entirely new wallets to use and store any remaining XRP. I know the argument that rekeying is just as secure, but IMO it's too easy for less sophisticated users to accidentally mess up the rekeying process and lose your funds again. I would rather just create a new wallet even if it cost ~$10 to fund. There are quite a few tools for doing this that don't try to store your keys like Gatehub does - Bithomp, Toast Wallet, my own (https://www.theworldexchange.net/). It's unfortunately hard to find consolidated information on stuff like this for XRP. If you just search "XRP Wallet" online, one of the first things listed is Gatehub, which isn't the same thing. If you search Ethereum Wallet, it rightly points to MEW and other local-only tools. IMO it really has to come from Ripple to list vetted and recommended wallets. Not only for trust but Google's SEO probably is affected a lot by what their site links to.
  9. In light of Gatehub's recent hack, I'm considering whether to rename The World Exchange so that it's more clear that this really has no back-end and doesn't store your keys, not even encrypted. I already replaced the tagline and footer to make it clear that this "exchange" operates directly on Ripple's blockchain with no intermediary server. I actually have the domain https://www.rippleclient.com/ but that might lead to confusion with the older min ripple client. If there are other ideas, let me know. I think when I built this, it was during a time that was still vague for how best to describe blockchain to the public, but things have changed obviously. I've also suggested to a few people at Ripple Labs to perhaps change the RippleTrade page to link to wallet tools like this and Bithomp instead of Gatehub, but had no luck there. IMO tools like this are much closer in spirit to the original RippleTrade which also didn't store or process any of your information (they processed your activities directly to the Ripple network and didn't store your keys, encrypted or not, anywhere). It bothers me that there's no real clarity to users what tools are actually "wallets" and what are actually centralized servers storing your keys. If you search "XRP Wallet" on Google, one of the first things that come up is Gatehub, instead of something like Bithomp, Toast Wallet, or the tool here.
  10. Added alerts on the Volume/MarketCap list to @TechTraderBTC so you don't have to keep checking it manually.
  11. Added all-time high column and filtered screener tabs to only liquid exchanges.
  12. This aged pretty well. Was a week or two early but basically Nov-Dec timing was the bottom of the market. This and ETH at $100 in Dec were the only times all last year the system gave off any daily signals: https://twitter.com/search?q=%40TechTraderBTC daily&src=typd
  13. XRP Ledger has built-in whitelisting, but the issuer has to do that. See the example here: https://www.theworldexchange.net/?symbol1=TTT.rBcA1MkS2jtywAAi9bWfGsUk9R6RWQAyKr&symbol2=XRP Does Etherdelta charge fees? I was under the assumption it was only gas to execute the smart contract (same as XRP burned per transaction).
  14. Etherdelta was fined by the SEC today per the article here: https://www.coindesk.com/sec-charges-etherdelta-founder-with-running-unregistered-securities-exchange/ There's a few differences between what they did and what you'd do on Ripple: 1. Etherdelta had to create their on smart contract, meaning they wrote exchange code that then went on the facilitate the trading. On Ripple, the ledger itself is already an exchange so you are doing API calls to blockchain only. The closest analogy I can think of is if you had a trading tool like MetaTrader allowing you to connect to brokers. The trading tool isn't itself conducting trades; it just connects you to the exchanges that are. However, in Etherdelta's case, they actually also wrote the smart contract code that Etherdelta's website was sending trades to. 2. There aren't any compliance controls for security tokens built into Ethereum itself, meaning it is up to the user to build this functionality (which Etherdelta didn't). On Ripple's side, whitelisting and other KYC control functionality is native to the ledger itself. I personally think this is more onus on the token issuer to make sure they code their contract correctly (so the token would fail to trade on an open exchange like Etherdelta to begin with), but the SEC doesn't seem to care here. Personally trying to figure out on my end how much the SEC would care about technical details here. If they went with the notion that anyone creating a tool permitting trading on blockchain needs an exchange license, then potentially anyone creating a Ripple client/wallet tool would be fined because Ripple itself is an exchange, meaning any Ripple wallet can conduct trades even if the client tool itself doesn't actually have exchange code. It would also not make sense when taken out of the blockchain context because any 3rd party mobile app or trading tool would fall in the same situation, but those are more easily seen as "tools" only since you can point to Interactive Brokers or TDAmeritrade as the actual exchange where the trades happen (harder to do here with Ripple since RL itself doesn't even have a UI for Ripple ledger). In the context of the Coindesk article, the question is basically how much the fact Etherdelta wrote the exchange code in the smart contract matters vs them just providing a website that displayed exchange functionalities. It also makes me wonder how things like Kyber and 0x are going to be treated, since they *have* to write the exchange code for their smart contracts.
  15. My point was to the original question of verifying a secret key is valid, which you could do by just trying to login on an offline computer. But actually TWE does output the signed transaction in the console log, so you technically could run a local copy on an offline computer and copy-paste that. The relevant part of the JS code is below in the submitTransaction function ( the console.log call). To do what you're saying though would require essentially multiple computers (one to sign, one to send), which is not what I see most people would do or find practical. You might start worrying that the way you copy-paste (USB?) might also bring malware to the offline computer. For me, it's more practical to just have two wallets, one that I never send out of or use the private key for (except to verify offline on a local copy of TWE or other wallet) (aka long-term/cold-wallet) and another that I use more often (aka operational/hot-wallet) but keep less funds in. var result = api.sign(prepared.txJSON, key); transaction = result.signedTransaction; console.log(transaction);
  16. That is what the TWE does already (signs offline and submits online); it's handled by Ripple-lib. Really, pretty much any wallet that uses Ripple-lib would do that (sign offline, only submit signed tx online). The problem with suggesting writing your own code is that if you had the technical skill to write or call Ripple-lib, you could also just verify yourself that the wallets out there are already doing the same thing. Like you said though, it's hard for most users to verify what's using Ripple-lib or not and then even then it seems most don't realize the signing happens offline.
  17. Not true. TWE at the time did not have this bug because fixing it only required re-compiling the ripple-lib source with latest libraries/dependencies (specifically the bignumbers.js library), which is what was done to make sure TWE didn't have the issue. The other wallets with the Safari bug were also actually running versions of Ripple Labs years behind the current version at the time. Ripple Labs' fix to the issue in later versions was essentially that (recompiling with updated libraries, which they really should have done immediately but did not for some time). See: The code for TWE already includes the Javascript code for verifying secret key with address, which as others stated can be used offline or on a disconnected computer to ensure nothing is being transmitted out. You would end up with the same thing but w/o the other Ripple-lib functionality (trading, trustlines, etc) on the page if you wanted to create just a secret key validator. Specifically, it is these lines below in the js file. There are 4 lines in ripple-lib that have to also be added to expose the "deriveKeypair" and "deriveAddress" functions from Ripple Labs, which I also labeled with "// pftq" in the ripple-lib js file; I've been asking them to do this in the official release for some time (since it's just 4 lines to be able to add verification functionality). If you guys can ask them as well, maybe they'll eventually include it so adding the lines yourself are not necessary. Most of the code below, you'll see, is just UI updates, and all the work is being done by deriveKeypair + deriveAddress which is from Ripple Labs (look it up in the ripple-lib js file). var pair = api.deriveKeypair($.trim($("#keyInput").val())); if(pair) { // Address is derived from the public key which is derived from the secret key // Make sure it matches the address the user input var publicKey = pair.publicKey; //console.log("Key pair for secret given: "+pair.publicKey+" / "+pair.privateKey); // If account field is blank, we can just generate it from the secret key (technically only the secret is needed) if($("#accountInput").val()=="") $("#accountInput").val(api.deriveAddress(publicKey)); // Else check against what they put if(api.deriveAddress(publicKey)==$.trim($("#accountInput").val())) { validKey = true; saveLogin2(validKey, error); } else { // if we get here, it means the secret is valid but secret key doesn't match the account account console.log("Secret key failed."); // Check if it's the RegularKey instead by first looking up the RegularKey setting of the account api.getSettings($.trim($("#accountInput").val())).then(function(receivedSettings) { if("regularKey" in receivedSettings) { console.log("Checking against additional regularKey: "+receivedSettings["regularKey"]); // Redo the check against the RegularKey if(api.deriveAddress(publicKey)==receivedSettings["regularKey"]) { validKey = true; console.log("RegularKey matched."); } } // No regular key found else { console.log("No additional regularKey to check against: "); console.log(receivedSettings); } }, function(err) { console.log("Error getting account settings: "+err); }).then(function() { // If other misc errors come up, such as API errors saveLogin2(validKey, error); }); } } The trust issue is annoying, but unless there's a consensus on what you'd need to see, I don't see a way to solve it. I could hire the same code auditor as Ripple Labs, but it would make little difference if no one bothers to look at the audit in the first place (few seem to look at the source code, for one) or if no one recognizes the name of the code auditor (can anyone here actually name the auditor for Ripple?). On top of that, you could just say I forged the audit.
  18. Binance is now jumping onboard. Their contest literally ticks off every feature of Ripple including issuance, orderbooks, freezing, etc. https://medium.com/binanceexchange/binance-dexathon-845dc0cbfffe All those are already available and fully functional here: https://www.theworldexchange.net/ (Ripple front-end/UI)
  19. You can freeze tokens on Ripple on a per-user basis. So once someone has redeemed, you can just freeze the amount they hold (if they're not willing to send it back to you).
  20. You basically just described an ICO. Yep - XRPLedger is designed for that
  21. I can add it if there is demand for it, but my thinking was it was something like a EULA / terms / agreement that the user just reads once and shuts off. If need be, they can just refresh to see it again.
×
×
  • Create New...