pftq

fyi

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

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.

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.