Jump to content

Professor Hantzen

Bronze Member
  • Content Count

    593
  • Joined

  • Last visited

  • Days Won

    1

Professor Hantzen last won the day on February 22 2017

Professor Hantzen had the most liked content!

About Professor Hantzen

  • Rank
    Advanced

Contact Methods

  • Website URL
    https://twitter.com/phantzen

Profile Information

  • Gender
    Male

Recent Profile Visitors

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

  1. The "key" you're presumably referring to (a "secret", in the form "shA2hufwhA7JNC7Cf4GncxTssxzk9") is in fact a kind of double-compressed version of the private key. Unlike some other systems, the actual private key is not typically revealed to, or directly used by the account owner when accessing the XRPL. It goes something like this: SECRET --> PRIVATE_KEY_SEED --> PRIVATE_KEY That said, due to this methodology, XRPL private keys are in fact *effectively* only 128 bits long, and whilst this is used to derive a 256 bit private key (like Bitcoin), the amount of information goin
  2. The XRP Ledger is a decentralised exchange (perhaps the first). An account that is "submitting an OfferCreate transaction" on the XRP Ledger (eg, to trade XRP for BTC) is analogous to an account on a centralised exchange - such as Kraken or Coinbase Pro, for example - that is "placing a trade" (eg, to buy XRP/BTC). Typically, any account can make such an offer on either type of exchange. You can see some of the various "trading pairs" available on the XRP Ledger's decentralised exchange by visiting http://xrpcharts.com The difference is mainly that on a centralised exchange, the issuer o
  3. This is unfortunately an unsolvable kind of chicken and egg problem. If there was such a status-checking service, there would then likely be times when the exchange you're checking is actually fully operational and working fine, but the service that provides the status check is down, or reporting incorrectly. Thus, you'd then need another one to check on that status reporter, and so on. There are "is it down?" websites intended for verifying large-scale, long-term outages of mainstream websites (usually with comments where users can discuss the state of things in their own locale etc), and
  4. It's calculated here: https://github.com/ripple/rippled/blob/fa57859477441b60914e6239382c6fba286a0c26/src/ripple/protocol/impl/PublicKey.cpp#L306:L319 With this: https://github.com/ripple/rippled/blob/5214b3c1b09749420ed0682a2e49fbbd759741e5/src/ripple/protocol/digest.h#L121:L180 (Which uses what I would assume to be equivalent implementations.) So, indeed looks like you SHA256 the public key, then RIPDEMD160 it. Maybe test your hashing code with known inputs and results for both the SHA256 and the RIPEMD160? Then you can narrow down if its your code, or what you're supplying to i
  5. If a submitted transaction consumed a fee, it will appear on the ledger regardless of whether the transaction actually succeeded or failed to achieve its intended result. Note that a response of "tesSUCCESS" means the transaction was successfully *submitted*. It does not mean it was successfully *applied* or that it can be expected to necessarily appear in any ledger, ever. The answer to your questions may be to search for all transactions from the account in question. Eg, with the data API: https://data.ripple.com/v2/accounts/r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59/balance_changes?descending
  6. Maybe ls -lR /tmp/full_history_dmp/ and post here - maybe something will stick out as off, or if not, at least that aspect could be ruled out.
  7. Maybe I'm reaching beyond the limits of my knowledge. As I understand it - if you start with 128-bits, then for all practical purposes, all you have at the end - in terms of your security - are those same 128-bits? In other words, as a user of the system, is there any necessity to make a discernment between the seed and the key? And if so, why introduce a new term to describe what's effectively the same thing? (I could understand why for development, but this is user-facing.)
  8. I think this is a great idea for the benefit of the future masses - at least if it's optional, mitigating the disadvantage to those used to the "s..." version. I am curious how you've implemented the check digit in your mechanism? The common schemes I know of didn't work when I did them in my head (but maybe that's because of my head...). I use the term "secret" to refer only to the base58-encoded, "s"-prefixed and checksummed version of the "seed", which I think of as just an ordinary number with no prefix or checksum. I have wondered why the well-established "private key" was not the t
  9. Great that you've done this. I don't know much (anything) about Ruby, but in general when implementing such things, watch out for how the system might fallback on some other source of randomness in the case the intended source isn't available. This could result in something less than secure and as such may be important to understand how differing systems running the same code can serve different (but still "valid") results. On from there, for the secret_seed --> secret_human_readable part, there's a roughly-parallel node.js implementation, here.
  10. Yes, that's another side of this. I mean to suggest that the metric of on-exchange XRP versus off-exchange - when taken alone - is not necessarily indicative of anything, unless paired with other figures backing up whatever claim is being made.
  11. XRP being moved to exchanges is an interesting metric to check, but it could be a predictor of selling action as much as be representative of supply purchases. It might be useful to connect this information with flow from known XRP II accounts to more feasibly determine the latter, but even then: Given the low trading volumes on the XRP Ledger presently, what you're looking at could be also seen as indicative of how much XRP the market wants to hold on exchanges versus in "cold storage". In that sense, an argument could be made that its a stronger positive signal in terms of price to see
  12. This looks like mainly a charting bug/data API bug. The historical data API is known to be buggy, but this has nothing to do with the integrity of the data on the XRP Ledger itself. When I checked more directly the amount of actual ledger closes for the past 24 hours, versus a control of a 24 hours period about one month ago - they were about the same. I also checked the past 2.5 hours versus a 2.5 hour period a month ago, same again. What I am noticing is a variation in the pattern in which ledgers are closing. The network appears to close a handful of ledgers every second or so, and t
  13. Given the amount of caveats and the lengths I needed to take to describe them, I somewhat agree with the negative assessments. Though I still find it interesting that the Top 100 by this metric shows 90% of all of the ex and current Ripple employees that I am aware have ever used the board. That they reliably cluster together at the very top when ordering by RPP makes me disagree that it's useless. Moving the cut-off point to a higher reputation (~700, arrived at by limiting to the first ten pages of results), the list is still populated with many ex and current Ripple employees. In that
  14. When reading through the forum, I often unconsciously divide a members Reputation by their Posts in my head, to get a feeling for how their contributions are percieved by other members. A higher ratio of Reactions Per Posts ("RPP" ;) ) shows that more people may be willing to demonstrate they value those members contributions. I find it interesting, but also useful. I might not read a long post by a member I don't recognise if they have a terribly low ratio, for instance. Perhaps others do something like this too? Recently, when @BobWay joined, I noticed that his RPP climbed very (x)r
  15. Well, what's your reward for asking the question? My take on summarising the answers already given: 1) It's interesting, fun and/or feels good. There is no comparable, sufficiently-utilised open ledger in existence that doesn't also destroy the environment. That's cool! 2) Running a node gets you fast and reliable access to the ledger and information on it. This can also *save* you money if you regularly query the ledger, as you can locally query stored data as much as you want without cost. If you are relying on others servers, you may be paying high fees in data every month to sat
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.