T8493

Member
  • Content count

    1,384
  • Joined

  • Last visited

  • Days Won

    9

Reputation Activity

  1. T8493 liked a post in a topic by gregor in Which IOU would you like for GateHub Fifth to add on ripple?   
    Other IOU wishes write bellow
  2. T8493 liked a post in a topic by Born2beKing in Hello!   
    I'm new to xrpchat.  Want to say "hello" to everyone...
  3. T8493 liked a post in a topic by tulo in /so͞on/   
    That would be pretty stupid, because they are incentivizing the use of XRP outside RCL itself, loosing all the advantages of RCL (unless ILP comes in play). Bitstamp is not increasing the liquidity in that way, but it is reducing it.
  4. T8493 liked a post in a topic by Vinnie in NuDB: C++ key/value database PLEASE UPVOTE   
    And by the way, we considered all of these possibilities. The analysis showed that it would be worse. Respectfully, if you believe otherwise I think you should fork the code and do some experiments. NuDB is a very simple library, there's not much too it. If you have questions, just open a GitHub issue and I would be more than happy to answer them right away!
  5. T8493 liked a post in a topic by Vinnie in NuDB: C++ key/value database PLEASE UPVOTE   
    The problem is building the bloom filter on the initial launch, you'd have to iterate all the keys in the database, thats a huge startup cost! Resizing the bloom filter is similarly painful. And persisting it on disk (i.e. update it as you go) is very complicated to implement and impacts performance in other ways. The usefulness of the bloom filter is proportional to the ratio of memory divided by number of keys. As the number of keys approaches infinity, the usefulness of a bloom filter goes to zero.
  6. Cryptoblock liked a post in a topic by T8493 in Multi Cryptocurrency Wallets   
    https://jaxx.io/
  7. Cryptoblock liked a post in a topic by T8493 in Multi Cryptocurrency Wallets   
    I don't think so, at least not by independent third parties.
    Some parts of the source code are not public ("Jaxx's code is now available to view below. This is the full code (minus third party libraries) of our wallet's back end; it does not contain any UI elements.") and I think that there are no mechanisms which can be used to "prove" that the executables were compiled from this code.
     
  8. cmbartley liked a post in a topic by T8493 in RCL Trading APIs   
    For starters:
    RL will first have to make clear which libraries will be maintained in the future and which will be abandoned (like C# .NET library and plethora of other repositories).
    We have only one high-level library (RippleAPI) which is written in javascript. Currently, there is no officially supported way of using this library in other languages. Ripple-REST was abandoned, the library that sits on top of RippleAPI and enables external access to RippleAPI is unsupported.
    This new C++ library will probably implement just serialization in signing, but not other things (e. g. transaction submission).
    RL will also have to provide a way to download historical ledgers/transactions. Querying rippled for each old ledger and each old transaction can take months.
    RL will also have to provide more documentation about everything, including the repositories like ripple-historical-database.
     
     
     
     
     
     
     
     
     
  9. DanielW liked a post in a topic by T8493 in RCL Trading APIs   
    I think it would be more useful if this library was written in C and not C++.
    C code can be easily called from other languages, but not C++ (there is no standard C++ ABI).
     
     
  10. Xi195 liked a post in a topic by T8493 in RCL Trading APIs   
    Didn't RL say no when you asked them if you could open-source it?
     
  11. T8493 liked a post in a topic by dreamdaze in RCL Trading APIs   
    Hi Everyone,
    If anyone is interested I have a fully formed API in both .NET and FIX supporting subscription-model (ie: not restful) for live market-data (with formatted event-types including the bid/ask index for local level-II caching/updating on an event-by-event basis etc...) and order-entry (with pub-sub order-status, partial executions, remaining quantity - including auto-sequencing, true new/modify/cancel,  etc...).  This is a fully documented .NET .dll.
    It is also possible to host the service as a distributed model API, but I have been focused mainly on ensuring that the RCL translator (ie: restful->subscription based) is housed locally (current .NET .dll version pointing to public RCL takes up less than 1% processor power, on basic laptop).  Also, keep in mind that because its .NET based, it doesn't really work on a Mac.
    Tim (above) can vet for me, and can put you directly in touch with me if you want.
  12. cmbartley liked a post in a topic by T8493 in RCL Trading APIs   
    For starters:
    RL will first have to make clear which libraries will be maintained in the future and which will be abandoned (like C# .NET library and plethora of other repositories).
    We have only one high-level library (RippleAPI) which is written in javascript. Currently, there is no officially supported way of using this library in other languages. Ripple-REST was abandoned, the library that sits on top of RippleAPI and enables external access to RippleAPI is unsupported.
    This new C++ library will probably implement just serialization in signing, but not other things (e. g. transaction submission).
    RL will also have to provide a way to download historical ledgers/transactions. Querying rippled for each old ledger and each old transaction can take months.
    RL will also have to provide more documentation about everything, including the repositories like ripple-historical-database.
     
     
     
     
     
     
     
     
     
  13. cmbartley liked a post in a topic by T8493 in RCL Trading APIs   
    For starters:
    RL will first have to make clear which libraries will be maintained in the future and which will be abandoned (like C# .NET library and plethora of other repositories).
    We have only one high-level library (RippleAPI) which is written in javascript. Currently, there is no officially supported way of using this library in other languages. Ripple-REST was abandoned, the library that sits on top of RippleAPI and enables external access to RippleAPI is unsupported.
    This new C++ library will probably implement just serialization in signing, but not other things (e. g. transaction submission).
    RL will also have to provide a way to download historical ledgers/transactions. Querying rippled for each old ledger and each old transaction can take months.
    RL will also have to provide more documentation about everything, including the repositories like ripple-historical-database.
     
     
     
     
     
     
     
     
     
  14. T8493 liked a post in a topic by Vinnie in NuDB: C++ key/value database PLEASE UPVOTE   
    This is my shameless promotion of my library NuDB, and begging for Reddit upvotes (please upvote)
    https://www.reddit.com/r/cpp/comments/60px64/nudb_100_released_a_keyvalue_database_for_ssds/
     
  15. tulo liked a post in a topic by T8493 in RCL Trading APIs   
    What is RCL trading API? RippleAPI or rippled API?
     
     
  16. cmbartley liked a post in a topic by T8493 in RCL Trading APIs   
    For starters:
    RL will first have to make clear which libraries will be maintained in the future and which will be abandoned (like C# .NET library and plethora of other repositories).
    We have only one high-level library (RippleAPI) which is written in javascript. Currently, there is no officially supported way of using this library in other languages. Ripple-REST was abandoned, the library that sits on top of RippleAPI and enables external access to RippleAPI is unsupported.
    This new C++ library will probably implement just serialization in signing, but not other things (e. g. transaction submission).
    RL will also have to provide a way to download historical ledgers/transactions. Querying rippled for each old ledger and each old transaction can take months.
    RL will also have to provide more documentation about everything, including the repositories like ripple-historical-database.
     
     
     
     
     
     
     
     
     
  17. cmbartley liked a post in a topic by T8493 in RCL Trading APIs   
    For starters:
    RL will first have to make clear which libraries will be maintained in the future and which will be abandoned (like C# .NET library and plethora of other repositories).
    We have only one high-level library (RippleAPI) which is written in javascript. Currently, there is no officially supported way of using this library in other languages. Ripple-REST was abandoned, the library that sits on top of RippleAPI and enables external access to RippleAPI is unsupported.
    This new C++ library will probably implement just serialization in signing, but not other things (e. g. transaction submission).
    RL will also have to provide a way to download historical ledgers/transactions. Querying rippled for each old ledger and each old transaction can take months.
    RL will also have to provide more documentation about everything, including the repositories like ripple-historical-database.
     
     
     
     
     
     
     
     
     
  18. Global liked a post in a topic by T8493 in Countering the ‘Damocles Effect’   
    Volume doesn't tell the whole story, especially because volume on Poloniex is currently high compared to what it was several months ago.
    Still, when I look at orderbooks of some popular gateways, the bid side is almost empty near the tip of the orderbook.
    Take a look at: https://charts.ripple.com/#/markets/XRP/USD:rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B?interval=5m&range=1d&type=candlestick
    or
    https://charts.ripple.com/#/markets/XRP/EUR:rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq?interval=5m&range=1d&type=candlestick
    Even a non-whale can easily push the price below $0.006 and it is almost impossible to sell more than 1 or 2 millions of XRPs without significant slippage (>3%).
     
     
     
     
  19. enej liked a post in a topic by T8493 in IBM unveils Blockchain as a Service based on open source Hyperledger Fabric technology   
    https://techcrunch.com/2017/03/19/ibm-unveils-blockchain-as-a-service-based-on-open-source-hyperledger-fabric-technology/
     
     
  20. tomxcs liked a post in a topic by T8493 in Demand more info?   
    I think some of you use the term "volatility" incorrectly.
    Volatility takes into account "average" growth rate. You can have zero volatility AND the price that is rising or falling simultaneously.
    Low volatility is good for market makers - they can't efficiently compete for the tip of the order book if volatility is excessive. However, that doesn't mean that the price remains the same over longer periods of time.
     
     
  21. MundoXRP liked a post in a topic by T8493 in Demand more info?   
    If N is very large, then - even if people hold XRP for very short amount of time - lots of people will still hold lots of XRPs at any given point of time.
    EDIT: and a lot of market makers will also have to hold XRPs because these transactions will have to buy XRPs from somebody.
     
  22. tomxcs liked a post in a topic by T8493 in Demand more info?   
    I think some of you use the term "volatility" incorrectly.
    Volatility takes into account "average" growth rate. You can have zero volatility AND the price that is rising or falling simultaneously.
    Low volatility is good for market makers - they can't efficiently compete for the tip of the order book if volatility is excessive. However, that doesn't mean that the price remains the same over longer periods of time.
     
     
  23. MundoXRP liked a post in a topic by T8493 in Demand more info?   
    You need much less than $20b to move the price of XRPs significantly. Did people really invest billions of USD when the price hit $0.028 during the last pump?
  24. MundoXRP liked a post in a topic by T8493 in Demand more info?   
    If N is very large, then - even if people hold XRP for very short amount of time - lots of people will still hold lots of XRPs at any given point of time.
    EDIT: and a lot of market makers will also have to hold XRPs because these transactions will have to buy XRPs from somebody.
     
  25. tomxcs liked a post in a topic by T8493 in Demand more info?   
    I think some of you use the term "volatility" incorrectly.
    Volatility takes into account "average" growth rate. You can have zero volatility AND the price that is rising or falling simultaneously.
    Low volatility is good for market makers - they can't efficiently compete for the tip of the order book if volatility is excessive. However, that doesn't mean that the price remains the same over longer periods of time.