Jump to content


  • Content Count

  • Joined

  • Last visited

1 Follower

About jargoman

  • Rank

Recent Profile Visitors

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

  1. there's two ripple's now. ripple > xrapid r3 > corda
  2. Mine has three interfaces for trading The depth chart The orderbook or the bot ui If these guys want to work together I'm down. edit* there is actually more interfaces for trading if you want to input the trades manually. Ihilda is about automation though
  3. I too am looking into creating a crypto based operating system. Possible base operating system candidates are debian/ubuntu/mint/, arch/manjaro or hardened bsd. I used to create my own distro called yahd. Arch linux with the zen-kernel. These guys seem to be making a command line environment. I'm talking full GUI. They might make a distributed exchange but I've already built one and it can run automatically and makes money automatically. It can run in command line mode if you want but in that mode only the bot runs. They might make a live image but mine will be better
  4. I read this again. You should save your secret key from within toast wallet. ANY software wallet is not a storage facility. It's a convenience wallet and it should be encrypted but you should have the secret key backed up. Software wallets can corrupt your wallet file, especially if it's encrypted. If the computer is saving to a file and the power goes out or the drive gets disconnected the file can be saved as blank or corrupted. There is no fix for this other than having your wallets backed up in a non corruptible form such as paper or wood or metal engraving. If you can't retrieve your secret see about setting a regular key for the account and backing that up. You'd have two keys. The master key on toast and the regular key you backed up.
  5. why do none of you guys save your secret key that's all you need.
  6. It's not something that is implemented server side. The user sets their regular key. If you reset their regular key. You'd have the key and they wouldn't.
  7. You can prevent replay attacks by setting a different regular key on each network. You'd only have to worry about the set regular key transactions being replayed. Replay attacks ARE possible. LastLedgerSequence was designed to stop an attacker from withholding a valid tx until it becomes profitable for them to submit it. Example a validator withholding a tx until it can be arbitraged against. People who sign tx's offline would sign a tx that would be valid later. So they would either not set a lastledger or they would set one that is farther in the future. I agree that replay attacks may be harder in practice but an attacker has public access to all the transactions submitted. A script could sniff and collect all susceptible transactions. Only accounts that were forked would be susceptible new accounts could have their tx's replayed but the systemd account would be unfunded.
  8. Yes you are right I saw all the numbers were exactly the same except the 11 turned to a 12. Weird it was exactly one month later
  9. 24 is 12 + 12. Are you sure you don't have two wallets bittrex > first 12 words = rMmfcWJ7WSGQugYX7iNaaeYcPvUGjYFXh2 20xrp second 12 words = rsbGAp8MhKaftdM8LGL4mSGmh9Hp2u3vXZ 18 384.39 XRP It really seems like you received 18384.39 to one wallet and sent it to another the next day. BOTH keys work in BOTH wallets. Put the other 12 words in and you'll find your xrp
  10. Either the second tx sequence wasn't the last sequence + 1 or the first tx you submitted wasn't included in a ledger before you submitted the second. all the validators must agree before your tx is approved. The server might be under heavy load. Usually you can fire off 4 - 5 transaction without a hitch before the fee escalates causing lag. Your transactions can be in limbo until either The lastledgersequence you specified is reached causing the order to expire before being validated or the fee drops below the fee you specified and all validators include it in a ledger. note lastledgersequence and a transactions sequence are two completely different things
  11. sudo pacman -Syu sudo pacman -S gtk-sharp-2 wget https://github.com/jargoman/ihilda_community_editon_alpha/raw/master/ihilda_community_edition/Binaries/ihilda-bin-1.0.2-1-any.pkg.tar.xz sudo pacman -U ./ihilda-bin-1.0.2-1-any.pkg.tar.xz see also
  12. It's up to you if you use a 3rd party binary but this is the step by step process that I created.
  13. VERY IMPORTANT THE FOLLOWING FEATURE CAN RENDER AN ACCOUNT BRICKED FUNDS CAN BE LOST FOR ALL TIME MAKE SURE YOU UNDERSTAND WHAT YOU ARE DOING AND YOU HAVE BACKED UP YOUR KEY a transaction created with the following configuration as shown will disable the accounts master key disabled
  • Create New...