Feed for tag: p2p
Erlay: Bandwidth-Efficient Transaction Relay for Bitcoin

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.

[BIP Proposal] Peer to Peer Message Transport Protocol V2

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.

Major Upgrade v0.9.4 for Bisq, the Decentralized Bitcoin Exchange

The Decentralized exchange BISQ recently rolled out a series of new upgrades including a twofold increase in trade limits for altcoins bringing the total trade limit to 2 BTC.

The release also fixes wallet and startup bugs and issues that were recently reported by users. The updates also include many improvements to Bisq DAO, a decentralized anonymous organiztion running over the testnet Bitcoin network.

The full details of the release can be found here

Proposal for Syncing Channel Updates
An update was suggested to include channel update timestamps to the channel range queries, the reply_channel_range will now include 4 bytes of a timestamp and the query_short_channel_ids will include a flag that is set to 1 if the node should send back a channel announcement and the updates, and would otherwise send just the updates.
Building a Bitcoin API and Query System

Currently, in order to get information on a Bitcoin block or transaction, one has to sync his node with other nodes in a P2P network to be able to query the block for the information required.

Sumit Lahiri presented a BIP proposal to build an API that enables users to “easily query Bitcoin blocks and transactions” without having to sync with other nodes on the network.

One of the issues with the proposal is that light clients like Electrum, Spruned and Bitcore offer most if not all of the functionalities because the “servers are designed to quickly answer the query of light client wallets”.

Preventing Delay Abuse in a Lightning Based Peer-to-Peer Exchange

Corné Plooy discussed a potential solution to prevent delay abuse in lightning based P2P exchange:

Lately I’ve been thinking about de-centralized crypto/crypto exchange (“atomic swap”) on the Lightning network. In my view, the main problem is that participants can delay transactions (up to HTLC time-out, which can be quite long), in order to speculate on exchange rate changes. I’ve been looking for several approaches to deal with this problem.