Feed for tag: privacy
Potential Privacy Issue With Dual Funded Channels

Dual funding and splicing mechanisms allow initial negotiations between node to allow the node on the other end an opportunity to put funds at channel opening time or after it. Finding liquidity is a problem that had solutions suggested all the way back in November, the suggestion was, in summary, that a node will advertise initial liquidity matching via their node_announcement, this is meant to help these nodes source inbound capacity from a market of advertised liquidity rates as set by other nodes.

After a recent spec meeting, developer Rene Pickhardt noticed a potential privacy issue with this schema: a node can spam another probing for a lower bound for the amount of BTC available by this node, each time aborting the channel establishing before locking any of its own Bitcoin.

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

Blockstream Explorer Updates
Blockstream published a few updates to its block explorer that was launched last year 2018. The most obvious of the changes is the enabling of address search with unlimited transactions. Although it takes more disk space, that has led to increased search speed for the explorer. Secondly, disabling Java Script has also been made possible to allow for more browsing privacy as Java Script can be used to remove anonymity of users especially those using Tor, to improve user experience significantly. Thirdly, an API endpoint and a web form have been added to enable transaction broadcasting, a feature that developers or users who may want to easily broadcast transactions to the Bitcoin Network may find useful.
Improving payment UX with low-latency route probing

Pending payments are a common UX problem for LN that users often complain about. While the cause of this problem is not easily unraveled, there have been several issues involving stuck intermediate nodes awaiting revocation and recipients who can’t give timely preimage replies.

Fabrice Drouin proposed a change to address the issue using a faster “proceed/try another route” answer using a probe with a short timeout requirement. The system sends the blank probe request prior to sending the actual payment, via the same route.

Bustapay: a practical sender/receiver coinjoin protocol

One of the main features intended for Bitcoin in the future is a native support for multisig payments and coinjoins, they are currently supported by the Blockchain but not in a native way and as such they do not have as much efficiency and privacy as desired. This is going to be the main focus of the next major update in Bitcoin, changing the signature scheme to Schnorr Signatures.

As a simplified alternative to Pay-to-Endpoint (P2EP - Pay-to-Endpoint), developer Ryan Havar proposed a BIP for a new coinjoins protocol that does not need changes to the current Bitcoin consensus and provides a simple, practical way to make coinjoin transactions that are indistinguishable from normal ones.

Bitcoin Encrypted Communication (BIP151) Overhaul

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:

Guiding Transaction Fees Towards a more Censorship Resistant Outcome

This is summary for a submission by Ruben Somsen on bitcoin-dev on censorship resistant transactions.


Bitcoin transactions with light client wallets involve addition of transaction fees as incentive for miners to include the transaction to the blockchain through the process of mining. This creates a win-win situation.

First, without any specific conditions, miners get paid the fees provided the transaction gets included in a valid chain with the most proof-of-work.

Secondly, the user enjoys the benefit of his transaction being added to the blockchain. The fees also ensure the security of transaction on the network as miners cannot ignore the transactions or other miners will process it because it has a reward attached.

For the full node Bitcoin Core however, conditions for adding transactions to the blockchain are more specific, one of which is that transactions can only be added to a block with a block height that is one higher than the last.