Core Concepts of Accountable Assertions
In the world of Bitcoin, ensuring security is paramount. Relinx employs advanced cryptographic techniques to achieve this, putting control firmly in the hands of users. Remember, “Not your keys, not your coins.”
We mentioned in Relinx’s litepaper that users retain control over their assets through the use of Time-Locks and Accountable Assertions. In previous posts, we’ve explained the principles behind Time-Locks; now, let’s continue by exploring Accountable Assertions.
This concept was introduced back in 2015 by Tim Ruffing and his team. It’s a sort of cryptographic primitive that lets users make statements in a way that holds them accountable within a specific context. If someone tries to play dirty by making two conflicting statements in the same context — a shady move known as “equivocation” — any observer can actually extract the attacker’s secret key. In their model, this key protects a certain amount of funds, and once it’s extracted, those funds can be taken away from the attacker. Pretty neat, right?
Here are some of the key features of this technology:
- Extractability: If a user makes two different assertions in the same context, you can extract their key. It’s like catching someone red-handed.
- Secrecy: For users who don’t engage in equivocation, their secret key remains safe. Even if an attacker tries to get them to make assertions in selected contexts, their key stays secure.
- Statefulness: The assertion algorithm remembers past states and actions, especially the assertions made in a specific context. This way, if conflicting statements are detected, the attacker’s secret key can be extracted and used to penalize them.
- Compatibility with Existing Cryptographic Primitives: Accountable Assertions are designed to be added onto existing public key primitives like ECDSA key pairs. This is crucial in practice because the secret keys used in Accountable Assertions need to have value, like being used to redeem funds.
So, how does this all work? It’s based on something called Chameleon Hash Functions. These are collision-resistant, randomized hash functions with a twist — they come with a trapdoor that allows easy computation of collisions, i.e., two different inputs that produce the same hash value. This means that with the right trapdoor, you can find a collision for the hash value without sacrificing security. This property has several important applications in cryptographic protocols and systems such as privacy-preserving digital signatures, fair exchange protocols, zero-knowledge proofs, and of course blockchain.
Chameleon Hash Functions have been around since the ’90s and have seen a lot of improvements and applications over the years. Let me give you a quick rundown of how a chameleon hash function based on discrete logarithms works. First, you pick a key pair (A,a)
such that A=gᵃ
. The chameleon hash function is then CH(m,r)=gᵐAʳ
, where m
is the input you want to hash, and r
is a random number. For anyone who only knows (A,m,r)
, it's impossible to compute another r’
such that CH(m',r')=CH(m,r)
, which means gᵐ'Aʳ'=gᵐAʳ
. But for the person who knows the secret, computing r'
becomes a matter of solving m'+ar'=m+ar
, which is straightforward.
This can be used to create digital signatures that are malleable by the signer. This allows the signer to change the message without changing the signature, which can be useful for applications requiring privacy or the ability to retract or change signed messages without invalidating the signature.
Accountable Assertions build on this by adding a method to obtain the private key a
when collisions happen. Essentially, if we know (m,r,m',r')
and have m'+ar'=m+ar
, we can solve for a
as a=(m-m')/(r'-r)
. Voila! We've got a way to extract the private key when the user’s assertions collide. It essentially lets you enforce strong accountability and traceability for user actions and it is also how accountable assertions work.
But here’s the catch: you can only use a key pair once, which is a big challenge for the Bitcoin ecosystem. Issuing a new public key means you need to create a new Bitcoin transaction, which is super costly and inefficient. The paper proposes a clever workaround for this problem. They use something called chameleon authentication trees, which are special Merkle trees that incorporate chameleon hash functions with Aᵢ,ⱼ ← CH((Aᵢ₊₁,ₛ,Bᵢ₊₁,ₛ,Cᵢ₊₁,ₛ);rᵢ,ⱼ)
.
Each node in the tree has multiple values, and these values are picked from the next layer of nodes using a fixed random function and then hashed using the chameleon hash function. When you want to make an assertion, you pick an unused value from a leaf node and recursively apply the chameleon hash function up the tree to get your r'
. Since each value is used for the first time along this path, no one else can extract the private key. When you need to make a new assertion, you just switch to a new path. Only when someone acts maliciously—by reusing a path—will a collision happen. At that point, you can use the extraction algorithm to recover the private key. This design balances both security and efficiency, making it super practical.
Relinx leverages these mature cryptographic techniques to protect user assets while efficiently serving various business needs. We hope this makes the whole concept of Accountable Assertions a bit more accessible to grasp once you break it down.