Squeaknode

Trustless Lightning Payments for Content

2022-01-07T00:00:00+00:00

The existence of the Lightning Network enables new types of online communities where participation and access to content is dependent on individual users making Bitcoin micropayments. These new communities can operate without a central authority, and without a middleman taking a cut of the profit.

In this post, I will briefly describe the weaknesses of the existing models for Lightning monetization, and how these problems will be solved when PTLC payment channels are the standard in Lightning Network.

How Lightning incentivizes content

If we imagine a world where social media is decentralized, content will no longer be hosted by large companies like Twitter, Facebook, Spotify, and Youtube. Instead, we will see individuals and independent hosting providers relaying and aggregating content that is signed cryptographically by individual users. This raises the question of how will these relays/aggregators be incentivized to host content. Lightning payments are the obvious answer.

What is wrong with the tipping model?

There are currently attempts to create models of monetization that use Lightning network to reward content creators:

Value-For-Value (Used in Podcasting 2.0 apps like Fountain)
Tipping (Used in Zion)

These apps use a voluntary payment model, where any user can access the content, and then decide how much they want to pay in tips to reward the content creator.

This leads to a situation where the majority of users are consuming the content for free, and a small generous minority of users is generating all of the revenue for the content creator. The revenue of the content creator is totally dependent on the generosity and altruism of their consumers.

It is the digital equivalent of “busking” on a sidewalk, and hoping that people will drop a few coins in your hat.

Moving to a pay for content model

A better, fairer model would be one where the consumer is required to make a payment to get access to the content.

A naive approach to accomplish this would be to simply encrypt the content, and then create a Lightning invoice with the decryption key as the invoice preimage (using HTLCs), and share the invoice with the consumer. Then, when the consumer pays the invoice, they would obtain the decryption key, and use it to unlock the content.

Unfortunately, this approach requires the consumer to trust the honesty of the content seller. A malicious seller could create an invoice using an invalid decryption key as the preimage. The buyer would make the Lightning payment, and only realize after the payment that they got an invalid decryption key. The buyer has no way to verify the validity of the invoice until it is too late, and they have already lost their funds.

This model of monetization can work if the buyer is able to trust the seller. This might be true if the seller is a large, reputable institution, but this model breaks down if we try to extend it to a peer-to-peer decentralized network, where all connections are assumed to be trustless.

Making payments trustless with PTLCs

Fortunately, there is a way to make the payment trustless for both the buyer and the seller, but it requires that Lightning use PTLC payment channels.

With PTLCs, the seller specifies a 32-byte scalar value (s) as the “preimage” at the creation-time of the invoice. When the buyer decodes the invoice payment string, they will obtain the payment point (p = s*G). The buyer will only obtain the “preimage” s after the payment is settled.

So now that we know that PTLC invoices use elliptic curve points, we can take advantage of the distributive property of points on elliptic curves:

(s1 + s2)*G = s1*G + s2*G

where s1 and s2 are scalars, and G is an elliptic curve.

The basic idea for selling content is as follows:

Alice has a piece of content she wants to be sellable.
Alice generates a scalar value s1 to use as a symmetric encryption/decryption key, and encrypts the content.
Alice calculates the point p1 on an elliptic curve G by calculating p1 = s1*G.
Alice makes p1 publicly available for anyone interested in buying the content.
Alice shares the encrypted content with a relay named Carol.
Bob downloads the encrypted content from Carol, and requests an invoice to unlock the content.
Carol generates a new scalar value s2, and creates a PTLC Lightning invoice with s1 + s2 as the preimage.
Carol sends Bob s2 and the Lightning invoice as a payment request string.
Bob decodes the payment request string to get the payment point of the invoice, call it p3.
Bob calculates s2*G. If it is equal to p3 - p1, then Bob knows that the invoice is valid.
Bob pays the Lightning invoice, and gets the value of s1 + s2 as the preimage.
Bob calculates s1 = (s1 + s2) - s2 to get the decryption key, and decrypts the content.

If Carol tries to give Bob an invalid invoice, Bob will know before he pays the invoice.

The above example assumes that Bob is able to trust that the value of p1 is valid.

