Jump to content


Platinum Member
  • Content Count

  • Joined

  • Last visited

  1. 2 signatures with the same nonce and you have the private key in fractions of a second. The only "hard" part is going through all signatures that were made so far (the researchers in that report only tested a subset of all transactions on XRPL), which can be probably done for a few cents using the transaction dataset on Google BigData.
  2. You'd just need to re-key the accounts and disable the master keys. That costs you a few hundred drops, not a few hundred XRP.
  3. You could look for the nonce used and if it is your transaction you could check if it is the deterministic one according to RFC 6979 (since you need the private key for that) or just a random number.
  4. It would be a bit faster to look up objects and a bit less disk used to store them, but to get hard numbers you'd need to do benchmarks. Switching to the new system (especially if you want to deprecate and completely remove the current one over time) would likely be a large task in itself, as Rome already said. A "clean slate" approach where a ledger state from the current ledger is used as genesis ledger for a "XRPLv2" chain would be an option, but also has its issues. It depends on the implementation in detail though, it could maybe be done in a way that only validators need to switch initially, and they shouldn't have much history to begin with. Still SHAMapv2 would change root hash calculations and thus influence the block headers and thus need to be understood and adopted by all servers in the network.
  5. They get paid to do this stuff by companies before they take a deeper look, they don't just randomly attack servers on the internet. At least the ones that want to stay out of trouble and in business. Alternatively they work for a large organization that protects them somewhat (universities, companies) and they get paid to do this stuff by their employer.
  6. Yeah, the US government is not first on the list at all of who I'd trust to fix a 0-day... You don't earn "fame" or money, but you maybe get to stay out of prison because you likely violated several laws at this point. I'd still expect to get raided, so make sure that you have off-site back-ups of your data in case you are working in IT and need working computers to actually earn your living - because it is not unlikely that you'll no longer be in possession of the ones you currently have. It is far more likely to stumble upon a badly written webshop or a forum leaking user data than a state sponsored attack.
  7. Depends a lot on your jurisdiction. In any case: STOP THE ATTACK IMMEDIATELY. Depending on the impact, I'd either stay silent about the whole thing or contact the CERT of country where this website/system is hosted or operating from, if necessary via anonymous mail. You'll get better (but also more expensive) advice from a lawyer or interest group (e.g. the CCC).
  8. Sukrim

    Ripple Network forked to create SystemD

    https://developers.ripple.com/transaction-common-fields.html - LastLedgerSequence (Optional; strongly recommended) Not every transactions sets this. Attacks the other way around would be also possible, replaying a transaction on "SystemD" on XRPL. Not implementing replay protection in any way is not very user friendly at all. Since you haven't answered ANY of my questions yet, I'm going to assume that the entire reason of your project to exist is to collect BTC into your own pockets (which will be hard in the current climate of post-ICO depression). If you really want to start an alternative network, I'd recommend to start from genesis and implement an ILP connector, maybe offering something like a bridge between the two networks. Would be much easier for you and your users too. Also I don't see the point in forking rippled, just to rename a few things here and there, especially if you want to actively contribute to the development of the protocol and offering scalability solutions.
  9. Sukrim

    Ripple Network forked to create SystemD

    @VokezWhy do you add go-ipfs to your Docker container and why do you use Boost 1.67, not 1.68 or 69? Why a debug.nounity build with clang? Why these weird paths in a Ubuntu based system (/etc/opt)?
  10. Sukrim

    Ripple Network forked to create SystemD

    No. History sharding is similar, but storing history (maybe optionally or in addition to sharding) in a DHT could have its own benefits and downsides. If only these "SystemD-rippled" nodes have this enabled, it would mean that they need to store a few TB of data on a few nodes, probably redundantly depending on their churn estimations. If they manage to get it onto all ~1000 rippled nodes, then there's still quite a lot of local storage used for the DHT data, but it would start approaching manageable levels.
  11. Sukrim

    Ripple Network forked to create SystemD

    Awesome idea, where's the code for that? It might make sense to integrate your functionality in rippled upstream and ask for more generalized support for competing chains (e.g. similar to how rippled by default has configs for testnet and mainnet). Similar to how clients like https://github.com/paritytech/parity-ethereum work. Maintaining a fork of a large code base is hard, especially if you are currently just changing configuration files.
  12. You can also rewrite the relevant parts (for a vanity address "mining" script: key derivation and address encoding) in C or Rust and call these from Python or use PyPy or Cython for some easier performance gains...
  13. Maybe your python script is badly written?
  14. Sukrim


    Because that user wanted to do that.
  15. There's https://github.com/arsenlosenko/python-ripple-lib, I'm not sure if they implemented keypair generation already. Shouldn't be too hard to do, just generate a seed, derive a keypair from it and encode the hash of the public key in base58 with checksum and a custom alphabet to get the address. Make sure to use good(!) entropy when generating the seed.