Note: If assets are created in Polygon they sit on Polygon’s network but can easily be bridged over to Ethereum.

If you want to do anything with Polygon, the first thing you need is a Polygon wallet. Luckily this is fairly simple with MetaMask (a popular Ethereum wallet).

Note: The below instructions are specific to Chrome but you can apply many of the same steps with other browsers. The only major difference is installing the browser extension.

(https://chrome.google.com/webstore/detail/metamask/nkbihfbeogaeaoehlefnkodbefgpgknn?hl=en)

This is one of the most challenging problems in crypto, securing your wallet. Make sure this phrase is saved in a secure place, treat it like your birth certificate document or SSN card. If you detest physical storage, an easy option is a password manager like 1Password.

Now your Metamask wallet is created, congrats! This is the biggest step in your crypto journey.

Now you should be able to see it in the corner of your browser, it’s the little fox.

As you start transacting in Polygon, be sure to remember this site. You can view all transactions on Polygon in Polyscan.

Under Account 1, you will see something like 0xAE1…, that’s your wallet address. If you want to receive anything to your wallet use that address.

This event will hit our finances, regulations, and global economy.

Finances

• How will established institutions that recently embraced Bitcoin through ETFs react to the sudden supply shock?

• How will the sudden change in Bitcoin’s supply affect peripheral financial assets?

Regulations

• As miners are forced out will regulators impose stricter controls on mining oligopolies?

• Will regulators require more audibility from organizational and individual miners?

Global Economy

• How will this affect the overseas and U.S. mining industry?

We’ll examine the halving events and analyze all the chaos it will cause us:

• What is a Bitcoin Halving?

• How often does it occur?

• Price of Bitcoin and the Halving Events

• Economic Impact of Halving Events

• Halving and Gresham’s Law

• This Story in the Bitcoin Core Code

Every 210,000 blocks the block mining reward fee is reduced by half. This was determined years ago when the code was first implemented. The intention behind halving the fees over time is to slow down the network growth and give it time to mature.

The halving events should continue till the year 2140 when the maximum supply of 21 million Bitcoins are met.

A new block is mined every 10 minutes, the 10 minute time is maintained by adjusting the difficulty (if blocks are mined too quickly the difficulty increases and if they’re mined to slowly the difficulty decreases).

So if we are halving every 210,000 blocks then we should have a halving event every 4 years.

Minutes Per Year = 60 minutes per hour * 24 hours per day * 365 days per year = 525600 minutes a year

Minutes to Mine 210,000 blocks = 10 minutes to mine block * 210,000 blocks = 2,100,000 minutes to mine 210,000 blocks

2,100,000 minutes to mine 210,000 blocks / 525600 minutes a year ~= 4 years

Below are the date of the halving events and their estimated halving events.

There isn’t a direct correlation between the price of Bitcoin and the halving events. Usually the trend is that Bitcoin is fairly stable then there is an uptick after a halving event, but this time (3rd halving event) we’ve seen the uptick before the halving event.

The intention for the halving is to slow down the rate of Bitcoins coming into the market, and in turn keep the currency

The companies that would be directly impacted by the halving are mining pool companies and companies that supply mining infrastructure. Marathon, Riot, and Clean Spark are some of the biggest miners today, halving the Bitcoin reward might remove many miners from the market and allow some of these larger mining companies to expand. Companies like NVIDIA and AMD will see negative affects from their mining equipment sales because there will be less miners.

Note: NVIDIA and AMD are growing their AI business and might not be deeply impacted from a stock perspective.

The companies that are crypto adjacent have been Coinbase, Block (Square), Microstrategy, Galaxy Digital Holding, Paypal, and Reddit because they have a large holding of Bitcoin and some provide crypto utilities. Their growth is indirectly impacted by how the halving impacts the fiat value of Bitcoin and the movement of Bitcoin.

Since the halving event reduces the reward for mining Bitcoin PoW (proof of work) miners would have more of an incentive to mine on other PoW networks. As of today some of those networks are Dodgecoin, Bitcoin Cash, Litecoin, Ethereum Classic, Kaspa, and Monero. It doesn’t mean that the coins associated to these networks will increase in value, but there might be more activity around mining, which will eventually lead to trading in these networks.

bad money drives out good

The idea behind the Gresham Law is if two forms of money are in circulation at the same time then people will use the bad money and save or hoard the good money, eventually driving the good money to appear less in circulation. An example is gold and fiat currency, gold it’s considered (even today) good money, but how many times did you buy something with gold or receive it?

The supply of Bitcoin won’t decrease with the halving but it will slow down the supply, making it somewhat scarcer. This scarcity might drive people to hold on to their Bitcoin rather than spend it.

The combination of hoarding and new Bitcoins entering into circulation might decrease the velocity of Bitcoin (how quickly units are exchanged), causing an increased value. This would make Bitcoin, “the good money,” to disappear from circulation and for Fiat currency, “bad money,” to appear more in circulation.

The same theory can be applied to other cryptocurrencies and Bitcoin. As Bitcoin, the “good money,” is hoarded more blockchain projects will use cryptocurrencies that are considered the “bad money”. It wouldn’t make sense to create DApps that use a crypto that’s high in value, so instead, companies would create their DApps using crypto that has low transaction fees in fiat. This could give way to modern cryptocurrencies like Solana, Algorand, and Avalanche.

Here we have the logic that tells us that the mining reward (subsidy) is halved every 210,000 blocks.

 CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
{
    int halvings = nHeight / consensusParams.nSubsidyHalvingInterval;
    // Force block reward to zero when right shift is undefined.
    if (halvings >= 64)
        return 0;

    CAmount nSubsidy = 50 * COIN;
    // Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
    nSubsidy >>= halvings;
    return nSubsidy;
}

The 210,000 is defined as a parameter value (nSubsidyHalvingInterval) in the chain params.

class CMainParams : public CChainParams {
public:
    CMainParams() {
        m_chain_type = ChainType::MAIN;
        consensus.signet_blocks = false;
        consensus.signet_challenge.clear();
        consensus.nSubsidyHalvingInterval = 210000;
...

This is where the maximum supply of Bitcoin can exist, if a bug ever causes the supply to exceed 21 million Bitcoin will go into a fork. The “MoneyRange” line of code is crucial and is referenced throughout the codebase.

// Copyright (c) 2009-2010 Satoshi Nakamoto
// Copyright (c) 2009-2021 The Bitcoin Core developers
// Distributed under the MIT software license, see the accompanying
// file COPYING or http://www.opensource.org/licenses/mit-license.php.

#ifndef BITCOIN_CONSENSUS_AMOUNT_H
#define BITCOIN_CONSENSUS_AMOUNT_H

#include <cstdint>

/** Amount in satoshis (Can be negative) */
typedef int64_t CAmount;

/** The amount of satoshis in one BTC. */
static constexpr CAmount COIN = 100000000;

/** No amount larger than this (in satoshi) is valid.
 *
 * Note that this constant is *not* the total money supply, which in Bitcoin
 * currently happens to be less than 21,000,000 BTC for various reasons, but
 * rather a sanity check. As this sanity check is used by consensus-critical
 * validation code, the exact value of the MAX_MONEY constant is consensus
 * critical; in unusual circumstances like a(nother) overflow bug that allowed
 * for the creation of coins out of thin air modification could lead to a fork.
 * */
static constexpr CAmount MAX_MONEY = 21000000 * COIN;
inline bool MoneyRange(const CAmount& nValue) { return (nValue >= 0 && nValue <= MAX_MONEY); }

#endif // BITCOIN_CONSENSUS_AMOUNT_H

This is where we add the block subsidy (mining reward) with the transaction fee.

CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
{
    int halvings = nHeight / consensusParams.nSubsidyHalvingInterval;
    // Force block reward to zero when right shift is undefined.
    if (halvings >= 64)
        return 0;

    CAmount nSubsidy = 50 * COIN;
    // Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
    nSubsidy >>= halvings;
    return nSubsidy;
}

Here we stop issuing fees if the accumulated fees exceed 21 million, as defined.

nFees += txfee;
            if (!MoneyRange(nFees)) {
                LogPrintf("ERROR: %s: accumulated fee in the block out of range.\n", __func__);
                return state.Invalid(BlockValidationResult::BLOCK_CONSENSUS, "bad-txns-accumulated-fee-outofrange");
            

Swan Bitcoin — Next Bitcoin Halving: April 19th History and What to Know!

Next Bitcoin Halving: March 26th, 2028 History and What to Know!

Every four years, the Bitcoin network experiences an event known as the "halving." The fifth Bitcoin halving is set to happen on March 26th, 2028. But, WTH is a halving, and why does it matter...

https://www.swanbitcoin.com

Swan Bitcoin — Gresham’s Law

Why Gresham's Law is Important For You (2024 Update)

Bitcoin's legal status as commodity money brings to light Gresham's Law, an economic principle stating "bad money drives out good." We explore how to apply Gresham's Law to the Bitcoin Standard.

https://www.swanbitcoin.com

Bitcoin Core Github

GitHub - bitcoin/bitcoin at 28f2ca675f89a764e1ec8eb5671b35357b8677f3

Bitcoin Core integration/staging tree. Contribute to bitcoin/bitcoin development by creating an account on GitHub.

https://github.com

Blockworks — Bitcoin Halving BTC Price Implications

How the halving could impact bitcoin's price

The halving officially takes place on April 19, meaning there are roughly 8,600 bitcoin blocks until the event.

https://blockworks.co

Bitcoin Talk

Popular Solutions using Algorand

A few standup apps that use Algorand are Republic, Securitize, El Salvador’s blockchain infrastructure, Marshall Island’s digital currency, Orion Protocol, and DUST Identity.

Pure Proof of Stake uses verifiable random function (VRF) as a weighted lottery where the weight is dependent on the number of ALGO’s someone owns.

VRF performs cryptographic sortition to select committees to run the consensus protocol. There are three parts to VRF, keygen, evaluate, and verify.

Y, our random string is unique and pseudorandom, it looks random, but with the proof, you can verify it with the verification algorithm.

In Algorand, each user (Algo holder online) runs through the steps above. They hold a secret key SK (secret key) and VK (verification key), the VK is known publicly, all handled out of band. If these users want to participate in the committee to run the consensus, then they need to do the following:

1. Compute Evaluate(SK, Qr) → (Y, ⍴). Here, Qr is a “magic” seed string available to everyone in the system.

2. Check that Y falls within a specific range [0, P] that depends on the user’s stake in the system.

Algorand shared their VRF algorithm with Libsodium, check out the implementation below:

https://github.com/algorand/libsodium/tree/draft-irtf-cfrg-vrf-03/src/libsodium/crypto_vrf?source=post_page-----e962f48f8c72--------------------------------

Below is the standardization on VRF by Sharon Goldberg, Moni Naor, Dimitris Papadopoulos, Leonid Reyzin, and Jan Včelák:

Verifiable Random Functions (VRFs)

A Verifiable Random Function (VRF) is the public-key version of a keyed cryptographic hash. Only the holder of the private key can compute the hash, but anyone with public key can verify the correctness of the hash. VRFs are useful for preventing enumeration of hash-based data structures.

https://datatracker.ietf.org

An interesting feature of Algorand is that it’s not forkable.

Side Note on Forking

Forking happens if two nodes get a valid block simulataneously and different users can’t agree on which block to take or an upgrade can’t be decided on. In these scenarios the chain splits in two and as new blocks are added to the chain one of them will get longer than the other. Eventually the longest one will stay and the shortest one will die off. When the shortest chain dies off, all the blocks in it, along with all the transactions will be considered invalid.

Forking is not a bad thing.

Algorand is built to prevent forks. It isn’t necessarily a positive feature, just another way of tackling the CAP theorem (Consistency, Availability, and Partition Tolerant). With blockchain networks like Solana, forks are created to rotate leaders quickly. Forking allows the network to process transactions quickly and keep moving when there are disagreements but sacrifices consistency in the process.

The benefit around this is there’s an assurance that transactions reach finality once they are complete (~5 seconds). In forkable networks, you need to wait after a certain amount of blocks (6 blocks is recommended in Bitcoin, which could be an hour) are added on top of the block to know your transaction is in and it’s finalized.

How is Algorand Unforkable

Algorand is unforkable because two blocks can never be propagated to the chain at once because only one block can have the required threshold of committee votes.

Below are the steps in the Algorand Consensus Protocol:

1. Proposal Phase

Every node loops through online accounts with valid participation keys and selects an account. Now an account is selected, the other nodes verify the account was selected.

2. Soft Vote Phase

The number of proposals are narrowed down, and the nodes verify the signed messages and validate the selection using a VRF proof. The account with the lowest VRF hash is chosen to propose the next block.

3. Certify Vote Phase

A committee of 1,000 verifiers is pseudorandomly selected to receive information about the new block. Their job is to verify the block and mark it as valid or invalid. If the quorum is reached, the block is added to the blockchain.

If Quorum Not Reached — Network enters recovery mode but doesn’t fork

The network would never fork instead it will enter the recover mode. In recovery mode recovery messages are sent out. Nodes will send these messages to signal to the network that it should either continue processing the last known block proposal or to propose a new block.

When a quorum of votes is received for either one of these messages, the system will revert to normal operation.

In the case of malicious behavior, the protocol may select a new leader. In the case of network outage, the current block will continue to be processed or a new block might be proposed.

Check out the video below to learn more about Pure Proof of Stake.

Or check out the white paper on the protocol:

https://www.algorand.com/Algorand%20Protocol.pdf

The ledger uses SQLite database as its internal store. This is where the algod process writes and reads data.

SQLite was chosen as it provides excellent storage performance, is embedded, lightweight, and fault-tolerant. Other databases might provide better indexing features — but these are not required for an algorand node.

A drawback behind using SQLite is the lack of control from a database standpoint. For instance, your flexibility would be limited if you wanted to optimize the database like add indexes, etc. It’s not a deal-breaker but something to ponder if you’re considering Algorand for government or financial projects where the organization has its database management strategies.

Relational databases are rare in the blockchain space. The norm is key-value databases (i.e., Bitcoin & Ethereum uses LevelDB, Solana & Polkadot uses RocksDB). These databases are lightweight and easy to scale out horizontally. The only other platform that uses relational databases is Corda R3.

Indexer is a separate binary outside the Algorand node that acts as a REST API interface. It retrieves the blockchain data from a PostgresSQL database and is connected using an Algod process running on an Archival Algorand node.

Below is an example of a query where we return the last 1000 transactions that exceeded ten microAlgos:

#/indexer/python/search_transactions_min_amount.pyresponse = myindexer.search_transactions(min_amount=10)# Pretty Printing JSON string
print(json.dumps(response, indent=2, sort_keys=True))

Accounts do not exchange messages directly; instead, they propagate their messages to a relay node. The relay node is untrustworthy, so to work around that, we use an encoding. One thing to keep in mind is that the relay nodes are permissioned nodes. They are registered with the Algorand foundation’s SRV records. This nudges Algorand towards a more centralized approach.

All messages in Algorand are encoded using MessagePack, a binary serialization format that allows exchanges in languages like JSON.

https://msgpack.org/?source=post_page-----e962f48f8c72--------------------------------

The network operates in a mesh network using WebSockets over HTTP (TCP). Algorand probably chose TCP because it’s commonly supported and can handle tasks like prioritizing queued messages.

The transaction pool, also called the mempool in other networks, is where the transactions are held in memory and added into a block proposal.

A transaction pool prepares valid blocks for proposals and caches validated transaction groups.

At all times, the transaction pool maintains a queue of transaction groups slated for proposal. It checks that the transactions are properly-signed, the fees meet the minimum, and the state changes are consistent with the prior transactions in the queue. It does all of this work within a deadline; if it doesn’t finish by the deadline, it gets a buffer period it puts together an empty or partial block.

With every transaction, there’s a minimum transaction fee of 1,000 microAlgos or .001 Algos. On top of that, there is a fee per byte based on the estimated size of the transaction in bytes. If this fee is less than the minimum fee, it defaults to the minimum fee. To better understand the fees, you can use the SDK method suggested fee per byte (fee).

Check out the fee documentation below for details:

https://developer.algorand.org/docs/get-details/transactions/?from_query=fee&source=post_page-----e962f48f8c72--------------------------------#fees

In Algorand, there is a required minimum balance of 100,000 microAlgos (today that’s ~$0.092373). If your transaction gets the balance below this minimum, it will fail.

FeeSink is where all fees from transactions are sent. The FeeSink can only be spent towards the RewardsPool account. The RewardsPool account holds the Algos that need to be distributed as rewards to Algorand accounts in the protocol. As you can see in the code below, there’s a logic that only allows the FeeSink to send to the RewardPool.

This approach is slightly centralized, the reward pool is just one address on the Algorand network. Below is the reward pool for mainnet:

There are two processes in Algorand, there’s KMD and Algod.

KMD (Key Manager Daemon) handles all interactions with spending keys, including signing transactions. Signing can also be standalone.

Algod is responsible for processing the protocol and interacting with SQLite to write records and implement REST API for reads.

Algorand uses TEAL (Transaction Execution Approval Language) and REACH.

Algorand smart contracts like Ethereum smart contracts have an Algorand address and can hold Algorand Assets (ASA’s) and Algos.

Refer to the docs to learn more about smart contracts:

Overview - Algorand Developer Portal

Algorand Developer Docs, SDKs, REST APIs, CLI tools, ecosystem projects, metrics dashboard and sample code, how-tos, and news from the Algorand developer community

https://developer.algorand.org

TEAL is an assembly-like language that’s processed in AVM (Algorand Virtual Machines). It’s a Turing-complete language that supports looping and subroutines has guardrails that limit the contract’s execution time using a dynamic opcode cost evaluation algorithm. You can either write TEAL or use pyTEAL to generate TEAL code.

In pyTEAL and TEAL programs, there are always two programs: the Approval Program and the other is the Clear Program. The approval program contains most of the business logic, and the clear program handles closing the account(s).

All communication with Algorand smart contracts is achieved through application transactions. Below are the six application transaction subtypes.

Approval Program

As you can see in the NFT smart contract example below, all the meat sits in the approval program.

from pyteal import *

def approval_program():
    """
    This smart contract implements a Non Fungible Token
    Each NFT is an (ID, ref_data, hash) triple.
    NFT ID is the total count of NFT's in asc.
    ref-data is represented as "https://nft-name/<total>/nft-ref"
    hash is an hash of the external resources data.
    Commands:
        create    Creates a new NFT. Expects 2 additional arguments:
                    * nft-ref: a reference data (usually a URL or CID)
                    * nft-ref-hash: a hash of the underlying reference data
                    Only creator can create new NFTs.
        transfer  Transfers an NFT between two accounts. Expects one additional arg: NFT_ID.
                    Additionally, two Accounts(from, to) must also be passed to the smart contract.
    """

    var_total = Bytes("total")
    var_1 = Int(1)

    # Check to see that the application ID is not set, indicating this is a creation call.
    # Store the creator address to global state.
    # Set total nft count to 0
    on_deployment = Seq([
        App.globalPut(Bytes("creator"), Txn.sender()),
        Assert(Txn.application_args.length() == Int(0)),
        App.globalPut(var_total, Int(0)),
        Return(var_1)
    ])

    # Always verify that the RekeyTo property of any transaction is set to the ZeroAddress
    # unless the contract is specifically involved ina rekeying operation.
    no_rekey_addr = Txn.rekey_to() == Global.zero_address()

    # Checks whether the sender is creator.
    is_creator = Txn.sender() == App.globalGet(Bytes("creator"))

    # Get total amount of NFT's from global storage
    create_nft_id = Itob(App.globalGet(var_total))

    # create transaction parameters
    data_ref = Txn.application_args[1]
    data_hash = Txn.application_args[2]

    # var to store id_h
    id_h = ScratchVar(TealType.bytes)

    # Verifies if the creater is making this request
    # Verifies three arguments are passed to this transaction ("create", nft-name, nft-ref)
    # Increment Global NFT count by 1
    # Assign data_ref to NFT ID (= total)
    # Assign hash of nft-ref to ID_h
    # Add above two keys to global and creator's local storage
    create_nft = Seq([
        Assert(And(
            Txn.application_args.length() == Int(3),
            is_creator,
            no_rekey_addr
        )),

        App.globalPut(var_total, App.globalGet(var_total) + var_1),

        id_h.store(Concat(create_nft_id, Bytes("_h"))), # store id_h in scratchVar
        App.globalPut(create_nft_id, data_ref),
        App.globalPut(id_h.load() , data_hash),

        App.localPut(Int(0), create_nft_id, var_1),  # Int(0) represents the address of caller
        Return(is_creator)
    ])

    transfer_nft_id = Txn.application_args[1]  # this is only in the transfer condition

    # Verify two arguments are passed
    # Verify NFT_ID is present in global storage
    # Add nft to account_2's local storage
    # Remove nft from account_1's local storage
    transfer_nft = Seq([
        Assert(And(
            Txn.application_args.length() == Int(2),
            no_rekey_addr,
            # assert that a account_1 holds the NFT
            App.localGet(var_1, transfer_nft_id) == var_1
        )),

        App.localDel(var_1, transfer_nft_id),
        App.localPut(Int(2), transfer_nft_id, var_1),
        Return(var_1)
    ])

    # Verfies that the application_id is 0, jumps to on_deployment.
    # Verifies that DeleteApplication is used and verifies that sender is creator.
    # Verifies that UpdateApplication is used and blocks that call (unsafe for production use).
    # Verifies that closeOut is used and jumps to on_closeout.
    # Verifies that the account has opted in and jumps to on_register.
    # Verifies that first argument is "vote" and jumps to on_vote.
    program = Cond(
        [Txn.application_id() == Int(0), on_deployment],
        [Txn.on_completion() == OnComplete.UpdateApplication, Return(Int(0))], #block update
        [Txn.on_completion() == OnComplete.DeleteApplication, Return(is_creator)],
        [Txn.on_completion() == OnComplete.CloseOut, Return(var_1)],
        [Txn.on_completion() == OnComplete.OptIn, Return(var_1)],
        [Txn.application_args[0] == Bytes("create"), create_nft],
        [Txn.application_args[0] == Bytes("transfer"), transfer_nft]
    )

    return program

if __name__ == "__main__":
    print(compileTeal(approval_program(), Mode.Application, version = 4))

Clear State

from pyteal import *

def clear_state_program():
    return Return(Int(1))

if __name__ == "__main__":
    print(compileTeal(clear_state_program(), Mode.Application, version = 4))

I pulled the smart contract above from Algo-Builder’s smart contract template:

algo-builder/examples at master · scale-it/algo-builder

Framework to automate development of Algorand Assets and Smart Contracts. - algo-builder/examples at master · scale-it/algo-builder

https://github.com

Reach is a DApp framework that works with Algorand and Ethereum, most commonly used with Algorand. Reach aims at handling the whole experience, frontend, and backend. The backend is dealt with a file like index.rsh and the frontend in an index.mjs.

Get your hands dirty with Reach by running through the tutorial below:

https://developer.algorand.org/docs/get-started/dapps/reach/?source=post_page-----e962f48f8c72--------------------------------

Standing up an Algorand is quite simple. You can even get away running on your laptop. Making it easier for several people to start running their Algorand nodes. Surprisingly, there aren’t many nodes running today, as of today, 1/31/21, there are only 1,427 nodes running. Giving that number some context, today, 1/31/21, there are 2,052 nodes running with Ethereum.

The relay nodes have to be registered with Algorand. In a truly decentralized blockchain, everyone and their mom should be able to run any node. Even though all these Relay Node participants are from different companies and countries, there is a point of centralization because they are all approved by the same organization.

Algorand has no minimum to participate in proof of stake, which allows anyone to participate in proof of stake. Every Algo token in Pure Proof of Stake (PPoS) (the consensus algorithm) is considered a lottery ticket. There’s a chance that the consensus would choose you with just one Algo, but the chances of being chosen increase with more “lottery” or Algos you have.

With Algorand’s no-fork design and its use of SQLite, I don’t see how it can scale. This approach of approving one block at a time, transactions could pile up if there isn’t a consensus on what’s proposed, stalling the network.

Because Algorand is unforkable, it’s highly secure, and transaction finality is everything regarding government and financial records.

The way they separate the processors, algod and kmd, makes the reads and writes secure. Key management should always be handled separately from other blockchain duties.

Algorand’s approach of not using spending keys to participate in consensus keeps the network secure. Instead, participants use a participation key and a collection of ephemeral keys to sign off on consensus activities like block proposals, votes, etc. This approach prevents double signing and protects spending keys from ever being jeopardized in the case of a compromised node.

Algorand is currently at around ~1,000 TPS, faster than Bitcoin and Ethereum, but not as fast as other 3rd generation blockchain networks like Solana. Algorand has proposed in their performance report that with block pipelining, they can reach 46,000 TPS, but we’ll need to wait for that implementation to deploy onto mainnet.

In terms of finality, Algorand wins; they have a finality of 2.5 seconds because it’s finalized as soon as the transaction completes. We don’t have to wait for additional blocks to be added to know it’s truly final because of its no forking design.

The Algorand Foundation pulled these performance metrics from their 2021 performance report:

https://drive.google.com/viewerng/viewer?url=https://www.algorand.com/120720-Algorand%25202021%2520Performance.pdf

Official Repo

GitHub - algorand/go-algorand: Algorand's official implementation in Go.

Algorand's official implementation in Go. . Contribute to algorand/go-algorand development by creating an account on GitHub.

https://github.com

Algorand Metrics Dashboard

Algorand

The AlgoGlobal Community works towards the goal of building a secure, scalable, decentralized network to serve as trusted public infrastructure for the common good.

https://forum.algorand.org

Official Algorand Forum

Algorand

The AlgoGlobal Community works towards the goal of building a secure, scalable, decentralized network to serve as trusted public infrastructure for the common good.

https://forum.algorand.org

CoMakery Algorand Security Token

GitHub - CoMakery/algorand-security-token: Open Source security token compatible with CoMakery, authored in collaboration with the Algorand Foundation team

Open Source security token compatible with CoMakery, authored in collaboration with the Algorand Foundation team - CoMakery/algorand-security-token

https://github.com

Algorand Smart Contract Architecture

Tutorial on Atomic Transfers on Android

GitHub - gconnect/AlgorandPayrollContract: This is an android app developed on the Algorand Blockchain

This is an android app developed on the Algorand Blockchain - gconnect/AlgorandPayrollContract

https://github.com

A Lightning invoice is a payment request that includes a payment hash and a preimage, which the payer must provide to settle the invoice.

Lightning invoices are generated by the payee and are used to receive payments through the Lightning Network.

We’re going to dive into:

Anatomy of an Invoice

• Human Readable Part

• Data Part

Why Do Lightning Payments Need Invoices?

Alternatives to Payments Without Invoices — Keysend

The invoice is formatted in bech32 encoding, already used for Bitcoin Segregated Witness. It’s broken up into 2 main parts: human-readable and data portions.

Below is an example of an invoice:

lnbc15u1p3xnhl2pp5jptserfk3zk4qy42tlucycrfwxhydvlemu9pqr93tuzlv9cc7g3sdqsvfhkcap3xyhx7un8cqzpgxqzjcsp5f8c52y2stc300gl6s4xswtjpc37hrnnr3c9wvtgjfuvqmpm35evq9qyyssqy4lgd8tj637qcjp05rdpxxykjenthxftej7a2zzmwrmrl70fyj9hvj0rewhzj7jfyuwkwcg9g2jpwtk3wkjtwnkdks84hsnu8xps5vsq4gj5hs

The human-readable part has the network name and amount. In the example above lnbc15u is the human-readable part.

Network

All Lightning invoices start with the letters ln for Lightning Network. Then they are followed by a 2-letter code defined by BIP173 for the network. Below is a table with network prefixes. For example, an invoice that starts withlnbc would be in the lightning mainnet because bc is after ln.

Amount

The amounts reference bitcoin, not satoshi. To save space for round invoices, an amount can be followed by a multiplier. For example, a single satoshi Lightning invoice would appear as 10n, a hundred satoshi as 1u, and a milli-satoshi as 10p. In the example above, the amount is 15u (15* 100 satoshis). Below is a table of the amount units.

The data part is broken up into a timestamp, payment hash, description, min block height expiry (min final CLTV Expiry), expiry, payment secret (preimage),

An easy to know the different parts is by looking for the tags. P is the tag for payment hash, D is the tag

In the example above, the data part is:

pp5jptserfk3zk4qy42tlucycrfwxhydvlemu9pqr93tuzlv9cc7g3sdqsvfhkcap3xyhx7un8cqzpgxqzjcsp5f8c52y2stc300gl6s4xswtjpc37hrnnr3c9wvtgjfuvqmpm35evq9qyyssqy4lgd8tj637qcjp05rdpxxykjenthxftej7a2zzmwrmrl70fyj9hvj0rewhzj7jfyuwkwcg9g2jpwtk3wkjtwnkdks84hsnu8xps5vsq4gj5hs

Timestamp

In the example above, the timestamp is p3xnhl2, this is equivalent to the timestamp 1651105770, which is equivalent to Monday, May 2, 2022, at 8:29:30 AM UTC.

Payment Hash

In the example above, the payment hash (tagged with p) is pp5jptserfk3zk4qy42tlucycrfwxhydvlemu9pqr93tuzlv9cc7g3s. The payment hash is a 32-byte hash that uniquely identifies a Lightning Network payment. This hash is used to reference the payment throughout the payment’s lifecycle, from invoice creation to the payment's fulfillment.

Description

In the example above, the description (tagged with d) is dqsvfhkcap3xyhx7un8. The description can be any text note on the invoice. The description in the example is decoded to bolt11.org.

Min Final CLTV Expiry

In the example above, the minimum final CLTV (CheckLockTimeVerify) expiry (tagged with c) is cqzpg. The minimum final CLTV is the minimum block height at which the payment can be considered final. In this example, there is a requirement of a block height of 40 to be considered final.

Expiry

In the example above, the expiry (tagged with x) is xqzjc. The expiry is the number of seconds after which the invoice will expire if the payment has not been made. In this example, the invoice will expire in 600 seconds (10 minutes) if a payment hasn’t been made.

Payment Secret

In the example above, the payment secret (tagged with s) is sp5f8c52y2stc300gl6s4xswtjpc37hrnnr3c9wvtgjfuvqmpm35evq. The payment secret is a random 32-byte string that the payer generates, encrypted in the invoice using the shared secret. It is also known as the preimage or the payment hash preimage.

The recipient must decode the invoice to obtain the payment secret, which the payer later uses to prove the payment was successful and claim the funds in the payment channel.

The payment secret is crucial for the network’s security and privacy features because it prevents unwanted parties from intercepting or tampering with the payment.

Feature Bits

In the example above, the feature bits (tagged with 9) is 9qyyssq. Feature bits are optional or required features that can be included in the invoice to indicate to the payer which capabilities the payee’s Lightning node supports. In this example, the featured bits are:

{
"var_onion_optin": "supported", 
"payment_secret": "required", 
"basic_mpp": "supported"
} 

• “var_onion_optin”: indicates that the payee’s node supports using variable-length onion packets for routing the payment.

• “payment_secret”: indicates that the payee requires the payer to include a payment secret in the payment hash.

• “basic_mpp”: indicates that the payee’s node supports the use of basic multi-path payments, which allows a payment to be split across multiple routes.

Signature

In the example above, the signature is y4lgd8tj637qcjp05rdpxxykjenthxftej7a2zzmwrmrl70fyj9hvj0rewhzj7jfyuwkwcg9g2jpwtk3wkjtwnkdks84hsnu8xps5vsq. A signature is a cryptographic signature created by the invoice issuer’s private key. It’s used to ensure the authenticity and integrity of the invoice. When the invoice recipient receives it, they can use the issuer’s public key to verify the signature and ensure that the invoice has not been tampered with.

Checksum

In the example above, the checksum is 4gj5hs. A checksum is a value calculated from a specific algorithm that is added to a Lightning invoice to ensure the integrity of the data and help detect errors.

We need invoices in the Lightning Network to route payments from the payer to the payee. Invoices contain important information such as the payment amount, payment hash, and other optional fields like the routing hints that enable intermediaries to discover the path to the payee. Routing nodes use invoices to determine the next hop in the payment path and forward the payment to the next node until it reaches the payee.

In addition, invoices also provide a way for the payee to request a specific payment amount and add additional metadata, such as an order number or customer ID, that can be useful for accounting or tracking purposes.

Without invoices, payers would have to manually construct payments and specify the routing path, which can be error-prone and time-consuming. Overall, invoices are critical in enabling efficient and reliable payment routing in the Lightning Network.

Keysend is a feature introduced in the Lightning Network that allows for small and spontaneous payments without needing a Lightning invoice. With keysend, a payer can simply send a payment directly to the payee’s Lightning node by including the payment information, such as the payment amount and memo, in the onion routing packet.

To make a payment using keysend, the payer’s Lightning node generates a payment hash and constructs an onion routing packet with the payment information in the payload. The onion packet is then sent to the payee’s Lightning node, which decrypts the packet and retrieves the payment information. The payee’s Lightning node then constructs a Lightning invoice using the payment hash, which the payer’s node can use to claim the payment once they have the preimage corresponding to the payment hash.

Keysend allows for more spontaneous and efficient payments. It eliminates the need for the payee to generate a Lightning invoice and for the payer to scan the QR code or manually enter the payment information. However, it does raise some privacy concerns, as the payment information is included in the routing packet in plaintext and can be visible to all the nodes involved in routing the payment.

Interactive Invoice BOLT 11

The Lightning Invoice

Learn about Bitcoin Lightning Network invoices. Get in-depth decoding on the inner workings of payment requests in LN.

https://www.bolt11.org

Suredbits on Lightning Invoices

https://paragraph.xyz/suredbits/lightning-101-what-is-a-lightning-invoice-d527db1a77e6?source=post_page-----bd7210f25012--------------------------------

BOLT11 Standards on Invoices in Github

bolts/11-payment-encoding.md at master · lightning/bolts

BOLT: Basis of Lightning Technology (Lightning Network Specifications) - bolts/11-payment-encoding.md at master · lightning/bolts

https://github.com

Lightning Engineering — Understanding Lightning Invoices

Understanding Lightning Invoices | Builder's Guide

Learn how to identify, decode and create Lightning invoices

https://docs.lightning.engineering

Lightning Keysend — ReadTheDocs

https://lightning.readthedocs.io/lightning-keysend.7.html?source=post_page-----bd7210f25012--------------------------------

Voltage Keysend Payments

Keysend Payments Explained - Voltage Technical Series | Voltage Blog

Keysend payments enable Lightning Network transactions without invoices, providing a simpler way to send payments directly between nodes.

https://www.voltage.cloud

In the lightning network, payment channels can close in 3 different ways, and they're good, bad, and ugly. The good is a "collaborative close" when both parties work together to close the channel. The bad is a "force close" when one party can't close the channel. The ugly is a "dispute close" when there's a force close, but the other party comes back and disputes the close initiated by the other party.

1. Negotiate the final channel balance

2. Initiate & Exchange Close Requests

3. Sign, Exchange & Broadcast Close Requests to the Network

4. Wait for Confirmations on the Network

5. Remove the Channel

💻 Code to do a Collaborative Close

📜 Example of a Collaborative Close Transaction

1. Initiate, Sign, and Broadcast the Force Close Request

2. Wait for the Force Close to Confirm

3. Remove the Channel

💻 Code to do a Force Close

📜 Example Forced Close Transaction

💻 Code of a Dispute Close Transaction

🗼Watch Tower

A collaborative close in the Lightning Network is a channel closure where both parties agree to close the channel. With a collaborative close, both parties sign off on closing the payment channel and get their funds back immediately. Below are the steps to a collaborative close.

Before initiating the channel closing, the parties should agree on the final balance. This can be done by exchanging commitment transactions until they reach a final balance that they both agree on.

Each party must initialize a close channel request in a collaborative close. Before the request is ever signed and broadcasted to the network, it must be exchanged to ensure everyone is on the right page.

An initialize request in LND implementation involves the following details:

• Channel Point: a unique identifier for a payment channel established between two parties. It consists of the channel funding transaction hash and the index of the transaction output that funds the channel.

• Target Confirmations: How many blocks need to be mined after the close txn to consider the txn done?

• Sats Per Byte: This is the Bitcoin fee rate the party is willing to pay on the close transaction.

• Force: Since this is not a force close, force is set to false.

• Delivery Address: Specifies an address to receive the funds from the closed channel. If left empty, the funds will still be split between the two parties according to their channel balance, but any unspendable funds will go to the node that initiated (Alice) the channel closure request.

Below is the code (using the LND go implementation) to initiate the close:

// Initiate the cooperative channel close.
closeReq := &lnrpc.CloseChannelRequest{
    ChannelPoint: channelPoint,
    TargetConf:   0, // Wait for the next block.
    SatPerByte:   1, // Set the fee rate.
    Force:        false, // Initiate a cooperative closure.
    DeliveryAddress: "your_bitcoin_address", // Optional.
}
closeResp, err := client.CloseChannel(ctx, closeReq)
if err != nil {
    log.Fatal(err)
}
log.Printf("Close channel response: %v", closeResp)
closeChannelStream, err := client.CloseChannel(context.Background(), closeChannelReq)
if err != nil {
     log.Fatalf("could not initiate close: %v", err)
}

Now that both parties agree on the close request, they can sign and broadcast their requests.

Below is the code (using the LND go implementation) to sign the request, send it to the remote (other) party, and receive the signed request from the remote (other) party.

// Sign the close request.
    signedCloseReq, err := client.SignMessage(context.Background(), &lnrpc.SignMessageRequest{
        Msg: closeRequest.SignedClosures[0].TxidBytes,
    })
    if err != nil {
        log.Fatalf("could not sign close request: %v", err)
    }
// Send the signed close request to the remote party.
    _, err = closeChannelStream.Send(&lnrpc.CloseStatusUpdate{
        Update: &lnrpc.CloseStatusUpdate_SignedClosingTx{
            SignedClosingTx: signedCloseReq.Signature,
        },
    })
    if err != nil {
        log.Fatalf("could not send signed close request: %v", err)
    }
    // Receive the fully signed close request from the remote party.
    closeRequest, err = closeChannelStream.Recv()
    if err != nil {
        log.Fatalf("could not receive fully signed close request: %v", err)
    }

Below is the code (using the LND go implementation) to broadcast the close channel transaction to the Bitcoin network.

// Broadcast the close transaction to the Bitcoin network.
    _, err = client.SendRawTransaction(context.Background(), &lnrpc.SendRawTransactionRequest{
        TxHex: closeRequest.SignedClosures[0].TxidBytes,
    })
    if err != nil {
        log.Fatalf("could not broadcast close transaction: %v", err)
    }

Wait for the TargetConf stated during the initiation, these are the number of blocks that need to be added after the close transaction is committed to the Bitcoin network (in this example, Alice is waiting for 6 blocks).

Below is the code (using the LND go implementation) to wait for the confirmations.

// Wait for the channel to be closed and remove it from local storage.
    waitCloseReq := &lnrpc.WaitForFinishedRequest{
        ChannelPoint: channelPoint,
    }
    _, err = client.WaitForChannelClosed(context.Background(), waitCloseReq)
    if err != nil {
        log.Fatalf("could not wait for channel to close: %v", err)
    }

Most implementations handle the channel removal on the network automatically. But even though the channel is removed from the network, the channel's information will still exist in the network.

You may want to remove a channel from your Lightening node's storage to free up disk space, improve your node's performance, or reduce your configuration's complexity.

Below is the code (using the LND go implementation) to remove the channel from local storage.

_, err = client.RemoveChannel(context.Background(), &lnrpc.RemoveChannelRequest{
        ChannelPoint: channelPoint,
    })
    if err != nil {
        log.Fatalf("could not remove channel: %v", err)
    }

Warning — Loss of Information:

Removing the channel state from your Lightning Network node will permanently delete all information associated with the closed channel, including the transaction history and any funds remaining in the channel.

This is why it’s important to make sure that the channel has been fully closed and settled on the Bitcoin network before removing the channel state from your node.

Warning — Wait for Pending HTLC’s

Wait for any pending HTLCs to expire: If there were any pending HTLCs (hash time-locked contracts) on the channel at closing, you should wait for them to expire before removing the channel state from your node.

This is because HTLCs have a time-out period during which the counterparty can redeem them. Once this time-out period has expired, the HTLCs will be resolved on-chain, and the remaining funds will be returned to the appropriate parties. Once all pending HTLCs have expired and been resolved, you can safely remove the channel state from your node.

package main

import (
    "context"
    "fmt"
    "github.com/lightningnetwork/lnd/lnrpc"
    "google.golang.org/grpc"
    "log"
)
func main() {
    // Set up a connection to the lnd instance running locally.
    conn, err := grpc.Dial("localhost:10009", grpc.WithInsecure())
    if err != nil {
        log.Fatalf("could not connect to lnd: %v", err)
    }
    defer conn.Close()
    client := lnrpc.NewLightningClient(conn)
    // Set the channel point you want to close.
    channelPoint := &lnrpc.ChannelPoint{
        FundingTxidStr: "funding_transaction_id",
        OutputIndex:    0,
    }
    // Start a cooperative close for the channel.
    closeChannelReq := &lnrpc.CloseChannelRequest{
        ChannelPoint:  channelPoint,
        TargetConf:    6,
        SatPerByte:    1,
        DeliveryAddr:  "", // Optional, if not provided the closing funds go to the channel initiator.
        Force:         false,
    }
    closeReq := &lnrpc.CloseChannelRequest{
      ChannelPoint: channelPoint,
      TargetConf:   0, // Wait for the next block.
      SatPerByte:   1, // Set the fee rate.
      Force:        false, // Initiate a cooperative closure.
      DeliveryAddress: "your_bitcoin_address", // Optional.
    }
    closeChannelStream, err := client.CloseChannel(context.Background(), closeChannelReq)
    if err != nil {
        log.Fatalf("could not initiate close: %v", err)
    }
    // Receive close request from remote party.
    closeRequest, err := closeChannelStream.Recv()
    if err != nil {
        log.Fatalf("could not receive close request: %v", err)
    }
    // Sign the close request.
    signedCloseReq, err := client.SignMessage(context.Background(), &lnrpc.SignMessageRequest{
        Msg: closeRequest.SignedClosures[0].TxidBytes,
    })
    if err != nil {
        log.Fatalf("could not sign close request: %v", err)
    }
    // Send the signed close request to the remote party.
    _, err = closeChannelStream.Send(&lnrpc.CloseStatusUpdate{
        Update: &lnrpc.CloseStatusUpdate_SignedClosingTx{
            SignedClosingTx: signedCloseReq.Signature,
        },
    })
    if err != nil {
        log.Fatalf("could not send signed close request: %v", err)
    }
    // Receive the fully signed close request from the remote party.
    closeRequest, err = closeChannelStream.Recv()
    if err != nil {
        log.Fatalf("could not receive fully signed close request: %v", err)
    }
    // Broadcast the close transaction to the Bitcoin network.
    _, err = client.SendRawTransaction(context.Background(), &lnrpc.SendRawTransactionRequest{
        TxHex: closeRequest.SignedClosures[0].TxidBytes,
    })
    if err != nil {
        log.Fatalf("could not broadcast close transaction: %v", err)
    }
    // Wait for the channel to be closed and remove it from local storage.
    waitCloseReq := &lnrpc.WaitForFinishedRequest{
        ChannelPoint: channelPoint,
    }
    _, err = client.WaitForChannelClosed(context.Background(), waitCloseReq)
    if err != nil {
        log.Fatalf("could not wait for channel to close: %v", err)
    }
    _, err = client.RemoveChannel(context.Background(), &lnrpc.RemoveChannelRequest{
        ChannelPoint: channelPoint,
    })
    if err != nil {
        log.Fatalf("could not remove channel: %v", err)
    }
    fmt.Println("Channel closed.")
}

Transaction a3b23982331300ef8d23bd90b64e939758835515642a65ba64234bf2cae2ac7a is an example of a collaborative closure.

A force close happens when one of the parties is offline, so the other party unilaterally forces the channel to close. There are fewer steps in a force close because there aren't exchanges between parties since it's a one-person show.

Below is the code (using the LND go implementation) to create the force close request. Notice that now the Force the field is marked true.

// Create the force close channel request
    request := &lnrpc.CloseChannelRequest{
        ChannelPoint:       channelPoint,        
        Force:              true,
        TargetConf:         6,
        SatPerByte:         10,
        DeliveryAddress:    "",
        ForceTargetChanId:  0,
        Anchors:            false,
    }

Below is the code (using the LND go implementation) to initiate the force close request. We are using the client to broadcast the close request here.

// Initiate the force close request
    response, err := client.CloseChannel(context.Background(), request)
    if err != nil {
        log.Fatalf("could not initiate force close: %v", err)
    }
    log.Printf("force close initiated: %v", response)

With force close, the party initiating the close has a waiting period (time lock), giving the counterparty enough time to respond.

Local and Remote Force Close

There are two types of forced closures, remote and local. It depends on who is initiating the forced closure. If you are initiating the forced closure, you are dealing with a local force close, and if you aren’t initiating the forced closure, then you are dealing with a remote force close.

This time lock prevents the funds from being spent for a certain period. This time lock is known as the CSV (Check Sequence Verify) value, and it ensures that both parties can dispute the force close and prevent fraud.

Below is the code (using the LND go implementation) to enforce the time-lock/CSV.

// Wait for the force close to be confirmed
    time.Sleep(10 * time.Minute)

In the Lightning Network, security is enforced, and honesty is incentivized using delays. The Lightening Network has two types of delays time-lock and revocation delays. If you want to dive deeper into those concepts, check out the article below:

Lightning Network & Delays

Delays in the Lightning Network are security measures that prevent inaccuracies and cheating from being published on the mainnet Bitcoin network. These built-in delays are called time-lock (sometimes...

https://medium.com

After the time-lock expires, the channel closure is complete, and now we can remove the channel from local storage.

Below is the code (using the LND go implementation) to remove the channel from local storage.

// Remove the closed channel from the node's local storage
    _, err = client.RemoveChannel(context.Background(), &lnrpc.RemoveChannelRequest{
        ChannelPoint: channelPoint,
    })
    if err != nil {
        log.Fatalf("could not remove channel: %v", err)
    }

package main

import (
    "context"
    "log"
    "time"
    "github.com/lightningnetwork/lnd/lnrpc"
    "google.golang.org/grpc"
)
func main() {
    // Create a connection to the LND instance
    conn, err := grpc.Dial("localhost:10009", grpc.WithInsecure())
    if err != nil {
        log.Fatalf("could not connect to LND: %v", err)
    }
    defer conn.Close()
    // Create a new LND client
    client := lnrpc.NewLightningClient(conn)
    // Define the channel point to be closed
    channelPoint := &lnrpc.ChannelPoint{
        FundingTxid: &lnrpc.ChannelPoint_FundingTxidStr{
            FundingTxidStr: "FUNDING_TXID",
        },
        OutputIndex: OUTPUT_INDEX,
    }
    // Create the force close channel request
    request := &lnrpc.CloseChannelRequest{
        ChannelPoint:       channelPoint,
        Force:              true,
        TargetConf:         6,
        SatPerByte:         10,
        DeliveryAddress:    "",
        ForceTargetChanId:  0,
        Anchors:            false,
    }
    // Initiate the force close request
    response, err := client.CloseChannel(context.Background(), request)
    if err != nil {
        log.Fatalf("could not initiate force close: %v", err)
    }
    log.Printf("force close initiated: %v", response)
    // Wait for the force close to be confirmed
    time.Sleep(10 * time.Minute)
    // Remove the closed channel from the node's local storage
    _, err = client.RemoveChannel(context.Background(), &lnrpc.RemoveChannelRequest{
        ChannelPoint: channelPoint,
    })
    if err != nil {
        log.Fatalf("could not remove channel: %v", err)
    }
    log.Println("force close complete")
}

Transaction f9b48496a3b16693460a447a224b102d4fb3d38bb9473dc865fb5ce6e71761bd is an example of forced closure. There are key features

If you dig a little deeper and look at the lightning channel details, you can see that Bitcoin Revolution was the one that opened and closed the channel (704410x953x0) unilaterally. Also, notice that the fees are considerably higher than a collaborative close. This transaction has a $0.67 fee, while the collaborative close (mentioned earlier) has a $0.06 fee. Force closes have higher fees because they use a time-critical pre-signed transaction.

Previously in the force close, Alice had to wait (time-lock/CSV) to give the other party a chance to come back on and dispute. In this scenario, the other party returned online within the wait time (time-lock/CSV) and disputed the force close.

In this example, Bob noticed that Alice made a force close request to the network. Luckily, Bob has the wait time (time-lock/CSV) ⏰ to dispute her close.

How would Bob dispute Alice's force close?

Bob needs to publish the most recent state of the channel before the time lock expires. If Bob publishes the most recent state within the time-lock wait time, he can publish a justice transaction 🏛 👩‍ ⚖. The justice transaction 🏛 👩‍ ⚖ will allow Bob to take everything.

What are justice transactions?

Justice transactions 🏛 👩‍ ⚖ use game theory to secure the lightning network, and if you're dishonest, you can lose it all, so the incentive of being dishonest must outweigh the risk of losing all your funds. BitMEX published research on the effectiveness of justice transactions.

BitMEX Research Confirms Lightning 'Justice' Works

BitMEX Research has confirmed that the Lightning Network's Justice Transactions system can effectively prevent cheating.

https://bitcoinmagazine.com

When does 🏛 👩‍ ⚖ justice transactions happen?

After the breach close transaction is confirmed on the Bitcoin network, the channel will enter into the “Pending Force Close” state.

At this point, the justice transaction will be broadcasted by the LND node to claim the channel’s funds and penalize the counterparty.

The code below walks through the steps Bob needs to take using the LND implementation in Go.

import (
 "context"
 "log"
 "github.com/lightningnetwork/lnd/lnrpc"
 "google.golang.org/grpc"
)
func main() {
 // Create a connection to the LND instance
 conn, err := grpc.Dial("localhost:10009", grpc.WithInsecure())
 if err != nil {
  log.Fatalf("could not connect to LND: %v", err)
 }
 defer conn.Close()
 // Create a new LND client
 client := lnrpc.NewLightningClient(conn)
 // Define the channel point to be disputed
 channelPoint := &lnrpc.ChannelPoint{
  FundingTxid: &lnrpc.ChannelPoint_FundingTxidStr{
   FundingTxidStr: "FUNDING_TXID",
  },
  OutputIndex: OUTPUT_INDEX,
 }
 // Create the breach close transaction request
 request := &lnrpc.BreachCloseChannelRequest{
  ChannelPoint: channelPoint,
  SweepAddress: "YOUR_SWEEP_ADDRESS",
 }
 // Generate the breach close transaction
 response, err := client.BreachCloseChannel(context.Background(), request)
 if err != nil {
  log.Fatalf("could not generate breach close transaction: %v", err)
 }
 log.Printf("breach close transaction generated: %v", response)
 // Broadcast the breach close transaction to the network
 _, err = client.PublishTransaction(context.Background(), &lnrpc.PublishTransactionRequest{
  Transaction: response.SignedTransaction,
 })
 if err != nil {
  log.Fatalf("could not publish transaction: %v", err)
 }
 log.Println("breach close transaction published to network")
 // Wait for the breach close transaction to be confirmed
 // TODO: implement waiting code
 log.Println("dispute complete")
}

In the scenario described above, Bob had to check the status of his payment channel continuously, or it might have been luck that he caught Alice the one time he checked his payment channel.

In most scenarios, it's advisable to use a watch tower to automate the monitoring of your payment channel and, in the case of fraudulence, publish the most recent state and a justice transaction. The watchtower does everything Bob was doing in the previous scenario.

🗼What is a Watchtower?

Watchtower is a lightning node that watches the chain on behalf of a 3rd party that can send justice transactions when it detects a breach.

🗼How the Watchtower knows it should dispute the close?

Every time the channel’s state is updated (Bob and Alice transact on the channel), Alice and Bob contact the watchtower with a status update.

The status update has a fixed-size encrypted blobs and is only able to decrypt and publish the justice transaction after the offending party has broadcast a revoked commitment state.

🗼Could the Watchtower eavesdrop?

Client communications with a watchtower are encrypted and authenticated using ephemeral (temporary) keypairs, mitigating the amount of tracking the watchtower can perform on its clients using long-term identifiers.

Below is code using LND implementation in Go to implement a watchtower.

import (
 "github.com/lightningnetwork/lnd/watchtower/client"
)
// create a client config with the necessary parameters
config := client.Config{
    DialAddr:        "localhost:9911",
    PubKey:          pubkey,
    PrivKey:         privkey,
    ChainHash:       chainhash,
    DB:              db,
    SessionBackup:   sessionBackup,
    SweepFeeRate:    sweepFeeRate,
    RewardAddress:   addr,
    Resolver:        resolver,
    Net:             net,
    EpochRegistrar:  epochRegistrar,
    DebugLogger:     logger,
    ErrorLogger:     logger,
}
// create a new watchtower client
watchtowerClient, err := client.New(config)
if err != nil {
    log.Fatalf("unable to create watchtower client: %v", err)
}
// create a new breach observer to watch for channel breaches
observer := watchtower.NewBreachObserver(watchtower.BreachObserverConfig{
    Backend:   backend,
    ChainHash: chainhash,
})
// start the observer and begin watching for breaches
if err := observer.Start(); err != nil {
    log.Fatalf("unable to start observer: %v", err)
}

Most likely, you will deal with forced closes. Collaborative closes require both nodes to always be up and running, and synchronization between the two nodes after transactions are complete.

Constant Node Uptime is Unrealistic

With node issues, network, and power outages, node uptime is a major issue. This isn't just a Bitcoin or Blockchain node issue but a major issue in tech; even giants like Amazon and Google cloud providers face these issues.

Channel Nodes are Not Always in Communication

There's a chance that one of the nodes in a payment channel goes MIA (missing in action). They may want their funds but forgot to close the channel or abandoned their node altogether. Think about all those unclaimed funds in your Venmo account. I know I am not the only one letting them sit there. Even though the other party may be happy to let their funds sit in the channel, the other party may have a greater urgency to close.

BOLT Rules on Closing Transactions

https://github.com/lightning/bolts/blob/d975de1ba5d3e8aca586154ae0cae8f1b3181495/02-peer-protocol.md?source=post_page-----a11bbe4ed486--------------------------------#channel-close

Bitcoin Lightning Transactions & Protocol Deep Dive

Ligthning Engineering

Lifecycle of a Payment Channel | Builder's Guide

At its core, a payment channel is a 2-of-2 multisignature contract between two parties holding bitcoin. While this bitcoin is held cooperatively by the two parties from the perspective of the Blockchain, each party owns a portion of it, and maintains a record of this ownership locally.

https://docs.lightning.engineering

L.N. Guide

Lightning Guide

A beginners guide to the Lightning Network

https://bitcoiner.guide

Raphael Osaze Eyerin Lightening Payment Channel

Lightning Payment Channels

Payment channels are the backbone of the Lightning Network as they enable the sending and receiving of off-chain payments. A payment channel is a trustless duplex financial relationship between two...

https://raphtyosaze.medium.com

The Bitcoin Manual

How To Close A Lightning Channel? - The Bitcoin Manual

A detailed review of to close Lightning Channels, why you would close a Lightning channel and what is involved in the various types of closes

https://thebitcoinmanual.com

BOLT to identify Justice Transactions

bolt03/breaches/is_remedy_witness.js at master · alexbosworth/bolt03

Utilities for BOLT 03. Contribute to alexbosworth/bolt03 development by creating an account on GitHub.

https://github.com

How to Set up a Watchtower for an Umbrel Bitcoin Lightening Node

www.nasdaq.com

LND Watchtower

github.com

Lightening Network Watchtower

lightningnetwork.plus

Decred Documentation on Watchtowers

docs.decred.org