Upgrade Range Proofs to Bulletproofs+

Development and Technical Discussion
1

Why we dont upgrade and implement Bulletproofs+ as a replacement for the current Bulletproofs system in Grin?. This would require a consensus hard fork, but delivers concrete, measurable improvements to proof size, verification speed, and chain growth and with minimal protocol complexity increase.

A standard Grin transaction with 1 input and 2 outputs is roughly 1,600 bytes. Of that, the two Bulletproof range proofs (~675 bytes each) account for 84% of the transaction size. Range proof verification is also the most CPU-expensive operation during sync and roughly 235x slower than a signature verification on the same hardware.

This means range proof efficiency is the single highest-leverage optimization target in the entire protocol. Even modest improvements compound significantly over time.

Bulletproofs+ improves on the original Bulletproofs in three measurable ways:

1. Smaller proofs: 96 bytes saved per proof, every proof, forever

| Outputs per tx | Current BP (bytes) | BP+ (bytes) | Savings |

|—|—|—|—|

| 1 | ~674 | ~576 | 96 bytes (14.3%) |

| 2 | ~738 | ~642 | 96 bytes (13.0%) |

| 4 | ~804 | ~708 | 96 bytes (11.9%) |

| 16 | ~936 | ~840 | 96 bytes (10.3%) |

The 96-byte reduction is constant regardless of aggregation. For a typical 2-output transaction, total transaction size drops from ~1,600 bytes to ~1,408 bytes , a 12% reduction in transaction size.

Projected chain savings assuming current network activity (~60 tx/block):

  • ~16.9 MB/day less chain growth

  • ~6.2 GB/year less storage

  • Every unspent output in the UTXO set carries its proof, so the savings compound

2. Faster verification

Based on Monero’s production benchmarks and Tari’s audited Rust implementation:

  • Single proof verification: ~15-17% faster

  • Proof generation (2-output, most common): ~10% faster

  • Batch verification: comparable or slightly better than current BP

For initial block download and ongoing sync, this directly translates to reduced sync time. Combined with PIBD, the new-node experience improves meaningfully.

Bulletproofs+ preserves all the properties we rely on:

  • No trusted setup (transparent)

  • Based on the discrete log assumption (same as current BP)

  • Supports aggregated range proofs

  • Supports batch verification

  • Non-interactive (Fiat-Shamir)

  • Compatible with Pedersen commitments on secp256k1

This is not experimental cryptography. Bulletproofs+ has been:

  • Deployed in Monero since their hard fork upgrade

  • Audited by ZenGo X (Monero’s C implementation, Feb 2021)

  • Audited by Quarkslab (Tari’s Rust implementation)

  • Implemented by Tari in a clean, well-documented Rust crate (tari-project/bulletproofs-plus)

We’re not pioneering here , we’re adopting proven technology that two other projects have already validated.

2 Likes
2

The savings do not compound. Over time, as more and more old utxo get replaced by new utxo, the savings in rangeproof merkle tree storage size will slowly creep from 0% toward 15%.

There is no urgency in adopting better rangeproofs though. With the current low tx volume, the savings won’t be noticeable for many years.

There is also something called BP++; could that be a preferable upgrade over BP+ ?

2 Likes
3

Perhaps because no one has expressed a desire to implement it.

This is far from the reality. Most of the blocks are empty currently.

1 Like
4

You are right. The savings are linear, not compounding. As old BP outputs get spent and new BP+ outputs replace them, the PMMR gradually converges toward the ~14% smaller proof size. At current tx volumes that’s a slow creep, as you said.

The argument “low volume now, so optimization can wait” assumes volume stays low. But I think one of the serious reason why volume is low is people don’t see a serious development in years. Shipping a well-executed cryptographic upgrade signals to potential contributors and users that the project is alive and capable of meaningful protocol work. This matters more than the bytes saved.

AFAIK, Neither the BP++ protocol nor any implementation has undergone a formal and serious security audit and It has not been deployed in any production blockchain.

That said, I take your point that this shouldn’t be treated as urgent and project has higher priorities. It was just an idea that came to my mind based on what I know about this field, that I thought I can help in the development.

3 Likes