pftq

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

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.

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.

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)

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

You basically just described an ICO. Yep - XRPLedger is designed for that

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.

I've extrapolated the method I used to create a Chat Box on Ripple and reimplement Ripple Names on the Ledger into a way for token issuers to attach a profile / bulletin to display to anyone trading their token. This way, users know the info is legitimately coming from the issuer and not a scam. It's also useful if your legal framework requires every token holder to have read certain disclaimers, etc. Here's a demo with the TTT token on World Exchange: https://www.theworldexchange.net/?symbol1=TTT.rBcA1MkS2jtywAAi9bWfGsUk9R6RWQAyKr&symbol2=XRP The lower-left shows an info box that describes what the token is, who is allowed to trade it, etc. As an added bonus, I added the ability to create a popup with your profile contents by using the [popup] tag. This way you know for sure all token holders have read your information before proceeding to the token. This is especially useful for EULAs, disclaimers, etc. Demo: https://www.theworldexchange.net/?symbol1=XYZ.raiLN9gC6AEK2B8odRskkwQMfwMqEukgyB&symbol2=XRP.

I'm not looking at payments. It's under exchanges that the transactions are missing. In general if you export from my site vs go down the exchange list on bithomp, there seems to be some trades missing.

Any ideas what the encoding is on this transaction? It's the only one that isn't being decoded properly. https://xrpcharts.ripple.com/#/transactions/799F77BE631D9F31FA68C5246CC0D969E80513822E4877C4BADAC55EB607A101

Not yet - haven't had time to look into it or what the technical side entails.

1. Not wallet secret key - just the public address. So you always need both the token name and public address of the issuer. 2. Yes, anyone can view anyone else's wallet contents by just having the public address. There's no privacy. You could even just use Bitstamp's address to login and view their contents (read-only of course). 3. You can set a display name (link at top the chat window). However, they still need your public key first to look you up (only after they do so, then the name changes to the display name). Note the display name is a protocol I created, so other Ripple wallets/sites have to add the same code from WorldX to be able to see the display names. 4. Yes and yes. 5. Actually not sure, but would assume no. At the very least, you couldn't login to send anything until the wallet has minimum XRP balance.

If anyone followed the MOBI ICO on Stellar, they're doing basically what the opportunity to do on Ripple was - an ICO/token immediately tradable on the decentralized exchange itself. https://stellarterm.com/#exchange/MOBI-mobius.network/XLM-native

Serious question - Is RL considering lowering the min balance? I'm working on a project that might use Ripple for managing accounts / payments between its users, but it's a bit steep if the min funding per account is $40. @JoelKatz @nikb @miguel

Sure. https://twitter.com/TechTraderAI/status/953757345909170176 https://twitter.com/TechTraderAI/status/945652195759755265 https://twitter.com/AiSideQuests/status/860061860317372416 https://www.pftq.com/stocks/images/2015-08-26_16-54,_Daily_SPY_Chart.gif