This week’s newsletter announces the 2020 Chaincode Residency program, describes two proposed routing improvements for LN, summarizes three interesting talks from the Stanford Blockchain Conference, links to popular questions and answers from the Bitcoin StackExchange, and lists several notable changes to popular Bitcoin infrastructure software.

Note: the list of releases and release candidates has been moved to its own section.

This type of circle routing would make surveillance more difficult and would eliminate the overhead for routing nodes of having to store the return path, making the protocol stateless for routing nodes. Discussion remains ongoing as of this writing, with a focus on enhancing privacy and preventing the mechanism from being abused for spam.

● LN direct messages: Rusty Russell proposed allowing LN nodes to route encrypted messages between peers without using the LN payments mechanism. This could replace current uses of messages-over-payments, such as Whatsat , with a simpler protocol that might be easier to build upon (such as for the offers idea described in Newsletter #72 ). Russell’s proposal originally specified using the same there-and-back onion routing used for LN payments (HTLCs), but developer ZmnSCPxj proposed having the message sender specify the full path from their node to the message recipient and back to the sender. For example, if Alice wants to communicate with Carol, she might choose the following path:

Several responders seemed to like the idea and began discussing how it might be implemented as well as what technical challenges it would need to overcome.

● Reverse up-front payments: as described in Newsletter #72 , LN developers have been looking for a way to charge a small fee for routing an LN payment (HTLC) even if the payment is rejected. This can discourage payments that are designed to consume bandwidth and liquidity before ultimately failing at no cost. This week, Joost Jager proposed a new scheme where up-front fees are paid from the receiver of an HTLC back towards the sender of the payment. For example, if a payment is being sent from Alice to Bob to Carol, then Alice receives a small fee from Bob and Bob receives a small fee from Carol. The fee would be proportional to the amount of time the HTLC remained pending, which would incentivize quickly routing or rejecting HTLCs and would ensure users of hold invoices (for example, Carol) paid the routing nodes (such as Bob) for tying up their routing capital.

The Stanford Center for Blockchain Research hosted its annual Stanford Blockchain Conference last week. The conference included over 30 presentations across three days. We’ve summarized three talks that we think will be of particular interest to Optech newsletter readers.

We thank the conference organizers for putting together the program and making videos of the talks available online (day 1, day 2, day 3), and Bryan Bishop for providing transcripts.

● An Axiomatic Approach to Block Rewards: Tim Roughgarden presented his work with Xi Chen and Christos Papadimitriou analyzing Bitcoin’s block reward allocation rule from a mechanism design theory perspective. (transcript, video, paper). Roughgarden began his talk by introducing mechanism design as the inverse of the better-known game theory. Game theory describes the rules of a game and then reasons about what equilibria and behavior are the result of those rules. By contrast, mechanism design starts with an intended outcome and tries to design game rules that will result in that desired outcome. Roughgarden asks “Wouldn’t it be nice if we had a mathematical description of the space of block chain protocols […] and we could [… pick our] favorite objective function and […] find a protocol that is optimal?” Roughgarden then gives three ‘axioms’ for desired behavior when designing the reward mechanism for a block chain: sybil resistance: no miner should be able to increase their reward by splitting their public identity into multiple parts. collusion resistance: no group of miners should be able to increase their reward by joining their independent identities into a single joined identity. anonymity: the reward distribution should not depend on the miners’ public identities, and if the miners’ hashrates are permuted, then the reward should be permuted in the same ways. The paper then gives a formal proof that the unique reward mechanism that satisfies these axioms is a proportional mechanism (i.e. that each miner receives rewards proportional to their hashrate). The paper only deals with the theory around the creation of a single block, and so does not consider longer-term strategies like selfish mining. The result may appear to be self-evident to people familiar with Bitcoin, but the formal treatment seems novel and may be a good basis for exploring more complex behavior for miners (eg long-term strategies and pooling behavior).

● Boomerang: Redundancy Improves Latency and Throughput in Payment-Channel Networks: Joachim Neu presented his work with Vivek Bagaria and David Tse on reducing latency and preventing liquidity lock-up when using atomic multipath payments in payment channel networks such as Bitcoin’s Lightning Network. (transcript, video, paper). Multipath payments suffer from the “everyone-waits-for-the-last” straggler problem. This concept from distributed computing describes how, if a goal depends on n tasks, then the goal must wait for the slowest of all n of those tasks to complete. In the context of a multipath payment, this means that if a payer wants to pay 0.05 BTC split into five parts of 0.01 BTC, the payment will only complete when all of those constituent parts complete. This leads to high latency for payments and reduced routing liquidity, particularly if one or more of the parts fails and needs to be retried. A common approach to fixing the straggler problem is to introduce redundancy. In our example above, this would involve the payer making seven partial payments of 0.01 BTC, and the receiver claiming the first five of those payments that successfully route. The problem then becomes how to prevent the receiver from claiming all seven parts resulting in an overpayment of 0.02 BTC. Neu et al. present a novel scheme called a boomerang contract. The receiver selects the pre-images for the payment parts as shares in a publicly verifiable secret sharing scheme. In our example above, the secret can be reconstructed from six of the seven payment pre-images. The payer then constructs the seven payment parts, but each payment part is associated with a reverse (boomerang) condition that pays the payer back the full amount if the payer knows the full secret. If the receiver claims five or fewer of the payment parts, the payer never learns the full secret, and the boomerang clause cannot be invoked, but if the receiver cheats and claims six or more of the parts, then the payer is able to invoke the boomerang clause of the contract and none of the payment parts can be redeemed by the receiver. The paper goes on to describe an implementation of boomerang contracts in Bitcoin using adaptor signatures based on a schnorr signature scheme. Neu also noted that it is possible to create adaptor signatures over ECDSA, so boomerang contracts could theoretically be implemented in Bitcoin today.