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
https://twiiit.com/gringokiwi/status/2051699691599876116