A repository of open Bitcoin research problems.
Bitcoin Problems is a community managed list of open research problems that, if solved, would have positive impact on the evolution of Bitcoin. Its purpose to help align the efforts of researchers and the needs of Bitcoin protocol developers. To contribute to the effort open an issue or pull request at the respository.
Balances of Lightning channels are not revealed during normal protocol operation. Hence LN users may have a somewhat grounded perception that their balances are private. Indeed, as LN payments are not publicly broadcast (contrary to L1 Bitcoin transactions), Lightning may be seen as not only scalability solution but also a privacy enhancing technology. In reality, however, channel balance privacy can be violated in the following scenario. The attacker sends a series of payments (probes) with randomly generated payment hashes. Each probe fails because of either insufficient balance at an intermediary hop, or because the final receiver doesn’t know the respective preimage. By distinguishing between these two cases, the attacker performs binary search over all possible positions of the balance (between zero and channel capacity).
Jamming is a denial-of-service attack on Lightning channels. The attacker initiates payments (jams) that consume the resources of routing nodes and then fail. Jamming decreases the profitability and reliability of routing nodes. The attack is cheap and difficult to prevent.
Layer-2 protocols like Lightning treat the blockchain as a dispute resolution and settlement layer. Only when their counterparty is unreachable or uncooperative does a participant have to unilaterally broadcast a transaction. Protocols like Lightning require a participant to confirm a transaction within a certain time so the coins are distributed correctly. So how can layer-2 protocol designers guarantee an opportunity to confirm time sensitive transactions to participants under reasonable assumptions? Since miners prioritize transactions based on their feerate, the only effective way is to make sure participants can control the fee of these transactions unilaterally. Ideally they should even be able to increase it after the transaction has been broadcast to the network should the original fee be insufficient.
In Point Time Locked Contract (PTLC) based Lightning channels the lock is randomized at each hop so that two malicious nodes separated by at least one honest node in a payment path cannot use the lock to determine whether the PTLCs are part of the same payment. Unfortunately, this seems to make PTLCs a little bit too unlinkable – it allows a malicious sender to create a single payment that cycles multiple times through a target pair of honest nodes significantly reducing the capacity between them for a small cost to the attacker. As in an ordinary jamming attack the malicious receiver then refuses to unlock the payment leaving the funds locked along the path until timeout. The honest nodes cannot detect the attack for the same reason that it preserves privacy: each incoming PTLC cannot be linked to any previous one.
When two lightning nodes wish to inform their peers about changes in the capacity between them they broadcast a channel_announcement or channel_update gossip message.
These messages both point to an on-chain UTXO through their short_channel_id field along with the nodes involved (and signatures from all keys).
This creates a cross-layer link between the nodes in the layer-2 network and the outputs on the layer-1 blockchain.
These cross-layer links are a privacy leak.
In Discreet Log Contracts (DLC), Dryja presents a compelling design for Bitcoin based smart contracts that settle based on real world events. Trusted third parties called oracles map the real world events to cryptographic conditions that are used to settle the bets. Unfortunately, the original work did not contain security proofs and suffers from several attacks.
Tumblers are services that offer users coin swaps in a privacy preserving way. A coin swap protocol lets Alice make a payment to Bob, not by sending it directly but instead sending the coins to Carol who sends completely unrelated coins to Bob. Coin swap protocols guarantee that no party has a way of stealing money – either Bob gets Carol’s coins and Carol gets Alice’s or the coins are returned. Blockchain observers should be unable to easily link the payment from Alice to Carol with the payment from Carol to Bob.