Jump to content

Professor Hantzen

Bronze Member
  • Content Count

    541
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Professor Hantzen

  1. Professor Hantzen

    Fast Payments Task Force - Weird Actions

    Has anyone tried crawling those comment PDF's for mentions of Ripple, R3, blockchain, SWIFT, "digital asset" etc?
  2. @coinologist I don't think its your question that set anyone off, its that there are regular influxes of new accounts here that come here specifically to try and stir up negativity (possibly to do things like find source material to fuel a negative article on an anti-XRP blog). As such, some here may understandably be on a hair-trigger alert for it. In my experience generally the forum will welcome questions, even difficult ones - assuming the result is a critical discussion that's productive. Also, you're likely better asking these types of questions in the Technical Discussion sub-forum - even if simple initially, such a query will likely become more technical as its answered in detail.
  3. Professor Hantzen

    XRP WORTHLESS IN 2019?

    @LordVetinari Thanks for the correction! Normally I wouldn't skip due process, but I must confess that in this case I didn't bother to read the article after reading the message.
  4. Professor Hantzen

    XRP WORTHLESS IN 2019?

    So according to you XRP probably won't be worthless, and will also be worthless. Are you talking about same XRP we are? Or is this some new Schrodinger's XRP? Several institutions are using XRP right now to move real money, and are saving money doing so and talking about it. None of them are banks yet, but that's because banks feel bound much more tightly by regulation and need to wait for clarity before jumping in. That said, its very likely banks at least now feel comfortable enough to *buy* XRP, and possibly in greater and greater quantities. If you look at the XRP Markets Quarterly Reports published by Ripple and combine the numbers logically with comments Brad and others have made it seems unlikely the purchasers are all non-banks given the amount of banks they've signed on as customers versus other entities. In any case, even if they don't buy it and never use it - people will probably endlessly speculate that one of them one day might, and that in itself will keep the price up. How can I be so sure? Well, its what has essentially driven all of the price activity in XRP over the past 6 years since it began. Pretty difficult to argue with I'd expect.
  5. Professor Hantzen

    xrpcharts api: tps / tps calculation

    I doubt it's in the API, on that page they're probably just dividing the number of transactions in each ledger by the latest close interval. You can get the numbers for this using the ledger subscribe command. Take the ledger stream responses, subtract the ledger_time from the previous ledger_time (it's in seconds), then divide this by the txn_count. Bear in mind the above is just one way to do it (and a guess at what's employed on that page). There is no "definitive" way to calculate TPS, see here for more details.
  6. Professor Hantzen

    Execute multiple transactions atomically

    There may be a way to accomplish this using Escrow, depending what you're doing: https://github.com/ripple/ripple-lib/issues/839 Stellar is not UTXO-based and has something like what you're suggesting built-in (it was originally forked from the XRP Ledger codebase). I'm also pretty sure something similar has been proposed for the XRP Ledger. @tulo may know?
  7. Professor Hantzen

    XRP Account Distribution status

    My previous statement backs up the other answers, but using the already available data. The OP's charts are presented in (from the perspective of the Ripple Base58 alphabet) a completely nonsensical order of "123... ABC... abc...". So the charts display a "random" distribution of accounts. If you reorder the charts according to the correct order (which runs "rpshna...", where r = 0, p = 1, s = 2, h = 3, and so on...), you'll find the distribution is not random at all, but completely aligned in a single block representing a subset-range of the total set. This (to me, at least), sufficiently illustrates the previous commenters statements but without requiring further study (though anyone is welcome to dive deeper). FWIW, I've already concluded my own various studies of this kind and am satisfied with the results: Ripple accounts/keypairs are randomly distributed.
  8. Professor Hantzen

    Can anyone explain this

    If you're seeing a payment that's failed and is continuously repeating (maybe its automated and run out of funds?). This is simply something you might see... what exactly do you want to know? Also, paste the account as text in your message so others can examine it themselves.
  9. Professor Hantzen

    XRP Account Distribution status

    If you have a look at the Ripple Base58 alphabet "rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz", and reorder your chart according to this you will see that the lower numbers group active distributions and the higher group inactive with a cut-off point around the middle.
  10. Professor Hantzen

    really low on-ledger activity

    It's tempting to think of the "transactions per second" value as a fixed quantity that can be known and set in stone at any given moment, but this is simply not the case. It is possible to take the exact same set of numbers - that is, the hard data of how many transactions were closed in each ledger, and contort them to create any variety of "transactions per second" rates depending on which time-frames are used for the calculation. For example, let us take this set of ledgers with an average close time of 3.5 seconds per ledger (I will use a simplified dataset for the sake of illustration, but a real dataset could potentially look much like this but for some noise and gradients): TIME - ledger number - tx's per ledger (00:00 - 08:00) - ledgers 1-10000: 5 tx's each (08:00 - 16:00) - ledgers 10001-20000: 20 tx's each (16:00 - 23:59) - ledgers 20001-30000: 1 tx each This amount of ledgers comprises (roughly) a days worth of activity on the XRP Ledger. Let's now have three people try to define the TPS for a given time on that day. Let's say the time we want to know the TPS for is 16:23. Person A looks at the transactions closed in the ledgers for the hour from 16:00 - 16:59, and comes up with 0.28 TPS as the TPS for the moment of 16:23. That is, every second, on average, 1/3.5th of a transaction was closed around that time. Person B takes an average of the txn's from the ledgers across the whole day, and comes up with 8.66 TPS for the moment of 16:23. Person C takes the values from an hour prior to 16:23, and an hour subsequent to 16:23, and comes up with 6.85 TPS. Three different, reasonable approaches to defining TPS, and three completely different TPS values as a result. There is no "correct" time-frame to consider. If someone were to pick the exact moment of 16:23.569 (569 ms) and locate the ledger that closed closest to that moment, and it contained 4 transactions, but the previous ledger contained 53 transactions, and the subsequent ledger contained 85 transactions, we can see that the "TPS" for that moment of 1.14 TPS (4 txn's / 3.5 seconds) would not be "accurate". This is the exact problem we are seeing at a larger scale with the example above. Conclusion: Without precise and universally agreed rules upon which timeframe to use to measure transactions per second,"TPS" is not a fixed value that can be known or defined by anyone. If you see a "TPS" quoted somewhere, its reasonable to assume the person coding this has done their best given the realities of this situation, and you're welcome to take it as a rough guideline for that moment - but don't regard it as gospel or preach it as such, nor expect different sites to arrive at the same value.
  11. Great you did that, I hope they follow up on it. Understandable if you don't want to share the details... I would love it if this issue could be more or less definitively solved (if possible) *before* the XRPL becomes the domain of significantly more powerful entities than "the rest of us". Then again, the distributed trading aspect of the XRPL may just slip by the wayside even as the rest of it succeeds.
  12. @Sukrim @tulo My last information regarding this issue was this detailed thread. It left me with the impression that the current system works, in as much nobody has successfully exploited it, despite many theorising that it may be exploitable. I'm sceptical of any theorising that involves the potential for guaranteed profit that yet remains unclaimed. If the theory holds, we'll see evidence of it on the ledger. It sounds as if this situation may have changed since then?
  13. I"m not sure how being able to view the current list of proposed transactions allows for front-running? The most an actor with that information can do is submit a reactionary transaction into the same proposed list - however, they cannot determine the execution order of the finalised, validated set, so would not success at front-running by this method essentially be random? I guess it would be possible for a bad validator (to whom you are choosing to submit transactions to directly) to provide a fake response, and submit their own transaction in your place, silently delaying yours until the next consensus round. However, you would notice this and be able to switch to another validator instead (or just run your own from the outset).
  14. Professor Hantzen

    XRP Ledger transaction volume surpasses total trading volume

    Historically, payment volume often far exceeded transaction volume. Its easy for even a single actor (with at least two accounts) to spam up millions and billions of payment volume at very little expense sending the same funds back and forth. Transactions however usually will incur significant risk if one were to attempt the same as they have to deal with price/orderbook fluctuations and/or spread, and/or IOU fees. As such, it's likely payment volume will peak out greater at times and with no impactful cause. The balance between the two is therefore not a reliable indicator. Maybe in a few years when the landscape has changed - but at the moment the ledger is mainly populated by people testing things out. Any single entity conducting a relatively cheap on-ledger payments stress-test could for example cause a peak in payments volume. Or an actor with badly written code (something we've seen a few times in other areas).
  15. Professor Hantzen

    secp256k1 endomorphisms

    @caroma If you enable this and are able to improve rippled performance, maybe post a github issue with your findings (https://github.com/ripple/rippled/issues) and see if this can be made the default?
  16. That depends on the use-case and how it's set up. In some situations there will be an advantage - possibly significant. In others, there will be none. In the case of a malicious actor executing a predefined set of transactions for a market maker for example, the net loss may be minimal - a bunch of sells or buys executed and resulting in a unintended configuration of funds and the payment of fees, but no actual loss. However, the same malicious actor gaining access to a hot wallet could do whatever they wish with whatever funds that wallet controls.
  17. Professor Hantzen

    Stock Node vs. Validator

    @nikb @mDuo13 ?
  18. Professor Hantzen

    Bitstamp selects trading system from Cinnober

    Assuming its Fair Fair Fair...
  19. Professor Hantzen

    Does XRP Have a Name Problem?

    @Stormchaser417 It's not called or pronounced "zerp". That's an unofficial nickname given by some community members (personally, I can't stand it - for similar reasons to you - but I believe people are free to call things whatever they want and from that angle I support it 100%). Any official reference always pronounces each letter "X-R-P", for example, when spoken about by it's inventors. "XRP", pronounced as an acronym, is the name.
  20. This is a great question, and a correct answer may be as varied as there are exchanges. I can't say anything for sure, but in my general experience, exchange order-matching (in any market) can be a dark and unfair place. In a more demonstrable sense, you'll find that when things get busy on most exchanges, they slow down processing orders or even die completely. This suggests many may simply keep the various clocks in different areas synchronised, and make a (nanosecond perhaps) timestamp when receiving a trade. Then they execute in a distributed queue which, when large enough, causes delays in order processing as trades are sent back and forth (I'm sure we've all experienced an exchange order taking aeons to return a result, especially during high market activity). They likely also have various contingency plans which may violate the expected order (and so also fairness) to get things moving and/or mitigate liquidity problems. The metric you want to be tracking is not ping, but order confirmation time. Run a timer from submitting a trade to receiving a response. Try that from different locales and see what you get. It will likely be much larger than the ping in general, and (hopefully...) more consistent regardless of where you are testing from. Only test locales simultaneously, and across similarly-liquid markets, as different times of day and market activity will likely affect results.
  21. Professor Hantzen

    Why. ledger close interval decreasing?

    If you look at the charts above that one, transactions trended down over the same period of time (Sept-Oct), so maybe ledgers were able to be closed more frequently as there wasn't as much to get done. This isn't always how the network responds - if you look at other times, transactions going up coincided with faster closes. Possibly it has this time because of the type of transactions that decreased. At the bottom of that page, you can see transactions by type and result. There is a large drop in OfferCancel's over that period, and a fall-off in the many tecPATH_DRY's that were coming through. Perhaps both of these dropping together resulted in less load on the consensus process and so a faster rippled.
  22. Professor Hantzen

    XRP UNITED - rP0w3rP01nT.xrp

    This is certainly a concern. I think the marketing is spot-on for who they're going for, but they do need to address the trust issue in a big way to attract more than this crowd. Though I believe people who will respond to this style of marketing are a huge part of the current crypto demographic, they are not necessarily the part with the most money or the longest retention.
  23. Professor Hantzen

    XRP UNITED - rP0w3rP01nT.xrp

    Great video, but the voiceover volume is too low relative to the music. You should also cut the last minute of the video. Videos with longer runtimes can be discouraging for people to view, and this is effectively 1:40 not 2:40. Certainly its annoying for the viewer to have to skip through to discover there is no further information. Other than these two criticisms though, its really great - I think you're doing awesome work.
  24. If you need to sign transactions dynamically and frequently via a script, there is really nothing you can do to improve security beyond that of the machine running the script. The secret will have to be stored in memory somewhere, so your script can use it. You could use a secure element, but if the script can access the secure element, so can someone with control of the machine. If you have enough similarity in your transaction dynamics, you could theoretically sign batches of valid, labelled transactions offline (by sequence number), and manually transfer them to the online machine at regular intervals. Your script could then select the appropriate transactions throughout the time period. The danger then is limited to a malicious actor choosing to execute only the full set of transactions for that period of time. As this was going to happen anyway - and depending on what your script is doing - this may minimise any potential damage somewhat.
  25. Professor Hantzen

    Bot trading with Gatehub

    Yeah, as soon as traditional banking is involved things get slow and costly. Hopefully sometime soon, that won't be necessary anymore.
×