Jump to content

Professor Hantzen

Bronze Contributor
  • Content Count

    501
  • Joined

  • Last visited

  • Days Won

    1

Reputation Activity

  1. Like
    Professor Hantzen reacted to devnullprod in rippled source code analysis and audit   
    What better day to release parts 9-12 of our rippled source code audit than on 9/12! Read about the overlay network, find out how the nodestore works, and explore the details of ledger & transaction management and the consensus process!!!
    Follow us on twitter for more updates!
  2. Like
    Professor Hantzen reacted to Paradox in Rippled v1.1.0 is primed for upgrade. Is this the version needed for xRapid to be released?   
    The feeling I get (based on what has been communicated by Ripple employees in AMAs and at various conferences) is that its being 'held up' by the general lack of regulatory clarity in the space, and possibly volume constraints driven by the bear market.  But in all honestly I know nothing about what is going on behind the scenes so anyone's guess is as good as mine.
    I think its expected that XRP/JPY, XRP/MXN, and XRP/USD will be some of the first xRapid corridors,  but I also think XRP/THB, XRP/SGD, XRP/PHP, and XRP/CHF won't be far behind.   Keep an eye on Thailand in particular.
     
  3. Like
    Professor Hantzen reacted to vsyc in Rippled v1.1.0 is primed for upgrade. Is this the version needed for xRapid to be released?   
    I think that "live" or "production" means that cutomer(s) will put some of its operation(s) via xRapid on daily basis for a long time, so they will have product that be using xRapid and real people will see real benefits and this is can not be dropped like pilot, because it costs.
    I totally agree with you that xRapid itself is already in production (as environment) and runs live transactiona (for pilots etc.) e.g. one example is 3 exchanges using it for liquidity (Bitso, Bittrex and some Philipinese), Cuallix uses its for internal operations to save cost, but they use real money.
    Anyway, on next AMA this questions should be asked.
  4. Like
    Professor Hantzen got a reaction from Paradox in Rippled v1.1.0 is primed for upgrade. Is this the version needed for xRapid to be released?   
    Thanks! Great source.  He's SVP of Product so he really should know the terminology they're using internally.  Actually this concerns me slightly, as I had the impression these pilots were ongoing, but it sounds almost as if they've wound down, though that could be my misinterpretation.  It's just concerning as it sounds like the pilots were things that came and went and the product now requires more work.  Ripple does have a history of pivoting on major issues, which I don't see as a bad thing (Apple does too and they're not doing too badly).  But it does make me wonder if xRapid is not as ready as everyone hopes.

    Maybe its just one of those things - someone asked them a question, and so they used the same terminology as the questioner in response.  Well, so long as someone at some point starts using some XRP to move their customers money around and keeps on doing it, I guess we can all agree its "live", "in production", and if we must.... "released".
  5. Like
    Professor Hantzen reacted to Paradox in Rippled v1.1.0 is primed for upgrade. Is this the version needed for xRapid to be released?   
    @Professor Hantzen Yes I do.   Ripple themselves (start at 7:10).    In this particular source, Asheesh actually uses the term "production", and that in his view xRapid is *not* yet in production as they are still trying to perfect the customer experience.   Pay particular attention at 7:40 as well.   
     
     
  6. Like
    Professor Hantzen got a reaction from lucky in Rippled v1.1.0 is primed for upgrade. Is this the version needed for xRapid to be released?   
    xRapid is in production use *right now*, and has been for several months, built on whatever previous rippled versions were in use at that time. That being the case, it follows therefore that its current use is not dependent on any future upgrades to rippled. As @lucky has said however, we do not know what future features are planned for xRapid, and how these may or may not be affected by future rippled upgrades.  But even including that caveat, the subject title of this thread is unintentionally misleading, as it is based on misunderstanding the present, known situation and relationships between xRapid and rippled.
  7. Like
    Professor Hantzen got a reaction from lucky in Rippled v1.1.0 is primed for upgrade. Is this the version needed for xRapid to be released?   
    xRapid is in production use *right now*, and has been for several months, built on whatever previous rippled versions were in use at that time. That being the case, it follows therefore that its current use is not dependent on any future upgrades to rippled. As @lucky has said however, we do not know what future features are planned for xRapid, and how these may or may not be affected by future rippled upgrades.  But even including that caveat, the subject title of this thread is unintentionally misleading, as it is based on misunderstanding the present, known situation and relationships between xRapid and rippled.
  8. Haha
  9. Thanks
    Professor Hantzen got a reaction from xrphilosophy in Ripple Concensus vs PBFT or any other consensus algorithm   
    #1: Speed & throughput. PoW approaches currently in demonstrable widespread use (Ethereum, Bitcoin etc) typically have block-times ranging from 10-15 seconds up to 10-15 minutes, and can only handle a comparatively tiny number of transactions per second versus consensus/BFT that have similar uptake.

    #2: One of the reasons for the creation of the original Ripple network and XRP was specifically to come up with something less-wasteful (more environmentally-friendly) than PoW.  Whilst being terribly slow, PoW also throws away vast computing resources and electricity by comparison.

    I'm not sure on the specific differences between PBFT and the consensus mechanism in use on the XRP Ledger, but AFAIK they involve similar tradeoffs in terms of agreement.

    Finally, as I understand it, an upgrade to the consensus protocol, called "Cobalt" plans to address some issues regarding agreement distributions (though maybe not the one you are concerned with here).

    I'm interested to know - why do you think this 20% matters?  Can you foresee a situation where this could cause a problem?  Each node has its own UNL so if problems with specific nodes keep cropping up they can simply be cut out of the consensus process and bring the network back into agreement were it to halt for a while due a malicious collusion.
  10. Thanks
    Professor Hantzen got a reaction from xrphilosophy in Ripple Concensus vs PBFT or any other consensus algorithm   
    #1: Speed & throughput. PoW approaches currently in demonstrable widespread use (Ethereum, Bitcoin etc) typically have block-times ranging from 10-15 seconds up to 10-15 minutes, and can only handle a comparatively tiny number of transactions per second versus consensus/BFT that have similar uptake.

    #2: One of the reasons for the creation of the original Ripple network and XRP was specifically to come up with something less-wasteful (more environmentally-friendly) than PoW.  Whilst being terribly slow, PoW also throws away vast computing resources and electricity by comparison.

    I'm not sure on the specific differences between PBFT and the consensus mechanism in use on the XRP Ledger, but AFAIK they involve similar tradeoffs in terms of agreement.

    Finally, as I understand it, an upgrade to the consensus protocol, called "Cobalt" plans to address some issues regarding agreement distributions (though maybe not the one you are concerned with here).

    I'm interested to know - why do you think this 20% matters?  Can you foresee a situation where this could cause a problem?  Each node has its own UNL so if problems with specific nodes keep cropping up they can simply be cut out of the consensus process and bring the network back into agreement were it to halt for a while due a malicious collusion.
  11. Like
    Professor Hantzen reacted to achuthomas in Ripple Concensus vs PBFT or any other consensus algorithm   
    If Ripple only assures a consensus if less than 20% of the node are byzantine then why is it the consensus algorithm preferred by Ripple than PBFT or PoW which looks like more reliable consensus algorithm
  12. Like
    Professor Hantzen reacted to justmoon in Concerns about Coil data collection   
    Hey all - thanks for the feedback, especially for breaking down the doc and highlighting the problematic sections. I just read through the thread and will be looking into this. The ToS were prepared by our external counsel and I wasn't part of that process, so I'll find out why those terms were included and if we can take them out. There may be some justification that I'm just not aware of.
    We have zero interest in selling user data or running ads - those are crappy, backwards ways of making money and the whole point of Coil is that those monetization workarounds are no longer necessary. We are paid directly by our users, so we don't need any other revenue stream.
    Expect a more full-fledged reply once I've had a chance to meet with the lawyers.
     
  13. Thanks
    Professor Hantzen reacted to devnullprod in rippled source code analysis and audit   
    Parts 1-8 of our rippled source audit is now online!
    http://wipple.devnull.network/research/rippled.html
     
    If you like this please consider following us on twitter and/or donating to the Wipple XRP Intelligence Project:
    https://twitter.com/DevNullProd
    http://wipple.devnull.network/donate.html 
  14. Like
    Professor Hantzen reacted to tulo in New Consensus Articles   
    I think it's hard for now to talk about decentralization. The UNL overlap must be 90%, so either all validators agree on a "common" UNL list, or they'll diverge. So the only way to be decentralized is that this common UNL list is agreed between different parties, and not imposed suggested by Ripple.
    Or to switch to Cobalt or Stellar Consensus which allow more flexible configurations.
     
    But I like how step by step it's always more and more decentralized. 
     
  15. Like
    Professor Hantzen reacted to Sukrim in New Consensus Articles   
    https://github.com/ripple/rippled/issues/1751 (June 2016, 0 comments)
    Only Stellar has asuch an API and it is not punished to lie in the responses of that API as far as I understand their consensus algorithm. XRPL doesn't even try to expose/publish UNLs, sometimes for good reasons in my opinion.
    https://github.com/ripple/rippled/issues/2396 (February 2018, 0 comments) could help a bit there.
  16. Like
    Professor Hantzen reacted to mDuo13 in New Consensus Articles   
    We've recently published two new articles to the XRP Ledger Dev Portal, both discussing the subject of Consensus:
    Introduction to Consensus is just that—a beginner level summary of Consensus in the XRP Ledger. Hopefully this can help new people pick up enough to get up and running with the XRP Ledger without getting as deep into the weeds as the older, more detailed consensus article. Consensus Protections Against Attacks and Failure Modes is a new FAQ-like article that discusses some of the various threats to the XRP Ledger and how it's set up to handle them.
    There's also a new blog post @JoelKatz shared on the Ripple Insights Blog: The Inherently Decentralized Nature of XRP Ledger. This one talks about the future of XRP decentralization and why the lack of mining is good for the network. (Forewarning: I think this article can be a little confusing when it switches between talking about the total number of validators and the trusted validators that most of the network pays attention to.)
    If you find these articles helpful or interesting, we'd be happy to hear it! And if you're befuddled or want to know more, please ask away. More importantly, I hope that building a better understanding of the XRP Ledger and its greater ecosystem can help you make more informed choices in the future, especially if you choose to contribute to the Internet of Value!
  17. Like
    Professor Hantzen reacted to WuWei in Ripple Drop Episode 4   
    I agree: it's a much better episode - thanks for posting it....
  18. Like
    Professor Hantzen reacted to Kpuff in Ripple Drop Episode 4   
    Hey guys I just saw the new episode. It's actually alot better than the previous ones theve done so far. Anyways I was surprised to see it hasn't been posted on here yet. Enjoy!
    https://ripple.com/insights/ripple-drop-episode-4/
  19. Like
    Professor Hantzen reacted to tulo in Fair XRP - XLM comparison   
    Reserved for comparison...it will take some time to fill 
     
    Company Type:
    Ripple: Private company
    Stellar.org: Non-profit organization (to be checked)
    Employees:
    Ripple: 318
    Stellar.org: 18
    Sources: https://www.linkedin.com/company/stellar-development-foundation; https://www.linkedin.com/company/ripple-labs
    Average Transaction Time:
    XRP: 3.7s
    XLM: 5s
    Sources: https://xrpcharts.ripple.com/#/metrics  ;  https://dashboard.stellar.org/
    Reserves:
    XRP: 20 XRP per wallet + 5 XRP per trust line
    XLM: 1 LMN per wallet + 0.5 LMN per trust line
    Average Transaction Fees:
    XRP: 0.002 XRP per transaction
    XLM: TODO find source
    Sources: https://xrpcharts.ripple.com/#/metrics  ;  TODO
    Transactions Per Second:
    XRP - 1500 TPS (claimed), ??? TPS (tested), 50000 with payment channels.
    XLM - 1000 TPS (claimed), ??? TPS (tested) 
    Sources: http://highscalability.com/blog/2017/10/2/ripple-the-most-demonstrably-scalable-blockchain.html; 
    Total Coins:
    XRP: 100B at inception. Decreasing over time for the burning fees mechanism. Actually there are 99.991B XRP.
    XLM: 100B at inception. Increasing over time due to intrinsic inflation mechanism. Actually there are 104.18B XLM.
    Sources: https://xrpcharts.ripple.com/#/  ;  https://dashboard.stellar.org/
    Circulating Supply:
    XRP: 39.3B (39.3%)
    XLM: 18.8 (17.9%)
    Coins Owned by The Company:
    XRP: 60.6B (60.6%)
    XLM: 85.41B (82.1%)
    Number of Accounts:
    XRPL: 1.3M
    XLM: 788k
    Sources: https://xrpcharts.ripple.com/#/accounts  ;  https://stellar.expert/explorer/public/
    Consensus Mechanism:
    XRP: Ripple Consensus Protocol. Requires 40% overlap of UNLs for non-fault tolerant case. Requires 90% overlap of UNLs for fault tolerant case to guarantee safety and liveness. Planning to move to Cobalt algorithm, which requires 60% overlap in the fault-tolerant case.
    XLM: Stellar Consensus Protocol (Federate Byzantine Agreement). Didn't find any detailed data on the analysis of the stability for safety and liveness.
    Sources: https://ripple.com/files/ripple_consensus_whitepaper.pdf; https://arxiv.org/pdf/1802.07242.pdf; https://arxiv.org/pdf/1802.07240.pdf; https://www.stellar.org/papers/stellar-consensus-protocol.pdf
    Decentralization and Validators:
    XRP: 21 validators. 10 owned by ripple (48%).
    XLM: 72 validators. 3 owned by SDF (4%).
    Sources: https://minivalist.cinn.app/  ;  https://stellarbeat.io/nodes
    Exclusive Features (the other ledger doesn't have it):
    XRP:
    Payment Channels: Payment Channels are an advanced feature for sending "asynchronous" XRP payments that can be divided into very small increments and settled later. Offline payments as Lightning Network to boost possible transactions to 50-70k per second. Escrow: Escrow is a feature of the XRP Ledger that allows to send conditional XRP payments. These conditional payments, called escrows, set aside XRP and deliver it later when certain conditions are met. Conditions to successfully finish an escrow include time-based unlocks and crypto-conditions. Checks: The Checks feature in the XRP Ledger allows users to create deferred payments that can be canceled or cashed by the intended recipients. Like personal paper checks, XRP Ledger Checks start with the sender of the funds creating a Check that specifies an amount and receiver. Freeze: All non-XRP currencies can be represented in the XRP Ledger as issued currencies. In certain cases, to meet regulatory requirements, or while investigating suspicious activity, an exchange or gateway can freeze non-XRP issued currency balances. XRP CANNOT be frozen by any entity or individual. Invariant Check: code that runs automatically and in real time after each transaction completes, and examines the changes it made for correctness before the results are committed to the ledger. The checks—which we believe will never trigger—help protect the integrity of the XRP Ledger from bugs yet to be discovered, or even created. Autobridging: the autobridging feature improves offer placement in a similar fashion to pathfinding: when consuming existing offers, a newly placed offer will have the liquidity available in not only the direct order book (source to destination currency) but also in the corresponding books in which XRP is the destination and source respectively. XLM:
    Inflation: The Stellar distributed network has a built-in, fixed, nominal inflation mechanism. New lumens are added to the network at the rate of 1% each year. Each week, the protocol distributes these lumens to any account that gets over .05% of the “votes” from other accounts in the network. Account Merge: Transfers the native balance (the amount of XLM an account holds) to another account and removes the source account from the ledger. Useful to unlock reserves on the accounts. List of operations: Transactions contain an arbitrary list of operations inside them. Typically there is just one operation, but it’s possible to have multiple (up to 100). Operations are executed in order as one ACID transaction, meaning that either all operations are applied or none are. If any operation fails, the whole transaction fails. Federation: The Stellar federation protocol maps Stellar addresses to more information about a given user. It’s a way for Stellar client software to resolve email-like addresses such as name*yourdomain.cominto account IDs like: GCCVPYFOHY7ZB7557JKENAX62LUAPLMGIWNZJAFV2MITK6T32V37KEJU. Major Partners:
    TODO
    Related Projects:
    TODO
    Can Issue IOUs:
    XRP: yes
    XLM: yes
    Independent Wallets:
    TODO
    Exchanges Supporting:
    XRP: TODO
    XLM: TODO
    Pairs on Exchanges:
    XRP: 139
    XLM: 66
    Sources: https://www.coingecko.com/en/coins/stellar/trading_exchanges; https://www.coingecko.com/en/coins/ripple/trading_exchanges
    API:
    XRP: 
    Supported, well documented, but always changing JS API (RippleAPI) Data API to access ledger data (also historical). Many bugs were found. Rippled API to interact with rippled (the main node). XLM:
    REST API (maintained from SDF) JS SDK (maintained from SDF) Go SDK (maintained from SDF) Java SDK (maintained from community) Ruby SDK (maintained from community) Python SDK (maintained from community) C# SDK (maintained from community) Sources: https://developers.ripple.com/index.html; https://www.stellar.org/developers/
    TODO check Stellar SKD if working well (I have no experience)
     
  20. Thanks
    Professor Hantzen reacted to devnullprod in Wipple Update - 08/11/18   
    Happy Saturday everyone! How about some good news while everyone is freaking out about XRP being below $0.30! We're pleased to announce the 0.9.0 release of the Wipple XRP Intelligence framework. For those unaware, Wipple is a XRP network client and analyzer that follows the ledger and collects / aggregates account and transaction statistics. This release bring many improvements to both the UI and backend, facilitating more and higher quality mechanisms to derive ledger stats!
    To start off the entire reporting system have been revamped. You can see the sleeker frontend on the live site (screenshot below). Furthermore the backend has been revamped to just generate raw statistical data which is rendered on the frontend. This means anyone can issue web requests to retrieve ledger stats without having to worry about following the live ledger. For example to retrieve the most_payments for any given hour, all one has to do is send a HTTP request to http://wipple.devnull.network/reports/hourly/<period>/json/most_payments. The full list of stats / API methods can be seen on the "API Docs" accessed on the reports landing page (screenshot below).
    Various other aspects of Wipple Live have been revamped including the incorporation of 'semantic data' in the live entity viewer. For example one can now navigate to any given ledger and see XRP timestamps converted to local time, clickable accounts, transactions, and ledger objects and much more! This is all ontop of many bugfixes and optimizations that we've incorporated into both the backend synchronization process and frontend interface!
    That's all for now but be sure to check back soon for more updates! We're currently working on Twitter Integration into the reporting system, so if you haven't followed @devnullprod on twitter be sure to do so, soon you'll be receiving automatic ledger stats in real time! We're also planning on adding 'smart' capabilities the Transaction Submission mechanism, so known fields are autofilled when submitting new transactions!


  21. Like
    Professor Hantzen got a reaction from Kakoyla in Multiple Ripple balances viewer in node.js   
    Sure, but I'm not a fan of ripple-lib/rippleAPI - it's changed so much it's been a nightmare to develop with, and ripple-lib in particular was very bloated (not sure on RippleAPI?).  I run latency and memory sensitive applications mostly, so I tend to roll everything myself with the rippled websocket interface - it's about as fast and lean as you can get, hasn't changed in the past four years and requires only a single websocket. A little more coding is required, but I'm used to it. 
  22. Thanks
    Professor Hantzen reacted to cmbartley in Q2 2018 XRP market reports   
    $0.0044 -> $0.45 in 18 months is nothing?
  23. Like
    Professor Hantzen got a reaction from King34Maine in Q2 2018 XRP market reports   
    To be clear - the important part of the sales did not drop, they went up, if only slightly.  Further, the less-important part of the sales declining in USD looks positive to me.

    Regarding the direct sales, these went up slightly from $16.60m, to $16.87m.  These are sales of XRP direct to new clients, so it's good news they've sold as much in USD as the previous quarter.  Also, given that the market price of XRP is significantly lower this quarter versus last, yet they sold the same amount in dollar value, suggests many more clients may have purchased a lot more XRP this quarter (up to six times as much going by the price extremes, or at least twice as much).  We know they're taking on more clients from Ripple's statements, but its good to also see it reflected in the figures and have a hint at by how much.

    Programmatic sales are lower in USD, yes.  However, in XRP they are in some sense higher, when taken as a percentage of total traded volume.  Ie, as a percentage of total traded volume, more XRP was sold this quarter than last.  As these sales are bound by exchange-traded volume, to me that is a relevant consideration (though I can understand the argument it isn't).  Anyway, these sales are on-exchange, and for the purposes of funding Ripple operations...

    So... going back to the USD side - as in, the amount in USD Ripple ends up with after selling - tells a more direct story.  On-exchange sales dropping when the price is low is positive (to me, at least) for two reasons.  Firstly, Ripple clearly believes XRP will appreciate, and so isn't cashing out as much as when XRP's price was higher.  Further, despite Ripple's high rate of expansion, they can clearly afford such a luxury of waiting, which must mean they are balancing their books well and have enough operational cash.
  24. Like
    Professor Hantzen got a reaction from King34Maine in Q2 2018 XRP market reports   
    To be clear - the important part of the sales did not drop, they went up, if only slightly.  Further, the less-important part of the sales declining in USD looks positive to me.

    Regarding the direct sales, these went up slightly from $16.60m, to $16.87m.  These are sales of XRP direct to new clients, so it's good news they've sold as much in USD as the previous quarter.  Also, given that the market price of XRP is significantly lower this quarter versus last, yet they sold the same amount in dollar value, suggests many more clients may have purchased a lot more XRP this quarter (up to six times as much going by the price extremes, or at least twice as much).  We know they're taking on more clients from Ripple's statements, but its good to also see it reflected in the figures and have a hint at by how much.

    Programmatic sales are lower in USD, yes.  However, in XRP they are in some sense higher, when taken as a percentage of total traded volume.  Ie, as a percentage of total traded volume, more XRP was sold this quarter than last.  As these sales are bound by exchange-traded volume, to me that is a relevant consideration (though I can understand the argument it isn't).  Anyway, these sales are on-exchange, and for the purposes of funding Ripple operations...

    So... going back to the USD side - as in, the amount in USD Ripple ends up with after selling - tells a more direct story.  On-exchange sales dropping when the price is low is positive (to me, at least) for two reasons.  Firstly, Ripple clearly believes XRP will appreciate, and so isn't cashing out as much as when XRP's price was higher.  Further, despite Ripple's high rate of expansion, they can clearly afford such a luxury of waiting, which must mean they are balancing their books well and have enough operational cash.
  25. Like
    Professor Hantzen got a reaction from King34Maine in Q2 2018 XRP market reports   
    To be clear - the important part of the sales did not drop, they went up, if only slightly.  Further, the less-important part of the sales declining in USD looks positive to me.

    Regarding the direct sales, these went up slightly from $16.60m, to $16.87m.  These are sales of XRP direct to new clients, so it's good news they've sold as much in USD as the previous quarter.  Also, given that the market price of XRP is significantly lower this quarter versus last, yet they sold the same amount in dollar value, suggests many more clients may have purchased a lot more XRP this quarter (up to six times as much going by the price extremes, or at least twice as much).  We know they're taking on more clients from Ripple's statements, but its good to also see it reflected in the figures and have a hint at by how much.

    Programmatic sales are lower in USD, yes.  However, in XRP they are in some sense higher, when taken as a percentage of total traded volume.  Ie, as a percentage of total traded volume, more XRP was sold this quarter than last.  As these sales are bound by exchange-traded volume, to me that is a relevant consideration (though I can understand the argument it isn't).  Anyway, these sales are on-exchange, and for the purposes of funding Ripple operations...

    So... going back to the USD side - as in, the amount in USD Ripple ends up with after selling - tells a more direct story.  On-exchange sales dropping when the price is low is positive (to me, at least) for two reasons.  Firstly, Ripple clearly believes XRP will appreciate, and so isn't cashing out as much as when XRP's price was higher.  Further, despite Ripple's high rate of expansion, they can clearly afford such a luxury of waiting, which must mean they are balancing their books well and have enough operational cash.
×