Jump to content

wm1215

Member
  • Content Count

    27
  • Joined

  • Last visited

  1. @mDuo13mentioned a downside to the aggregation approach in regards to how "Whoever owns that address has full control of the XRP until they escrow it.” 1. Would uploading to Codius the code that handles the pooling of funds and creation of escrow under the aggregation approach mitigate the concern around the ownership of the account that is pooling and escrowing the funds? If anyone here could chime in with their thoughts, it would be highly appreciated. Thank you.
  2. On second thought, maybe you can make the aggregation approach a more scalable one by using destination tags. Instead of creating a new address (which would require a 20 XRP reserve) for each transaction, one could just create a new destination tag for each transaction. So for example, let's say you have 1,000 groups of 5 individuals, with each group assigned a destination tag (so 1,000 different destination tags). When each individual goes to send a payment, they would all send it to the same one "aggregator address", but specifying the destination tag assigned to their respective group. Then you could aggregate and escrow the funds based on destination tags. With the use of destination tags, I think the "aggregator" approach could be used in situations in which you wanted to use one address to create an escrow funded by multiple addresses --many times, simultaneously. Anyways, just wanted to share my additional thoughts
  3. Thank you for the feedback @Flintstone I will check out Bithomp's escrow tool. Yes, very helpful @mDuo13. Thank you. Taking into consideration the 20 XRP account reserve, the "aggregation" approach now doesn't seem so scalable, especially for low value transactions. If you had a service that had to do this multiple times, simultaneously, you would have to create a new address and reserve away 20 XRP for each transaction. The "multiple escrow" approach seems to be more scalable at least from a cost perspective. However, more complex (at least for now) given that each sender would have to be capable of creating an escrow transaction.
  4. I am exploring and trying to better understand the escrow functionality on the XRP Ledger. I was wondering whether you are able to fund an escrow directly from multiple addresses? Per my review of the RippleAPI docs, this is not supported it seems. If you are not able to do so, what are some possible approaches? Would the approach would be to: have the multiple addresses send XRP to one address ("aggregator address") that would be used to aggregate the funds. send the aggregated funds from the aggregator address to the address where you would escrow the funds. Any insights/feedback would be appreciated. Thank you.
  5. It was just an initial plug. It turns out that that was the problem. https://github.com/ripple/ripple-lib/issues/933 Thank you for taking the time to help troubleshoot.
  6. Thank you for the replies @SGoldstein and @Sukrim I will post my question on Github. By the way, is there a chat room for the XRP Ledger? Like the community rooms for Codius or Interledger on Gitter?
  7. I am writing a script for an escrowCreation transaction using the RippleAPI and XRP Test Net Faucet. When I go to run the script, I get the following error. [ValidationError("CancelAfter" must be after "FinishAfter" for EscrowCreate)] (node:4754) [DEP0079] DeprecationWarning: Custom inspection function on Objects via .inspect() is deprecated I am puzzled by this error message given that I am using the RippleAPI, not the rippled API. The RippleAPI escrowCreation transaction type takes the fields: amount, destination, allowCancelAfter, allowExecuteAfter, condition, destination tag, memos, sourceTag. The escrowCreation object is pasted below. const escrowCreation = { "destination": "rpZc4mVfWUif9CRoHRKKcmhu1nx2xktxBo", "amount": "100", "allowExecuteAfter": "2018-08-20T16:30:00.000Z", "allowCancelAfter": "2018-08-20T16:30:00.000Z", }; I've written scripts for the get account info and send payment transactions using the RippleAPI boilerplate without issue. However, I've hit a roadblock in writing the script for the escrowCreation transaction because of this validation error which I cannot fix. If you've experienced this error or know how to fix it, I would really appreciate your guidance.
  8. wm1215

    7 days left of Q4

    Let's not get carried a way here. I am hopeful about additional announcements before year end, but let's keep in mind that they made a forecast about the timing of announcements which is subject to change (undoubtedly for good reason). Besides, they have already made 11 announcements via their website in Q4. XRP is at $1.11. Thanks.
  9. wm1215

    Updated Map of Ripple's Partners

    Found this cross-border remittance flows diagram by McKinsey. It looks awfully familiar...
  10. wm1215

    Updated Map of Ripple's Partners

    I believe it would be interesting to see these corridors. From what I understand, Ripple intends to target inefficient corridors, which are believed to have the greatest potential (at least initially) for XRP use. That said, in terms of the magnitude of the impact on XRP demand/price, it should be largest for announcements related to: 1. Banks joining RippleNet which establish new inefficient corridors. 2. FI's joining RippleNet which send large volume payments through these inefficient corridors.
  11. wm1215

    Why are you here?

    When I said, "business", I was referring to Ripple!
  12. wm1215

    Why are you here?

    I'm here because I was at the right place at the right time to come across a means (i.e., XRP) to participate in a business at the forefront of an industry in its super normal growth phase. Also, I dislike paying high fees and waiting a week for an overseas wire transfer to settle!
  13. wm1215

    Updated Map of Ripple's Partners

    This is great Sebastian. Thank you for taking the time to put this together! By any chance, do you have one which shows the currency corridors (i.e., as shown below)? It would be great to get a sense for which corridors have already been established.
×