A BIP proposal for 'cancellable' transactions

Alejandro Ranchal Pedrosa and Tucci-Piergiovanni proposed a new BIP to extend OP_CSV1 and/or OP_CLTV2 to allow and interpret negative values.

The discussion that followed concluded that the BIP would be breaking a fundamental rule which is that valid transactions remain valid. This could lead to loss of funds when several transactions are made invalid.

Plasma Scalable Autonomous Smart Contracts

This week’s paper pick was recently published by Joseph Poon and Vitalik Buterin and introduces a framework that allows highly scalable smart contracts:

Plasma is a proposed framework for incentivized and enforced execution of smart contracts which is scalable to a significant amount of state updates per second (potentially billions) enabling the blockchain to be able to represent a significant amount of decentralized financial applications worldwide. These smart contracts are incentivized to continue operation autonomously via network transaction fees, which is ultimately reliant upon the underlying blockchain (e.g. Ethereum) to enforce transactional state transitions.


[Paper Pick] Preventing Abuse in a Lightning-based Peer-to-Peer Exchange

This week’s brings two papers from the same team on the topic of preventing delay abuse within lightning p2p exchanges:

  1. A trusted latency monitor service, for preventing abuse in a Lightning-based peer-to-peer exchange. link

  2. Preventing transaction delays with a Lightning routing service, for preventing abuse in a Lightning-based peer-to-peer exchange. link

We covered this subject here and here.

Scriptless Scripts With ECDSA

Pedro Moreno Sanchez via Bitcoin Dev linked the following paper, Multi-Hop Locks for Secure, Privacy-Preserving and Interoperable Payment-Channel Networks.

…my co-authors and I have been working hard to get ready an extended version of the paper for this work…

In this paper, we describe in detail the scriptless script (SS) ECDSA construction and formally prove its security and privacy guarantees. Additionally, we describe several other constructions of interest for the LN:

-The SS Schnorr, initially proposed by A. Poelstra. We formally describe the protocol and prove its security and privacy guarantees

-Interestingly, we show that it is possible to combine SS ECDSA and SS Schnorr without losing security or privacy. This allows interoperability between different implementations.

-A framework to combine script-based cryptographic locks using partially homomorphic one-way functions.

-Possible applications. For instance, SS ECDSA could be used today in Bitcoin to perform atomic swaps where the resulting transaction no longer reveals the cryptographic condition. Instead, it is embedded in a regular ECDSA signature. This provides several advantages such as reduced transaction size and better privacy/fungibility among others.

A cornerstone of their approach is to provide interoperability between different signature schemes. The utility of such an approach is a form of “cryptographic future-proofing” where if one scheme is broken there are fall-back functions that are still secure.

[Paper Pick] Scalable Funding of Bitcoin Micropayment Channel Networks

This week’s paper is Blockstream proposed solution for scaling lighthning by enabling trust-less off-blockchain channel funding.


The Bitcoin network has scalability problems. To increase its transaction rate and speed, micropayment channel networks have been proposed, however these require to lock funds into specific channels. Moreover, the available space in the blockchain does not allow scaling to a world wide payment system. We propose a new layer that sits in between the blockchain and the payment channels. The new layer addresses the scalability problem by enabling trust-less off-blockchain channel funding.

[Paper Pick] Eltoo a Simple Layer2 Protocol for Bitcoin

This was published alongside the new Eltoo lightning update mechanism by blockstream.

From the abstract:

Bitcoin, and other blockchain based systems, are inherently limited in their scalability. On-chain payments must be verified and stored by every node in the network, meaning that the node with the least re- sources limits the overall throughput of the system as a whole. Layer 2, also called off-chain protocols, are often seen as the solution to these scalability issues: by renegotiating a shared state among a limited set of participants, and not broadcasting the vast majority of state up- dates to the blockchain, the load on the network is reduced. Central to all Layer 2 protocols is the issue of guaranteeing that an old state may not be committed once it has been replaced. In this work we present eltoo, a simple, yet powerful replacement mechanism for Layer 2 protocols. It introduces the idea of state numbers, an on-chain en- forceable variant of sequence numbers that were already present in the original implementation, but that were not enforceable.

[Paper Pick] Quantum Blockchain Using Entanglement in Time

This week’s paper pick, published by Del Rajan and Matt Visser from Victoria University of Wellington on April 17, 2018, is a conceptual design for a quantum blockchain.

A conceptual design for a quantum blockchain is proposed. Our method involves encoding the blockchain into a temporal GHZ (Greenberger–Horne–Zeilinger) state of photons that do not simul- taneously coexist. It is shown that the entanglement in time, as opposed to an entanglement in space, provides the crucial quantum advantage. All the subcomponents of this system have already been shown to be experimentally realized. Perhaps more shockingly, our encoding procedure can be interpreted as non-classically influencing the past; hence this decentralized quantum blockchain can be viewed as a quantum networked time machine.

[Paper Pick] Privacy Preserving Proofs of Solvency for Bitcoin Exchanges

This is the first brief in a new series called Paper Pick that will occasionally allow our readers to discover published papers related to Bitcoin technology.

This week’s paper pick, published on Oct 26, 2015, is a privacy-preserving proof of solvency for bitcoin exchanges that does not disclose the exchange’s Bitcoin address, its total holdings or liabilities, or any information about its customers.

Bitcoin exchanges function like banks, securely holding their customers’ bitcoins on their behalf. Several exchanges have suffered catastrophic losses with customers permanently losing their savings. A proof of solvency demonstrates that the exchange controls sufficient reserves to settle each customer’s account. We introduce Provisions , a privacy-preserving proof of solvency whereby an exchange does not have to disclose its Bitcoin addresses; total holdings or liabilities; or any information about its cus- tomers. We also propose an extension which prevents exchanges from colluding to cover for each other’s losses. We have implemented Provisions and show that it offers practical computation times and proof sizes even for a large Bitcoin exchange with millions of customers.

If you want to share a paper to include on our weekly briefs, feel free to contact us at authors@bitcointechweekly.com

Monero Transaction Traceability

Monero is one of the leading privacy coins on the market. A recent paper called An Empirical Analysis of Traceability in the Monero Blockchain argued that it might not be as private as expected.

In this paper, we empirically evaluate two weaknesses in Monero’s mixin sampling strategy. First, about 62% of transaction inputs with one or more mixins are vulnerable to “chain-reaction” analysis — that is, the real input can be deduced by elimination. Second, Monero mixins are sampled in such a way that they can be easily distinguished from the real coins by their age distribution; in short, the real input is usually the “newest” input.

However some of the issues addressed in the paper have already been addressed by the monero dev team.

Velvet Forks
Blockchain forks have been a controversial subjects since the dawn of bitcoin, there’s two types of forks, one is called a soft fork, this adds more restrictions to the consensus on which the blocks are verified, a block that was deemed valid before the soft fork can be deemed invalid after it, while the other type of fork is called a hard forkm, and it is exactly the opposite, a hard fork loseens the restrictions on which the blocks are verified, so that a block that was deemed invalid before the hard fork can be deemed valid.