Now any node in the network can relay content from any creator, and earn a profit by selling it trustlessly to any consumer. The consumer does not have to trust that the relay is an honest actor, and vice versa. The only requirement is that the payment point generated by the original content creator must be publicly known and trusted.

Payment for content with Squeak Protocol

The Squeak Protocol is a social media protocol that utilizes the properties of PTLCs on lightning to create a trustless, decentralized alternative to Twitter.

With the Squeak Protocol, any user can download an encrypted post (called a “squeak”), and verify several properties of the squeak:

1) The squeak has a unique hash that is the same across all nodes 2) The squeak was created and signed by a certain person. 3) The squeak was created after a certain time. 4) The squeak was created in reply to another squeak (or not). 5) The squeak was encrypted using a scalar that corresponds to a certain elliptic curve point.

After these properties have been verified, the consumer can request an invoice from the seller that will unlock the decrypted content of the squeak (after payment):

If the consumer then clicks the “buy” button, they will be presented with an offer that they received from the seller:

Then, if the consumer decides that the squeak is worth the price, they can pay the invoice to unlock the squeak:

The consumer now has a copy of the unlocked squeak on their own node, and they can now re-sell the squeak to other nodes in the network.

How squeaks work under the hood

There are two components in a squeak:

The squeak header
The external fields outside the header.

A squeak header has the following fields:

Field Size	Description	Data type	Comments
4	nVersion	int32_t	Squeak version information
32	hashEncContent	char[32]	The hash value of the encrypted content of the squeak
32	hashReplySqk	char[32]	The hash value of the previous squeak in the conversation thread or null bytes if squeak is not a reply
32	hashBlock	char[32]	The hash value of the latest block in the blockchain
4	nBlockHeight	int32_t	The height of the latest block in the blockchain
33	pubKey	char[33]	Contains the public key of the author
33	recipientPubKey	char[33]	Contains the public key of the recipient if squeak is a private message
33	paymentPoint	char[33]	The payment point of the squeak derived from the decryption key on the secp256k1 curve.
16	iv	char[16]	Random bytes used for the initialization vector
4	nTime	uint32_t	A timestamp recording when this squeak was created
4	nNonce	uint32_t	The nonce used to generate this squeak

There are also external fields outside the header:

Field Size	Description	Data type	Comments
1136	encContent	char[1136]	Encrypted content
64	sig	char[64]	Signature over the squeak header by the author

There is also a squeak hash, which is derived from the bytes of the squeak header using SHA256.

How a squeak is created

When a user creates a squeak, the following happens:

An encryption/decryption key is generated as a random scalar value.
A random initialization vector is generated.
The post content is encrypted with a symmetric-key algorithm using the encryption key and the initialization vector.
A hash is calculated over the encrypted ciphertext.
The payment point is calculated from the encryption key scalar value on an elliptic curve.
A new nonce is generated.
The public key of the author is derived from their private key.

Also,

The latest block height and block hash are fetched from the Bitcoin blockchain.
The hash of another squeak (to make a reply) can also be provided by the author.

All of these values are used to populate the squeak header. After the header is created:

The squeak hash is calculated from the header.
The private key of the author is used to sign the squeak hash.
The signature is then attached to the squeak.

The MakeSqueak function looks like this:

def MakeSqueak(
        private_key: SqueakPrivateKey,
        content: bytes,
        block_height: int,
        block_hash: bytes,
        timestamp: int,
        reply_to: Optional[bytes] = None,
        recipient: Optional[SqueakPublicKey] = None,
):
    """Create a new squeak.
    Returns a tuple of (squeak, secret_key)
    private_key (SqueakPrivatekey)
    content (bytes)
    block_height (int)
    block_hash (bytes)
    timestamp (int)
    reply_to (Optional[bytes])
    recipient (Optional[SqueakPublickey])
    """
    secret_key = generate_secret_key()
    data_key = sha256(secret_key)
    if recipient:
        shared_key = private_key.get_shared_key(recipient)
        data_key = xor_bytes(data_key, shared_key)
    initialization_vector = generate_initialization_vector()
    enc_content = EncryptContent(data_key, initialization_vector, content)
    hash_enc_content = HashEncryptedContent(enc_content)
    payment_point_encoded = payment_point_bytes_from_scalar_bytes(secret_key)
    nonce = generate_nonce()
    author_public_key = private_key.get_public_key()
    squeak = CSqueak(
        hashEncContent=hash_enc_content,
        hashReplySqk=reply_to or b'\x00'*HASH_LENGTH,
        hashBlock=block_hash,
        nBlockHeight=block_height,
        pubKey=author_public_key.to_bytes(),
        recipientPubKey=recipient.to_bytes() if recipient else b'\x00'*PUB_KEY_LENGTH,
        paymentPoint=payment_point_encoded,
        iv=initialization_vector,
        nTime=timestamp,
        nNonce=nonce,
        encContent=enc_content,
    )
    sig = SignSqueak(private_key, squeak)
    squeak.SetSignature(sig)
    return squeak, secret_key

