Jump to content

SimpleXRPTools

Member
  • Content Count

    23
  • Joined

  • Last visited

About SimpleXRPTools

  • Rank
    Regular

Contact Methods

  • Website URL
    https://github.com/SimpleXRPTools/SimpleXRPTools
  1. Sorry that I can't help you with your specific problem, but I just noticed that you've set maxLedgerVersionOffset: 5 to represent ~5 minutes but according to https://xrpl.org/send-xrp.html#2-prepare-transaction it should be set to 75. It probably makes no difference if you're immediately submitting the transaction, but if you're moving a prepared transaction to an offline device and then back to a online device for submission you're probably going to have the transaction fail. This is because, while you're transferring transactions around, the 'Ledger Version Number' would've already progressed past the 'Current Ledger Version Number ' PLUS the maxLedgerVersionOffset. If you use 5 for the maxLedgerVersionOffset it only gives you ~20 seconds to submit the transaction from the time you prepared it. Admittedly, this isn't very helpful advice right now, but it might prevent some confusion later on. Good luck.
  2. You can prepare simple XRP transactions via my SimpleXRPTools, no Node.js required: https://github.com/SimpleXRPTools/SimpleXRPTools Download the whole project and open the html files with an up-to-date Google or Firefox browser. There's some guidance included about what steps should be online or offline. You can't submit code/transactions offline, you prepare them online first then move them to an offline device, sign them with your XRP Secret/Seed, then submit the signed transaction online. If you're into Node.js, Wietse Wind has a beginners tutorial you can follow to get started: https://coil.com/p/wietse/Coding-the-XRP-ledger-A-beginners-course-/kKu7G0Hhq
  3. Hmmm. I went to change the wording in my SimpleXRPTools and realised that hardly anyone will know what an 'XRP Seed' actually is. I'll stick with 'Secret' or 'XRP Secret' for the sake of people who aren't interested in getting bogged down in the details. Bah! You can't really win with this problem.
  4. That might be true, but I don't have any experience in Python and Ripple don't have an official Python library. I'm pretty sure it is pretty complex, but feel free to have a go at it. Also, it's not usually advisable to reinvent the wheel rather than use a well maintained and tested library. Especially when there could be actual money/XRPs at stake. It's only a better way if you don't want a GUI, the beauty of using a browser is that it's almost universally available. I'm trying to hit a sweet spot between ease of code checking and ease of use. You really need to have more than cursory glance before you come up with a list of faults. The rest of your points were already taken into consideration in my code.
  5. Yeah, that was push I needed to make it officially 'Open Source' rather than just code that is freely available. Thanks.
  6. Ah crap. I see what you're saying now. It doesn't entirely remove the disincentive for ordinary people/organisations to create unnecessary accounts but it does make it cheaper for a dedicated spammer to spam the network. Thanks, I'll add it to the CONS in the first post.
  7. Rather than sending more XRP to your account AND THEN recharging and paying for the transaction fee from the general balance, it could be setup so that you can send XRP directly to the Reserve. Sort of like using a Destination Tag. A Reserve Tag if you will. But it would be a boolean check box rather than a number. If checked, send the whole payment to the Reserve.
  8. I'd just say that it's usually better to fix problems at their source rather than rely on people outside of your control or influence. You could request UX designers and builders to subtract the Reserve from the Balance to achieve the same result but it could take years for the changes to filter through. Bitcoin with the integration of Segwit is a good example of that. Also, you'd create unnecessary confusion when your balance from an XRPL explorer didn't match with your software/hardware wallet. I'd say it's an all or nothing type of deal. You do a hard fork (an Ammendment: https://xrpl.org/amendments.html), or just forget about it.
  9. A new transaction type would need to be created specifically for recharging the Reserve. EDIT: Whoops. I see what you're saying. You'd need to send more XRP to your account and then transfer it to the Reserve. EDIT 2: @Tinyaccount has the right idea. The general account balance could be used to fund the transaction.
  10. OK, so I may have overstated my love of integers. It was really meant to be an example of how transactions can create balances that become difficult to reconcile via the human eye rather than a wish that all transactions would end up with integer balances. For example, if I have a current balance of 100 and send 50 somewhere else, my new balance is 49.999988 (assuming a transaction fee of 0.000012). Now, if I was drunk and accidentally sent 50.1 instead of 50 the new balance would be 49.899988. In my drunken state, I'm just not gonna pick up the error, probably not even when sober. Joking aside, if my suggestions were implemented it would immediately be obvious there had been a mistake because the balance should be 50. Obviously this isn't going to help much if your starting balance is 100.937383 and you need to send 50.873649. I suppose theses suggestions are slightly philosophical in nature as opposed to fixing obvious problems. We should always strive to make systems as intuitive as possible. For simplicity's sake, I'd say the transaction should fail if the reserve runs dry.
  11. That's a good point. Here's a possible solution. Allow the Reserve to be recharged to any amount you wish. Not just 20. In cases of mistaken recharges, allow the Reserve to be transferred back to the available XRP balance EXCEPT for 20 XRP. For example, someone might need 200 XRP in their Reserve to cover their expected transactions but accidentally add 2000. They'd be able to transfer the extra XRP back as long as there were 20 XRP still remaining in the Reserve.
  12. The 20 XRP would still be required to activate an account and a fee is still required to submit a transaction. I don't think these changes would affect spam prevention in any way.
  13. All the code is right there, why don't you consider it 'Open Source'? It's not needless. I've tested my code to work with those specific versions of those libraries. I can't possibly know what bugs or changes will occur in future versions. Also, their source, their CHECKSUM details, and encouragements to check for yourself are right there in the code comments. If there's a better way to do it, I'm all ears.
  14. Reserve not included in the XRP balance. It's really unintuitive to have the reserve included in the XRP balance when it's not actually usable. PROS: Intuitive. CONS: Easier said than done. In addition, Transaction Fees to be taken from the Reserve. PROS: It would allow accounts to be much more easily read and audited (at least from a human's perspective). A lot of transactions become awkward when you need to take the transaction fee into account. Nice, clean, integer amounts become unwieldy. e.g.100 XRP - 20 XRP - 0.000012 XRP FEE = 79.999988 XRP vs 80 XRP - 20 XRP = 60 XRP (and a hidden reserve balance of 19.999988). Since transaction fees are so low, the average user will never need to worry about their transaction fee ever again. At today's fee of 0.000012, your 20 XRP reserve would be enough for 1,666,666 transactions. Even if the fee increases you're still unlikely to run out unless you're a large organisation. Takes a little of shine off of the DAG coins (e.g. Nano). Wallet software designed for public use could probably get away with hiding the fee section of the transaction altogether. Feeless might be best, but so-cheap-and-easy-that-no-reasonable-person-would-care, is not far behind. FROM USER @Khaleesi: there would be less complaints about the Reserve being lost value. CONS: Again, easier said than done. I don't really know for sure, but I assume this would be a major change to the XRPL, requiring a huge effort to pull off. It would also need a new transaction type for recharging the reserve when it runs out. FROM USER @Dario_o : It makes it cheaper for a dedicated spammer to spam the network. Since they were going to pay the 20 XRP in fees anyway, they essentially get the account for free. EDIT: I think these changes are objectively better than the status quo but it's probably far too late in the game to be making complicated changes like this.
  15. I'm really late to the party on this one but here's some tools for doing what you want. As a bonus, no Node.js is required, just download the whole project and open the html files in an up-to-date Chrome of Firefox browser. https://github.com/SimpleXRPTools/SimpleXRPTools
×
×
  • Create New...