pull down to refresh

I found this thread to be pretty interesting.

If you've been playing around with @arkade_os, you may have noticed an 'Arkade address' in your Receive tab

You may be wondering:

👉 Why is it so long?
👉 Why is the first part the same even after creating a new wallet?
👉 How does it relate to my mainnet Bitcoin address?

To explain what an Arkade is, we first need to recap how a Bitcoin address works

The simplest definition is that it's a long word that encodes a set of rules for how funds can be spent (e.g. “by Alice, after 2 days”)

This set of rules is also known as a "script pubkey"

The script pubkey defines what a valid spend must "look like", but it doesn't include the actual data needed to spend the funds

If we use a lockbox analogy, the address only describes the shape of the keyhole, not the key itself

Modern bitcoin addresses use a special encoding format known as bech32m

This format uses several components, but the part that the Bitcoin protocol cares about is everything after "1" minus the last 6 characters

This is called the "payload" (highlighted in blue) 👇

Every bech32 character in the payload translates to a 5-bit binary number (sometimes called a "word"), e.g.:

q -> 0 -> 00000
p -> 1 -> 00001
4 -> 21 -> 10101

If you want to learn more about why this format was chosen, I recommend reading this blog post: https://sprovoost.nl/2022/11/10/what-is-a-bitcoin-address/

Walking through a practical example with this @arkade_os mainnet boarding address:

"bc1put5fehwk652mlgw62aj0upj2v600pdqkw25jz0lzyapx7tpkuerqjqm6v4"

First, we extract the payload 👇

"put5fehwk652mlgw62aj0upj2v600pdqkw25jz0lzyapx7tpkuerq"

Then, we follow BIP-350 rules to identify the payload as a Taproot address (represented by "p")

The remaining 52 bech32 characters can be then decoded into bits, then regrouped into 8-bit bytes

The resulting data is a 32-byte Taproot output key 👇

"e2e89cddd6...6f2c36e646"

This Taproot output key a.k.a. 'tweaked public key' is what's used by Bitcoin nodes to verify any transactions that spend funds from this address

I'm not going to get into Taproot key tweaking mechanics, but if you're curious I highly recommend this book: https://btcwip.com

Now that we've walked through how a mainnet address works, how about an @arkade_os address?

They're actually quite similar!

The three main differences are the prefix ("ark" for Arkade, instead of "bc), the version ("q" for 0), and the payload length (~2x)

We follow almost the same rules to decode Arkade addresses

However, the output is 64 bytes, not 32

Why?

There's an additional "server public key" inserted before the Taproot output key

And why is that included?

To answer that, it helps to recap how @arkade_os works...

As you may be aware, @arkade_os is a new protocol that scales Bitcoin without bridges, wrappers, or sidechains

All funds on Arkade exist on mainnet, and all Arkade transactions are valid mainnet transactions

And yet, you can do stuff like instant payments

How come?

Simple: the collaborative spend path

Arkade users can spend offchain by collaborating with a cosigner, which is a program that enforces additional spending restrictions

The cosigner exposes a public key so you can verify its signatures, which is what's returned by the server

One these spending restrictions is banning the RBF feature, which enables senders to 'cancel' a pending transaction

On mainnet, this means you often need to wait for confirmation for ~10 minutes or more

Meanwhile on Arkade, you can just trust the cosigner to block RBF attempts

But let's say the server goes down and the sender is malicious

👉 How do you get your funds out?

Well, you'll need to reconstruct the Taproot output key used to receive funds on Arkade

This in turn requires the server public key, even if you use the unilateral exit path

Additionally, it's included for verification:

👉 How can you ensure you or your recipient are using the correct @arkade_os server?

You could use DNS records, but they're centralized; public keys on the other hand are sovereign

The mainnet version of the Arkade address is simply the decoded Taproot output key encoded in the "bc1p" format instead of "ark1q"

The bech32 characters are different, because of the different payload length and checksum

But the low-level data is the same