Transaction relay in Bitcoin is currently a simple scheme, any node announces transactions to every peer in its list, in turn every peer announces it to its peers and so on until the whole network is updated. This is simple but not bandwidth efficient as a transaction can reach one node multiple times through multiple peers, this ensures that there is no single point of failure but is highly inefficient.

Currently any node with 8 connections would be using about 18GB of bandwidth per month, if we increase the amount of peers, further enhancing security, we increase the usage, which would discourage some users from owning a node, according to a new research paper almost 44% of all bandwidth used is redundant.

That’s why a group of Bitcoin developers and researchers created Erlay, an efficient transaction relay protocol for Bitcoin, in simple terms the protocol works by optimizing the transaction relay while maintaining the security aspects, it reduces propagated information by using an efficient set of reconciliation method, it is also designed to withstand attacks like denial of service and timing.

Routing on Lightning is an optimization problem with continuous development, developers do not only aim to reduce the computational costs and increase the privacy, they also mean to delegate route computations to other nodes in a trustless manner, lets take a look at layer 1 for an example.

Full nodes are nodes that verify transactions themselves, they hold the entire blockchain and the UTXO set which makes them able to verify any transaction based on a defined consensus and the history of the transaction inputs. On the other hand lite clients use methods such as SPV to verify the existence of a transaction in a block without downloading the block itself, they rely on other full nodes to make that CPU/Memory heavy operation for them.

The way Lightning currently works is that the sender calculates the route from its node to the receiver’s node, this means that the sender’s node must have an updated network of nodes, it might not be connected to the receiver directly but it is connected through a path in the network.

This might be fine for Lightning in its current state, but it won’t be if the number of channels expand into the millions due to adoption. Trampoline payments is a new suggested way of outsourcing that aims at having lite clients outsourcing the route computation to trampoline nodes, nodes of higher Memory, bandwidth and computation power.

Peer to Peer messaging is already applied in Bitcoin courtesy of BIP 151, but the current way it is applied is inefficient and insecure, currently messages transported are non-encrypted so message tampering, block delay attacks and BGP hijacks are all valid threats using man in the middle attacks. A new BIP is aiming at adding opportunistic encryption using ChaCha20 as a cipher and Poly1305 as a message authentication code, which has been lately getting adopted in many state of the art protocol encryption schemes such as Wireguad and tinyssh.

The computation power required for encrypting and authenticating a message using these algorithms would be almost as much the current double-SHA256 checksum.

Running a Bitcoin node is the healthiest way to contribute to the Bitcoin Network but in the past couple of years it has become very expensive to run one both in storage and bandwidth.

A process called blocksonly mode was introduced in Bitcoin 0.12 with the aim of helping Bitcoin Node owners save a hefty amount of bandwidth and still contribute to the network. blocksonly mode allows nodes to stop requesting, relaying and listening for transactions until they are bundled up in a block.

Cezary Dziemian raised a question on lightning-dev regarding channel funding:

About weak ago I talked with Christian Decker, and he told me, that there is plan to implement possibility of both-side funding channels. He told me, that I will be able (for example) to pay 100 sat for peer if he agreed to put some of his funds to channel. Everything in single, trustless transaction.

Do I understand this correctly? And if so, do you have any predictions when it could be implemented?

On of the pros of Bitcoin since its birth is that it’s a public ledger, anyone is allowed to send and receive payments and data on the Blockchain. However, Bitcoin’s network does not provide a way of encrypting communication between nodes, which allows manipulation of data, mass surveillance and analysis of its users.

Although encrypted communication is currently a possibility with VPNs, TOR or other mechanisms, it is not easy for the average user to setup such a connection. There is BIP draft called BIP151 that aims to add encrypted communication to Bitcoin’s network and which currently seems implemented only by Armory.

Jonas Schnelli presented an overhauled version for BIP 151 with some major changes:

Lightning Network is one of the key upcoming technologies that will change Bitcoin for the better, it’s a network of nodes with channels between these nodes that process payments and transactions “off-chain”, to keep only the few important transactions on-chain and decrease the load on the blockchain and the time it takes to send a transaction.

However there is a potential for node centrality in the lightning network, the main issue being that some nodes might end up functioning like banks, processing the bulk of these transactions. Developer Kulpreet Singh set out to measure the centrality of nodes in the Lightning network.