rippled Version 0.60.2

The rippled team has released rippled version 0.60.2, which further strengthens handling of cases associated with a previously patched exploit, in which NoRipple flags were being bypassed by using offers. Ripple requires upgrading to rippled version 0.60.2 immediately. There are no new features in the 0.60.2 release. Note: This does not affect XRP transactions. Ripple … Continued

The post rippled Version 0.60.2 appeared first on Ripple.

MUFG Joins Ripple’s Global Payments Steering Group

MUFG’s banking arm The Bank of Tokyo-Mitsubishi UFJ (BTMU), the third largest bank in the world and largest bank in Japan, publicly announced today that it is joining Ripple’s Global Payments Steering Group (GPSG). As the first Japanese bank joining GPSG, MUFG will join Bank of America Merrill Lynch, Santander, Standard Chartered, Westpac Banking Corporation, … Continued

The post MUFG Joins Ripple’s Global Payments Steering Group appeared first on Ripple.

rippled Version 0.60.1

The rippled team has released rippled version 0.60.1, which corrects a technical flaw that resulted from using 32-bit space identifiers instead of the protocol-defined 16-bit values for Escrow and Payment Channel ledger entries. rippled version 0.60.1 also fixes a problem where the WebSocket timeout timer would not be cancelled when certain errors occurred during subscription … Continued

The post rippled Version 0.60.1 appeared first on Ripple.

Escrow, PayChan, and fix1368 Will Be Available in 3 Days

A majority of rippled validators voted to enable the Escrow, PayChan, and fix1368 Amendments, which are scheduled to become enabled on the network on Thursday, 2017-03-30. Escrow (previously called SusPay), designed for low volume, high value transactions, permits users to cryptographically escrow XRP on RCL with an expiration date using a hashlock crypto-condition. PayChan, designed … Continued

The post Escrow, PayChan, and fix1368 Will Be Available in 3 Days appeared first on Ripple.

Provable Solvency Report #36 – March 2017

Coinfloor is a custodian of client bitcoins and we believe that we must set the industry standard for transparency and regular audits. Without proper public accountability, the industry will not be able to grow and mature. This is why we are committed to releasing a Provable Solvency Report every month. Coinfloor is proud to have the longest standing track record among bitcoin exchanges in regards to auditing.

Today we are publishing our 36th monthly Provable Solvency Report with step-by-step validation instructions for your convenience.

As of today, Coinfloor holds a total of 7,825.2923 XBT on behalf of our clients. You are invited to verify that your held bitcoins are included in this balance by following the instructions below.

What does the Provable Solvency Report include?

We started out by creating an obfuscated report of all current client balances (the Solvency Report) and then generated a SHA-256 hash of this report.

We then created a bitcoin transaction to ourselves, that includes all currently held client bitcoins, for a value of 8,174.3882 XBT and included in the output script the OP_RETURN of the SHA-256 hash of the report, proving that at the time of making the solvency report, Coinfloor held all of our clients’ XBT funds. You can verify the amount and details of the transaction on the blockchain.

Key Pieces of information:

Provable Solvency Report #36 (March 22, 2017):

SHA-256 Hash of the Provable Solvency Report: ec8279bf42aa915ee43378587e53eec6c864e0d65260669f54d4bec7223e5629

Transaction ID: 2f3ce9d2a1a891abc3338c46bf6ba082424aaa6ac72e2a6ef7e9db8115064063

View the transaction here:

Your API authentication cookie:
You will find it in My Account > Dashboard in the Coinfloor signed in view, in the API section (visible only for fully verified accounts).

Where is my cookie?!

Instructions for Validating Solvency Report:

      1. Open the Provable Solvency Report file:

      2. Go to or to your SHA256sum calculating application.

      Copy the entire contents of the solvency report into the SHA-256 generator and calculate the SHA-256 hash of the report.
      3. Go to

      At the bottom of the page, in the Output Scripts section, you will find the generated hash in the OP_RETURN output script of the transaction that includes all customer bitcoins.
      4. Go to

your local SHA1sum application

      to calculate the SHA-1 digest of a message consisting of the timestamp shown at the top of the Solvency Report (1490191092) and your API authentication cookie.
      Example (Linux):
                timestamp: 1490191092
                API authentication cookie (API Key): 9BTa7M0Z/Mrk6tFMJwEkTV3BQek=
                command: echo -n ‘14901910929BTa7M0Z/Mrk6tFMJwEkTV3BQek=’ | sha1sum
      5. Find the resulting hash in the solvency report. Your balance is shown on that line in satoshi units. 1 bitcoin = 100 000 000 satoshis. For your convenience, here is a link to a bitcoin unit converter:

We believe that this approach is the best way to achieve maximum accountability while retaining privacy for our clients. We welcome your feedback and hope that in time, other exchanges will also help safeguard client funds by providing proof of solvency reports to their users on regular basis.

Thank you for your trust,

Coinfloor Team