Properties of a squeak

After a squeak is created, it can be shared and validated on any node.

A validated squeak has the following properies:

The squeak hash is a unique identifier for the squeak, because it is derived from the immutable fields of the squeak header.
The pubkey embedded in the squeak belongs to the author of the squeak (proved by the signature).
None of the fields in the header were modified after being signed by the author (that would change the hash, and the signature would become invalid if that happened).
The encrypted content field was not modified after being signed by the author (that would also result in the signature becoming invalid).
The Bitcoin block hash and block height (if valid) prove that the squeak was created after that block was mined.

How a user interacts with a squeak

For example, if Alice authored a squeak, and Bob obtained a copy of the squeak:

Bob will know that the squeak was authored by Alice.
Bob will know that the squeak was created after a certain time (given by the block hash).
Bob will know if the squeak is a reply to another squeak.

However, because Bob does not have the decryption key:

Bob will not be able to see the content of the squeak.

How a user unlocks the content of a squeak

Now Bob has a choice to make. Is he interested in reading the squeak that Alice authored, given everything he knows about the squeak?

If Bob wants to unlock the content, he can send a message to all of his peers in the network expressing interest in buying the decryption key for the squeak.

Bob’s peers in the network (only those who already have a copy of the decryption key) will respond to Bob by sending him invoices as described in the earlier section.

Bob can now browse through the offers, and make a payment to any peer that offered him a valid invoice. Bob knows which invoices are valid because he can validate against paymentPoint field of the squeak header, using the elliptic curve math described earlier.

When Bob makes a Lightning payment to one of the sellers, he will obtain the preimage of the invoice. This preimage can be used to get the decryption key:

The preimage is s1 + s2, as described earlier.
Bob already knows s2, because the seller sent it to him.
Bob calculates s1 = (s1 + s2) - s2 to obtain the decryption key.
Bob can then decrypt the content of the squeak.

Now Bob can read the content of the squeak!

The GetDecryptedContent method looks like this:

    def GetDecryptedContent(
            self,
            secret_key: bytes,
            authorPrivKey: Optional[SqueakPrivateKey] = None,
            recipientPrivKey: Optional[SqueakPrivateKey] = None,
    ):
        """Return the decrypted content."""
        CheckSqueakSecretKey(self, secret_key)
        data_key = sha256(secret_key)
        if self.is_private_message:
            if recipientPrivKey:
                shared_key = recipientPrivKey.get_shared_key(self.GetPubKey())
            elif authorPrivKey:
                shared_key = authorPrivKey.get_shared_key(self.GetRecipientPubKey())
            else:
                raise Exception("Author or Recipient private key required to get decrypted content of private squeak")
            data_key = xor_bytes(data_key, shared_key)
        iv = self.iv
        ciphertext = self.encContent
        return decrypt_content(data_key, iv, ciphertext)

Try it out for yourself

There is a working implementation of the core Squeak Protocol as a Python library here: https://github.com/squeaknode/squeak

And there is an implementation of a full node running the Squeak Protocol here: https://github.com/squeaknode/squeaknode

Getting started with squeaknode

2021-11-18T00:00:00+00:00

Squeaknode is a peer-to-peer social media app that lets you make posts and view posts from other people, incentivized with lightning payments.

This guide will go over some of the things you can do with the app

Set up a signing profile

