Jump to content


Platinum Member
  • Content Count

  • Joined

About Sukrim

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. What is "csc", do you have a link to their code? Stellar has forked the code and rewritten it from scratch years ago by now, so while the APIs and concepts are similar, I doubt that it would be easy to write a single integration that supports both XRPL and Stellar. The code would likely be very similar though. Great, write one!
  2. Their previous CTO definitely was more focused on Interledger... ;-) The current one seems to promote more advanced capabilities of XRPL more actively, so I doubt that they are trying to "fade away". They could certainly do more, but there's not much money in there for them, so their motivation is probably a bit lower than e.g. for lobbying with central banks.
  3. "They" in this context means "Ripple" - Bitstamp is not in control over the file you refer to, that's just what Ripple's developers chose to put in there. Nothing less, nothing more. Poor user experience when onboarding customers until Checks are enabled on MainNet. Regulatory issues/concerns. No more example implementation of a gateway. No real advertisement of that feature by Ripple at all. Very few features regarding issued currencies being developed by Ripple in the past few years (many exciting features were XRP exclusive). No more community standards around gateways (IRBA), no guidelines for clients (and many don't even implement issued currencies)...
  4. You would be wrong - but sure, you could say that.
  5. You could use Escrow with a SHA256 preimage condition and a time based lock. To cancel early, reveal the secret.
  6. They can use whatever name they want...
  7. ...or a white hat that wants to make sure everyone is safe and privately contact exchanges that are affected by this. Calling someone "scammer" outright is a bit premature.
  8. There are wallets out there that can send transactions like that and you could always just hand-craft, sign and send a transaction.
  9. Have you read through the developer documentation already? That might take a while until they respond with a link to the documentation. But surely a way to try out. I'd also recommend charging industry rates for consulting if you do private consulting, but that's of course up to you.
  10. This should be probably discussed on Github or at least in a separate thread here.
  11. There is no "the UNL". A UNL is secret and (potentially) unique to each validator, it's just that a lot of them use the same list or at least maintain a high overlap (this guarantees forward progress) by using a service by Ripple that regularly signs and publishes a list they recommend. There's no need or advantage to putting this service on the ledger itself. No. Neither thrust nor trust would be decreased by this, quite the opposite actually. Spam and there can be a huge number of possible UNLs - if you want to publish only "recommended lists" instead on-ledger, who gets to publish them?
  12. I would assume if I read "seed" somewhere that the private key is actually derived from this, not that it is the private key itself. This example up there is an encoded 128 bit value to be used to generate 256 bits of private key, so hopefully a good KDF is being used to derive the private key from this.
  13. I'm arguing that to do accounting, you'll of course need to track transactions affecting RippleState objects in an account at each end (probably in Asserts and Liabilities, depending on the current balance and the type of relationship). That doesn't mean that RippleState objects are accounts or should be called accounts themselves. If Alice sends a TrustSet transaction towards Bob, she does not create an (on-ledger) account, she establishes a relationship that can/should/will be tracked in an account (or not, if s/he doesn't want to do bookkeeping) on either end. Maybe this is clearer? Accounts are not the thing, they are the thing that tracks the thing. The "it's impossible" part - you can issue me USD of yours when holding USD of mine, it will just only shift our "settled" balance instead of being recorded separately (from RCL/XRPL's POV you are always FIRST handing me back my USD, THEN giving me yours and vice versa). That's just a limitation (optimization?) of the system, in accounting however that would be trivial to model - and even RCL/XRPL could "learn" this via an amendment that makes RippleState objects directed (at the cost of duplicating them and complicating transactions, you'd need to signify if you're sending mine back or sending yours every time). I think we're on the same page on this topic though.
  14. I agree to both of these, even though I would say that an entity is represented by a set of addresses/on-ledger accounts (Bitstamp also has a "hot wallet" for example) instead of a single one. No. EUR and BTC (where do these come from?) aside, I don't have an account with them on-ledger or off-ledger - I only (temporarily) hold something that represents USD that Bitstamp has stored in their bank account. There's an object on-ledger that tracks the current balance of this relationship and that Bitstamp and me can control (they can freeze it, I can offer/transfer it to someone else unless frozen). This object is not an account in itself, it is the thing that an account in my personal bookkeeping system and in Bitstamp's personal bookkeeping system can/should track. No. I don't have a user account at bitstamp.net any more, I closed that down long ago when they got hacked. This is not something that can be inferred from me sending a TrustSet transaction on-ledger or having a RippleState entry with Bitstamp. This is orthogonal to me owning 100 USD/Bitstamp. There are only(?) 4 (or 6) accounts with their own balance and transaction history with the case of me owning 100 USD/Bitstamp: Sukrim: Assets:XRPL:rvYAfWj...(Bitstamp): 100 USD Equity (Actually: whatever account these 100 USD actually came from when I acquired the 100 USD/Bitstamp): -100 USD Bitstamp: Assets:Bitstamp_Bank_Account (or whereever they - hopefully - store their reserves): 100 USD Liabilities:XRPL:r123456...(Sukrim): -100 USD ( If you also/only view the RippleState object on RCL/XRPL as "accounts": Assets:r123456...(Sukrim): 100 USD Liabilities:rvYAfWj...(Bitstamp): -100 USD ) Transactions that change the RippleState object between Bitstamp and me should trigger changes in (at least) account 1 in my system and account 2 in Bitstamp's - potentially there are even more changes (if I sell the USD to someone else for example). These are the actual "accounts", not the RippleState on-ledger object. If I had also an user account at Bitstamp and trust lines in EUR and BTC on RCL/XRPL with them, there would be more than 6 accounts in total in the "ledger account" sense. I'm not so certain about this, it is just not possible to have them displayed separately, so there can be unexpected issues with issuing issuances (). You can trust me for 1000 USD and I can trust you for 1000 USD at the same time, try it out on the Testnet. The only thing that's not possible then is that we send each other 100 USD and have that visible in the ledger - it would only show "0 USD", the current balance of our relationship, not the actual reality (each having 100 USD of the other). We could still send each other 1000 USD more than the other. Even if we hold a million USD each of the other, the system wouldn't care as long as the difference is below 1000 USD. That's because everything is considered fungible in Ripple (I wouldn't care that I hold your USD and vice versa, so you sending me USD that I'm willing to accept means that this changes the USD balance between us instead of you having to define that you're paying me back my USD or giving me your USD). By the way: I wrote a small proof of concept importer to get data from RCL/XRPL into beancount (http://furius.ca/beancount/), an easy to use accounting software that has a great web interface (https://beancount.github.io/fava/). Might be worth exploring further for your lectures.
  15. I agree that it could be an "accounting relationship", I just would not like to see someone call creating a trust line with X "creating an account with/for X" or refer to the balance of their trust lines with X as "money in my X account". I'm fine with "establishing an accounting relationship with X". A trust line and its state can be tracked using accounts, it is not an account itself. Just like the number of dollar bills and coins in your wallet in your pocket can be tracked as an (asset) account in the bookkeeping sense, but that doesn't make that thing an account itself. In the beginning you made a distinction between "Entities" and "Accounts" without mentioning trust lines, so I assumed that you want to call e.g. my 100 USD trust line to Bitstamp on my account "The Entity Sukrim has an Account with Bitstamp that contains 100 USD". I'd rather see a description like this: "The Entity Sukrim (with its on-ledger Account r123456...) has an accounting relationship with the Entity Bitstamp (with its on-ledger Account r987654...). The current balance between these Entities (visible in the RippleState object with the ID 123abc...) shows that Sukrim currently owns 100 USD that were issued by Bitstamp more than the amount of USD issued by Sukrim Bitstamp might hold. The exact numbers are private to these 2 entities in their nostro and vostro accounts respectively." https://developers.ripple.com/ripplestate.html
  • Create New...