Jump to content

Professor Hantzen

  • Content count

  • Joined

  • Last visited

  • Days Won


Professor Hantzen last won the day on February 22 2017

Professor Hantzen had the most liked content!

About Professor Hantzen

  • Rank
    Advanced Member

Contact Methods

  • Website URL

Profile Information

  • Gender
  1. @corak Nice work! I noticed this "r...ok" account too, and my conclusion was also its an exchange. 6k+ accounts is a pretty big (likely non-recoupable) investment in terms of account reserves, anyone would have to get a payback for that investment and the most straightforward would be satisfying customers with wallet. I'm sure it should be possible to figure out where such a large cache came from. This may be of use (source: reddit): https://docs.google.com/spreadsheets/d/17_Wgo4iwGoPB1JenxD5fHtJ0HQYLpb669zaNemPojG4/edit#gid=0
  2. Exact nature of an XRP

    Not disagreeing with the assessments here or your intuitions about XRP. Just pointing out that technically XRP doesn't 1:1 correspond to a recorded ledger value. And totally agree with this!
  3. Exact nature of an XRP

    Actually, an XRP is an abstraction invented to make the real stored numbers easier to deal with. The actual amount recorded in the ledger is called a "drop". A drop is one millionth of one XRP. Ie, as it takes one hundred cents to make a dollar, it takes 1 million drops to make an XRP. As a programmer, if you query the XRP Ledger directly for an account for the first time, and you don't know about this, you may get a surprise, as the value showing in the account will be 1,000,000x greater than you thought it should be. Eg, 1) Try this example query. This site queries the ledger directly and reports the amount actually stored on the ledger and associated with an account. Click "Send Request" and then read the "Balance" amount. It will say something like 13 billion (at the time of writing). 2) Then try a similar query of the same account using a different source of information. This site queries the ledger directly and then divides the amount it receives by 1,000,000. It shows that divided result as "XRP". "Zerp" is just what some xrpchat forum members a while back decided would be (by a process of consensus...) an alternate pronunciation of "XRP".
  4. Cryptos not fully mainstream

    @tulo Nice perspective! And I would agree at least from my experience in Europe. I wonder if in some parts of Asia the wave has already happened. Eg, much of the volume across crypto this past year has been coming from Korea, and to a lesser extent, Japan has an all girl band dedicated to cryptocurrencies - though that may just be an opportunistic blip.
  5. XRPtoolkit

    Also, the Ethereum Foundation fixed this issue.
  6. They're just SAP-branded fidget spinners. I actually can't see any evidence of Ripple anywhere in these pictures? But I'm sure it'd be great if true - SAP is huge.
  7. Personal Validator / Server

    @theGlitchKing Welcome! This video by 3Blue1Brown is the clearest overview of blockchain architecture I've seen. It doesn't all apply exactly to Ripple, but much of what's presented is analogous or otherwise related. This plus his other video on sha256 forms a pretty solid ground. As to server costs - Digital Ocean is the most competitive I've found for setting up a rippled server. At the moment you could operate a full-history node for under $1000/month total including the SSD's for nudb. It's also much easier to use and configure than AWS, and you could very easily resize your SSD's on the fly as you populate to keep the cost down initially. Obviously the price for running at full history would continue to increase as more ledgers are added to the db, maybe you could go for the next three months at under $1000. It may even out somewhat as SSD's continue to drop in price and cloud providers reflect that in their price - though you pay for the lag. Then again increased usage of the ledger could see an increase in the size of ledgers added to the DB daily that could outweigh any of that (perhaps ultimately significantly...). I've wondered if it may be more cost-efficient to simply buy your own hardware and add SSD's at the market price as required.
  8. Tool for transaction in a ledger

    Set expand to true and sort the returned list by [tx].metaData.TransactionIndex.
  9. How do you buy large quantities of XRP?

    The maximum trading fee for an exchange is usually around ~0.2%. There are also minimal deposit fees available if you look around, you just need to be sure that the currency you are sending is the one the exchange is set up to "natively" receive in terms of its fiat-banking setup. Any confusion around this - ask the exchange. Eg, there is no fee for depositing EUR via SEPA to Bitstamp or Kraken, other than the 9 EUR cents that your sending bank will charge you. So if you have SEPA-zone bank account (meaning a European bank account), the most you should pay is 9 cents + the minimal standard trading fee of around 0.2%. If you need to start with USD, you can do this using Kraken, but not Bitstamp (if you use Bitstamp for USD you'll pay a huge conversion fee to an intermediary bank). Sending USD from a USD bank account to Kraken should ordinarily be the cost of a SWIFT transaction - around $25 (and may take 3-5 days). So the total cost for USD bank account --> Kraken XRP should be only ~USD$25 + a 0.25% fee. At current prices that's only a total cost of around 0.3%. Unfortunately, they're about to disable this in a couple of weeks - but if you hunt around, I'm sure you can find another exchange that accepts USD-native deposits without charging a huge fee. After your EUR or USD has arrived in your trading account, use the corresponding trading pair (XRP/EUR, or XRP/USD) to buy XRP directly. Its then just a simple case of metering out your trades into smaller parcels to keep them at the market rate. In the case of buying 50,000 for example, look at the leading asks that are close to market rate on the exchange, are they >50,000 XRP? If so, you're good to go. If not, say they're 10,000 - match that size for your first trade, and wait for the market to recover before trading again. It's best to use limit orders, even if you intend to buy at the market rate - market orders have the potential to fleece you if the market shifts in the moment you place the order, and yet provide no additional benefit over making a limit order that's priced a percent or so into the market rate. (Personally, I think market orders should not be offered by exchanges and they should instead adopt a percentage-based limit order system. Further, not many people realise that stop-loss orders are *always* market orders - if you want to *lose* money, place stop-loss orders, they were invented primarily to rob you during a "flash-crash", where the market blips down due to a large sell, and then immediately recovers, leaving you with a market order that was likely filled at the worst possible rate and with nothing you can do about it.) Anyway, I see little reason to pay anything like 5% to buy XRP, definitely when starting with EUR, and it should continue to be possible with USD. If starting with some other currency, there may well be an exchange that handles it natively, have a look. One final note - anyone paying 5% is not doing so because of exchanges or the market. It's because of intermediary banks charging exorbitant fiat-currency conversion fees. This is well-known and is as they have always done. If you don't want to pay the premium, don't let them convert anything for you, summarised as: TL;DR - Set up your trading accounts with exchanges that can handle your fiat deposits as their native currency, and look for exchanges that don't charge you for making them.
  10. Balance on a specific date

    Select and copy/paste the following link into your browser, but don't hit "return" yet: https://data.ripple.com/v2/accounts/rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn/balance_changes?start=2018-01-01T00:00:00Z Replace the "rf1Bi...Jpn" part with your account number. Now hit return. The result will be a bit of a mess (its in "JSON format" - download a "JSON viewer" browser extension to make it a bit more readable). The link should return a list of transactions that occurred affecting your account from the date specified (year-month-day), with most recent at the top. Specifically, if you look at the number to the right of the "final_balance", that will show the balance at the "executed_time" of a particular "currency".
  11. Trade Simulation for Those Interested.

    Wow, this is all seriously epic. Thanks!
  12. IMO its one - if not the only - clear architectural failure of the system. That said, if it's the only major unforeseen shortfall they've done really well. Coming up with solutions for it are hard, you rapidly approach some kind of spaghetti of consequence, though I have a feeling imposing account activation refusals based on activation rates could be employed somehow.
  13. Harbor Wallet 1.0.7 Release

    I hear what you're saying too, and I appreciate your open dialogue around this. Respectfully, I must say - if the basic tenets of blockchain and cryptocurrencies need to be violated in order to support your business model, its your business model that needs work. And honestly, and with no other agenda - I think you're fighting a losing battle with your present approach. Your posts will likely continue to be met with suspicion if not outright hostility from educated members. A better solution may be to come up with something unique you can add to the space, that requires or naturally compels a user to contribute. Off the top of my head: - You're providing your own server for processing transactions and this is potentially valuable to others, and costs you money. A pre-signed transaction cannot be tampered with, so here lies what could be a good fit for a way to add value without compromising user security. Offer your (open source) wallet for free and use it against Ripple's public servers. Require a purchasable,/subscription key in order to use your wallet with your own servers, for greater reliability and transaction speed. If the code is open, and verifiably conducts signing client side prior to submission, its of little consequence if your servers are then compromised. (Maybe some opportunity cost in the case of trades, but funds would not be compromised.) Further, any user who wishes to have a more reliable form of transaction submission, regardless of what wallet they're using, may choose to pay to use yours assuming it holds positive repute. - Post feature suggestions, and allow users to make them, along with a donation address. When a given amount is reached, add those features. There are a lot of (suddenly) wealthy people in this space, and some are dying for particular features to be included in a wallet *mostly issues around security* - its possible some may be willing to pay for this. It goes without saying the need to see the code in these cases. But also - part of such a relationship is they typically also want to like and respect you - open sourcing, aside from allaying security concerns, engenders this aspect of the relationship. - If you've built up enough knowledge of the Ripple system, consult! If you've authored code that is publicly verifiable and well-known - you will find people and companies come to you, regularly, requesting consultation. Open source software isn't just "giving something away for free', its a giant advertisement of your skills and knowledge, and Ripple is very much a niche market. You could honestly make a killing if you wanted to - but at the moment, nobody has any way of knowing if you can actually code, or if - for example - you've just taken one of the other open source wallets, modified it a little and published that claiming its your own. This isn't an accusation, its simply intended as an example of how closed source may have drawbacks you haven't considered. As @Sukrim said, it all boils down to we have to trust you. But we don't trust you. We also don't trust banks or the people who wrote their software. That's really the most basic and essential reason all of this exists...
  14. Harbor Wallet 1.0.7 Release

    Your policy does reflect the standard in legacy software development, particularly as you say, for financial software. This serves to illustrate the final point I made: I think you, as developers, may have missed the core value proposition of cryptocurrency and blockchain in general. The old systems are broken, because they rely on centralised trust. The only thing any of your users have to protect their *previously-protected-by-the-system* funds is your statement that you won't steal them. The new solutions we are collectively building together, including Ripple, Ethereum etc, are designed to *replace or augment* the existing infrastructure which is clearly lacking in precisely this regard. The main "additions" being made to the existing systems are the various benefits of transparent source code and decentralisation and the security and resilience these offer specifically over the existing systems such as online banking platforms or e*trade etc. Ripple's code is all online. Ethereum's too. Almost all wallet software for both platforms and just about any blockchain project is open and available online and always has been. (iPhone is somewhat of a special case as software on that platform operates within a tightly-controlled "walled-garden" operated by a company that has established a large amount of trust, and audits all of its own code before publishing.) There are in fact several trading platforms that are also open-source, but as this is a new field they are somewhat "cutting-edge" (aka, crap) - it remains to be seen, but is somewhat likely that decentralised trading systems will eventually disrupt the existing closed solutions once they reach maturity, which is some ways off (give them a year or two). I wholly disagree with your final point. When entering a market dominated if not characterised by open-source software, where your target demographic of blockchain enthusiasts largely expect your software to be open-source, and even if they don't expect it is arguable they still require it (as the converse negates the primary value proposition of blockchain system they are choosing to adopt in the first place), and where every single one of your direct competitors has open-sourced their wallet software, one could argue the converse of your statement: In order to protect your investment, you may need to open-source your code. For example, given that just about everyone influential in this space is a strong advocate and proponent of open source software, and may further actively discourage the use of closed source wallet software for reasons of security and negating the primary benefits of blockchains and cryptocurrency in general, if you are to win over said influential personalities in this space to promote your software and sing its praises, and to prevent those same from discouraging its use, you would very likely need to open your codebase. Place as restrictive a license on its subsequent usage as you see fit, but make it publicly available and auditable, or IMO it is unlikely to gain traction, and you are likely therefore to lose your investment as users understandably will prefer open alternatives. Further, given that many open source alternatives already exist for building XRP wallet software, while you have much to gain, I don't particularly see how you have anything to lose by opening your source code - as anyone wanting to acquire external source to build their own wallet is already readily able to do so.