The first thing you might want to do is create a signing profile. This profile allows you to create squeaks, and it will be your identity that other users will see attached to your squeaks. You can create as many signing profiles as you want.

Go to the profiles page
Click the “Create Signing Profile” button
Enter any name that you want for your profile and submit

Make a squeak

After you have a signing profile, you can now make a squeak.

Go to the timeline page
Click on the button in the bottom right corner to open the “Make Squeak” dialog
Select the signing profile from the form selection
Enter any text (and emojis) that you want, up to 280 characters and submit

Connect to other nodes

After you have created some squeaks, you may be wondering if anyone else can read them. Other users will only be able to download your squeaks if their node is connected to your node (or if they connect to another node that already has copies of your squeaks).

You can establish connections to other nodes in two ways: 1) open a connection to another node using its external address 2) share your node’s external address and let other nodes connect to you

Once a connection is established, it doesn’t matter which node started the connection, inbound and outbound connections are treated the same.

Make an outbound connection

If you know the external address of another squeaknode, you can connect to it directly:

Go to the “Peers” page
Click on the “Connect Peer” button
Enter the external address host in the input form
Enter the external address port in the input form, if it is anything other than the default (8555)
Check the “Use Tor” toggle if the address is an onion address
Submit the dialog form

After a few seconds, if the connection is successful, you should see the newly connected peer in the list of connected peers.

Accept inbound connections

You can also share your external address, and allow other nodes to make connections to you.

Go to the “Peers” page
Click on the “Show External Address” button
Copy the content of the displayed address and share it wherever you want

Now anyone who knows this external address can use it to make a connection from their squeaknode to yours.

Download Squeaks from other users

Now that you have some peer connections open, you can begin to download squeaks from other users onto your timeline.

The squeaknode timeline only shows squeaks from profiles that you are following. You can begin to follow profiles by adding contacts.

Ask a friend (who is running squeaknode) to share with you the address of their signing profile
Go to the “Profiles” page
Click on the “Add Contact” button
Enter the name of the person
Enter the address that was provided
Submit the form to create the new contact profile

After the contact profile is created, your squeaknode will begin to download squeaks from all of your connected peers that match were authored by that profile. If you go to the “Timeline” page, you should see the squeaks in the timeline, if any were downloaded.

Buying squeaks

Now you have some squeaks from other users visible in your timeline, but they are locked, so you can’t read them.

You unlock squeaks by making Lightning payments to the peers that are selling them.

Click on the squeak that you want to unlock
Click on the “Buy To Unlock” button in the middle of the squeak
When the dialog opens, select one of the offers from the selection
Check the price of the squeak, and if you agree to pay that amount, click the “Buy Squeak” button
Wait a few seconds for the Lightning payment to complete, and then the squeak should unlock

Now you should see the unlocked content of the squeak

Opening a Lightning channel directly to a seller

Sometimes the lightning payment will fail. This usually happens because:

You do not have a route to the payee
You do not have enough liquidity in your route

If you want to open a Lightning channel directly to the seller node, you can do that.

Click on the “Buy To Unlock” button in the middle of the squeak
When the dialog opens, select one of the offers from the selection
Click on the link on the “Lightning Node” section of the offer display to go to the “Lightning Node” page
Click on the “Connect Peer” button to ensure that your Lightning node is connected to the seller Lightning node.
Click on the “Open Channel” button to open the “Open Channel” dialog
Enter whatever amount you want to fund the channel and for the transaction fee and submit.
Now wait for the Bitcoin transactions to complete for the channel to finish opening.

After the channel finishes opening, you should be able to complete the payment without any problems.

Connect your Twitter account

If you are a Twitter user, you can mirror your tweets automatically to your squeaknode profile.

Obtain a “bearer token” from Twitter (you have to create a Twitter developer account: https://developer.twitter.com/en/apply-for-access)
Go to the “Twitter” page in the squeaknode app
Click the “Set Bearer Token” button and copy the bearer token from your Twitter Developer account
Click the “Add Twitter Account” button and enter your Twitter handle, and select the signing profile where you want it to be mirrored

After you set your bearer token and add your Twitter handle, your squeaknode will be configured to automatically make new squeaks for any new tweets that are created.