Bitcoin Optech Newsletter #129: 2020 Year-in-Review Special Bitcoin Optech

This special edition of the Optech Newsletter summarizes notable developments in Bitcoin during all of 2020. It’s the sequel to our summaries from 2018 and 2019.

As we’ve done in our previous annual summaries, we must prefix what
you’re about to read with an apology. Many more people worked on both
maintaining and improving Bitcoin’s technology than we could possibly
ever write about. Their fundamental research, code review, bug fixes,
test writing, administrative work, and other thankless activities may
not be described here—but it is not unacknowledged. If you contributed
to Bitcoin in 2020, please accept our deepest thanks.

Contents

• January
  • DLC specification, implementations, and usage
• February
  • LN large channels
  • LN dual funding and interactive funding
  • LN blinded paths
• March
  • Exfiltration resistant signing
• April
  • Payjoin
  • LN PTLCs and other cryptography-based improvements
  • BIP85 keychains
  • Vaults
• May
  • Transaction origin privacy
  • Succinct atomic swaps
  • Coinswap implementation
  • Compact block filters
• June
  • Overpayment attack on multi-input segwit transactions
  • LN payment atomicity attack
  • Fast LN eclipse attacks
  • LN fee ransom
  • HTLC mining incentives
  • Inventory out-of-memory denial-of-service attack
  • WabiSabi coordinated coinjoins with arbitrary output amounts
• July
  • WTXID transaction announcements
• August
  • Signet
  • LN anchor outputs
• September
  • Faster signature verification
  • Patent alliance
• October
  • LN jamming attacks
  • LND security disclosures
  • Generic signmessage
  • MuSig2
  • Version 2 addr messages
• November
  • Lightning Pool incoming channel marketplace
• December
  • LN offers
• Featured summaries
  • Taproot, tapscript, and schnorr signatures
  • Major releases of popular infrastructure projects
  • Bitcoin Optech

January

Several developers began working on a specification for using Discreet Log Contracts (DLCs) between different
software. DLCs are a contract protocol where two or more parties agree
to exchange money dependent on the outcome of a certain event as
determined by an oracle (or several oracles). After the event happens,
the oracle publishes a commitment to the outcome of the event
that the winning party can use to claim
their funds. The oracle doesn’t need to know the terms of the contract
(or even that there is a contract). The contract can be made
indistinguishable from many other Bitcoin transactions or it can be
executed within an LN channel. This makes DLCs more private and
efficient than other known oracle-based contract methods, and it’s
arguably more secure as an oracle that commits to a false
result generates clear evidence of fraud. By the end of the year,
there would be four compatible implementations of DLCs, an
application for offering and accepting
DLC-based peer-to-peer derivatives, and several users reporting that they’d used DLCs in transactions on mainnet.

February

Five years after the first public presentation about LN, several early protocol decisions meant to be temporary were
revisited. The most immediate change was the February update to the LN specification that allowed users to opt out of the
maximum channel and payment value limits enacted
in 2016.

Another early decision that saw reconsideration was keeping the protocol
simple by opening all channels with a single funder. This minimizes
protocol complexity but prevents channel funders from receiving any
payments until they’ve spent some of their funds—a position that
creates barriers to merchants joining LN. One proposal to eliminate
this problem is dual-funded channels where both the channel opener and
their counterparty commit some amount of funds to the channel.
Lisa Neigut has developed a protocol for dual funding, but
(as expected) it’s complex. In February, she started a
discussion about an incremental
improvement over the existing single-funder standard that would allow
interactive construction of the funding transaction. Instead of the
current case where one party proposes a channel open and the other party
either accepts it or rejects it, the nodes belonging to the two parties
could exchange information about their preferences and negotiate opening
a channel that they would both find desirable.

New progress was also made on the often-discussed plans to allow
rendez-vous routing for LN, which was labeled a priority during the
2018 LN specification meeting. A new method for achieving
equivalent privacy was described by Bastien
Teinturier in February based on a previous privacy enhancement he had
proposed. This new method, called blinded paths, was later
implemented as an experimental feature in C-Lightning.

March

One method hardware wallets could use to steal bitcoins from their users is by
leaking information about the wallet’s private keys via the transaction
signatures it creates. In March, Stepan Snigirev,
Pieter Wuille, and several others discussed
possible solutions to this problem for both Bitcoin’s current ECDSA
signature system and the proposed schnorr signature system.

April

The payjoin protocol based on the 2018 Pay-to-EndPoint
proposal received a major boost in April when a version of
it was added to the BTCPay self-hosted payment
processing system. Payjoin provides a convenient way for users to
increase their privacy and the privacy of other users on the network by
creating transactions that undermine the assumption that the same person
owns all of the inputs in a transaction. The BTCPay version of payjoin
would soon be specified as BIP78 and support for
it was added to other programs.

One widely desired improvement to LN is switching the payment security
mechanism from Hash Time Locked Contracts (HTLCs) to Point
Time Locked Contracts (PTLCs) that improve the privacy of
spenders and receivers against a variety of surveillance methods. One
complication is that the ideal multiparty PTLC construction is
challenging to implement using Bitcoin’s existing ECDSA signature
scheme (although it’d be easier with schnorr signatures). Early in the year, Lloyd Fournier circulated a
paper analyzing signature adaptors by disentangling their core locking and information exchange
properties from their use of multiparty signatures, describing an easy
way to use plain Bitcoin Script-based multisig instead. During an April
hackathon, several developers produced a rough
implementation of this protocol for a fork of the popular libsecp256k1
library. Later, in September, Fourier would further advance the
practicality of PTLCs without needing to wait for changes to Bitcoin by
proposing a different way to construct LN commitment transactions. In December, he would
propose two new ways to improve the robustness
of LN backups, again offering practical solutions to user problems
through the clever use of cryptography.

April also saw Ethan Kosakovsky post a proposal
to the Bitcoin-Dev mailing list for using one BIP32 Hierarchical
Deterministic (HD) keychain to create seeds for child HD keychains that
can be used in different contexts. This may address the problem that
many wallets don’t implement the ability to import extended private keys
(xprvs)—they only allow importing either an HD seed or some precursor
data that is transformed into the seed (e.g. BIP39 or SLIP39 seed
words). The proposal allows a user with multiple wallets to backup all
of them using just the super-keychain’s seed. This proposal would
later become BIP85 and would be implemented in
recent versions of the ColdCard hardware wallet.

Two announcements about vaults were made in April. Vaults
are a type of contract known as a covenant that produces a warning
when someone is trying to spend the covenant’s funds, giving
the covenant’s owner time to block a spend they didn’t authorize. Bryan Bishop announced a prototype
vault based on his proposal
from last year. Kevin Loaec and Antoine Poinsot announced their own
project, Revault, that focuses
on using the vault model to store funds shared between multiple users
with multisig security. Jeremy Rubin also announced a new high level
programming language designed for building stateful
smart contracts with the proposed OP_CHECKTEMPLATEVERIFY opcode, which could make it easier to create and
manage vaults.

May

The Bitcoin Core project merged several PRs in May and the following
months that improved transaction origin privacy, both
for users of the Bitcoin Core wallet and for users of other systems.
Bitcoin Core #18038 began tracking whether at
least one peer had accepted a locally-generated transaction, allowing
the wallet to significantly reduce the frequency Bitcoin Core used to
rebroadcast its own transactions and making it harder for surveillance
nodes to identify which node originated the transaction. PRs
#18861 and #19109 were
able to block a type of active scanning by
surveillance nodes by only replying to requests for
a transaction from peers the node told about the transaction, further
reducing the ability of third parties to determine which node first
broadcast a transaction. PRs #14582 and
#19743 allow the wallet to automatically
try to eliminate address reuse links when it wouldn’t cost the user any extra fees (or, alternatively,
allowing the user to specify the maximum extra they’re willing to spend
in order to eliminate such links).

Late May and early June saw two significant developments in coinswaps.
Coinswap is a trustless protocol that allows two or more users to create
transactions that look like regular payments but which actually swap
their coins with each other. This improves the privacy of not just the
coinswap users but all Bitcoin users, as anything that looks like a
payment could have instead been a coinswap.

• ● Succinct Atomic Swaps (SAS): Ruben Somsen wrote a post and created
  a video describing a procedure for a trustless exchange
  of coins using only two transactions. The protocol has several
  advantages over earlier coinswap designs: it requires less block space, it
  saves on transaction fees, it only requires consensus-enforced
  timelocks on one of the chains in a cross-chain swap, and it doesn’t
  depend on any new security assumptions or Bitcoin consensus changes.
  If taproot is adopted, swaps can be made even more privately and
  efficiently.

• ● Coinswap implementation: Chris Belcher posted
  a design for a full-featured coinswap implementation. His initial
  post included the history of the coinswap idea,
  suggested ways the multisig conditions needed for coinswap could be
  disguised as more common transaction types, proposed using a market
  for liquidity (like JoinMarket already does), described splitting and
  routing techniques to reduce privacy losses from amount correlation or
  spying participants, suggested combining coinswap with payjoin, and discussed some of the backend requirements for the
  system. Additionally, he compared coinswap to other privacy
  techniques such as using LN, coinjoin, payjoin, and
  payswap. The proposal received a significant amount of expert discussion and a number of
  suggestions were integrated into the protocol. By December, Belcher’s
  prototype software was creating coinswaps on
  testnet that demonstrated their strong lack of linkability.

Since Bitcoin’s early days, one of the challenges of developing
lightweight clients with SPV security has been finding a way for the
client to download transactions affecting its wallet without giving the
third party server providing the transactions the ability to track the
wallet’s receiving and spending history. An initial attempt at this was
BIP37-style bloom filters, but
the way wallets used them ended up providing only minimal privacy and created denial of service risks for the full nodes that served them. An anonymous developer
posted to the Bitcoin-Dev mailing list in May 2016 suggesting an
alternative construction of a single bloom filter per block
that all wallets could use. The idea was quickly refined, implemented, and specified,
becoming the BIP157 and BIP158 specifications of compact block
filters. This can significantly improve
the privacy of lightweight clients, although it does increase their
bandwidth, CPU, and memory requirements compared to current popular
methods. For full nodes, it reduces the DoS risk to that of a simple
bandwidth exhaustion attack, which nodes can already address with
bandwidth throttling options. Although merged on the server side in
btcd in 2018 and proposed for Bitcoin Core around the same
time, 2020 saw the P2P part of the protocol merged piecewise into Bitcoin Core in May through
August, culminating with the ability for a node
operator to opt in to creating and serving compact block filters by
enabling just two configuration options.

June

June was an especially active month for the discovery and discussion of
vulnerabilities, although many problems were discovered earlier or fully
disclosed later. The notable vulnerabilities included:

• ● Overpayment attack on multi-input segwit transactions:
  in June, Trezor announced Saleem Rashid had discovered a weakness in
  segwit’s ability to prevent fee overpayment attacks. Fee overpayment
  attacks are a well known weakness in Bitcoin’s original transaction
  format where signatures don’t commit to the value of an input,
  allowing an attacker to trick a dedicated signing device (such as a
  hardware wallet) into spending more money than expected. Segwit tried
  to eliminate this issue by having each signature commit to the amount
  of the input it spent. However, Rashid re-discovered a problem
  previously discovered and reported by Gregory Sanders in 2017 where a specially
  constructed transaction with at least two inputs can get around this
  limitation if the user can be tricked into signing two or more
  seemingly identical variations of the same transaction. Several
  developers felt this was a minor issue—if you can get a user to sign
  twice, you can get them to pay the receiver twice, which also loses
  their money. Despite that, several hardware wallet manufacturers
  released new firmware that implemented the same protection for segwit
  transactions that they’ve successfully used to prevent fee
  overpayments in legacy transactions. In some cases, such as in the
  ColdCard wallet, this security improvement was implemented
  non-disruptively. In other hardware wallets, the implementation broke
  support with existing workflows, forcing updates to the BIP174
  specification of PSBT and software such as Electrum, Bitcoin Core, and
  HWI.

  

• ● LN payment atomicity attack: as LN developers
  worked to implement the anchor outputs
  protocol to eliminate risks related to rapid rises in transaction
  feerates, one of the key contributors to that protocol—Matt
  Corallo—discovered it would enable a new vulnerability. A malicious
  counterparty could attempt to settle an LN payment (HTLC) using a low feerate and a transaction pinning technique that prevents the transaction or a fee
  bump of it from being confirmed quickly. The delayed confirmation
  causes the HTLC’s timeout to expire, allowing the attacker to steal
  back funds they paid to the honest counterparty. Several solutions
  were proposed, from changes to the LN
  protocol, to third-party markets, to soft fork consensus
  changes, but no solution has yet gained any
  significant traction.

• ● Fast LN eclipse attacks: although Bitcoin
  protocol experts from Satoshi Nakamoto to present have been aware that
  a node isolated from any honest peer can be deceived into accepting
  unspendable bitcoins, a category of problems sometimes called eclipse
  attacks, Gleb Naumenko and Antoine Riard
  published a paper in June showing that eclipse attacks could steal
  from LN nodes in as little as two hours—although it would take
  longer to steal from LN nodes that were connected to their own full
  verification nodes.
  The authors suggest the implementation of more methods for avoiding
  eclipse attacks, which did see several positive developments in the
  Bitcoin Core project this year.

• ● LN fee ransom: René Pickhardt publicly
  disclosed a vulnerability to the Lightning-Dev mailing list that he
  had previously privately reported to LN implementation maintainers
  almost a year earlier. A malicious channel counterparty can initiate
  up to 483 payments (HTLCs) in an LN channel and then close the
  channel, producing an onchain transaction whose size is about 2% of an
  entire block and which needs to have its transaction fee paid by the
  honest node. Simple mitigations for this attack were implemented in
  several LN nodes and the use of anchor outputs
  is also expected to help, but no comprehensive solution has yet been
  proposed.

• ● Concern about HTLC mining incentives: two
  papers about out-of-band HTLC bribes were discussed in late June and
  early July. HTLCs are contracts used to secure LN
  payments, cross-chain atomic swaps, and several other trustless
  exchange protocols. They work by giving a receiving user a period of
  time where they have the exclusive ability to claim a payment by
  releasing a secret data string; after the time expires, the spending
  user can take back the payment. The papers examined the risk that
  the spending user could bribe miners to release the secret data but
  not confirm the transaction containing it, allowing the timelock to
  expire so that the spender would get their money back but still learn
  the secret. Developer ZmnSCPxj reminded the researchers of a
  well known mechanism that should prevent such problems, a mechanism he
  helped implement in C-Lightning. Although the idea
  works in theory, using it will cost users money, so research into
  better solutions is still encouraged.

• ● Inventory out-of-memory Denial-of-Service attack (InvDoS):
  an attack originally discovered in 2018 that affected the Bcoin and
  Bitcoin Core full nodes, which was responsibly disclosed
  and fixed at that time, was reevaluated in June 2020 and found to also
  apply to the Btcd full node. An attacker could flood a victim’s node
  with an excessive number of new transaction announcements (inv
  messages), each containing nearly the maximum allowed number of
  transaction hashes. When too many of these announcements were queued,
  the victim’s node would run out of memory and crash. After Btcd fixed
  the problem and users were given time to upgrade, the vulnerability
  was publicly disclosed.

June also had some good news, with a team of researchers working on the
Wasabi coinjoin implementation announcing a protocol
named WabiSabi that should allow
trustless server-coordinated coinjoins with arbitrary output values.
This makes it easier to use coordinated coinjoins to send payments,
either between participants in the coinjoin or to non-participants.
Wasabi developers worked on implementing the protocol during the
remainder of the year.

July

July saw the merge of the BIP339 specification for wtxid
transaction announcements. Nodes have historically announced the
availability of new unconfirmed transactions for relay using the
transaction’s hash-based identifier (txid), but when the proposed segwit
code was being reviewed in 2016, Peter Todd discovered that a malicious node could get other nodes on the network to
ignore an innocent user’s transaction by invalidating witness data in the transaction
that is not part of its txid. A quick
fix was implemented at the time, but it had some
minor downsides and developers knew that the best solution—despite its
complexities—was to announce new transactions using their
witness txid (wtxid). Within a month of BIP339 being added to the BIPs
repository, wtxid announcements were merged into Bitcoin
Core. Although seemingly a minor concern without any obvious effect on
users, wtxid announcements simplify the development of
hoped-for upgrades, such as package relay.

August

After over a year of development, including multiple feedback-driven changes, the last
major revision to the BIP325 specification of
signet was merged in early August. Signet is a protocol
that allows developers to create public test networks and also the name
of the primary public signet. Unlike Bitcoin’s existing public test
network (testnet), signet blocks must be signed by a trusted party.
This prevents vandalism and other problems that occur because testnet
uses Bitcoin’s economic-based consensus convergence mechanism (proof of
work) even though testnet coins have no value. The ability to
optionally enable signet was finally added to Bitcoin Core
in September.

Almost two years after Matt Corallo first proposed the CPFP carve-out mechanism, the LN
specification was updated to allow the creation of
anchor outputs that use carve outs for security.
Anchor outputs allow a multiparty transaction to be fee bumped even if
one of the parties attempts to use a transaction pinning attack to prevent fee bumps. The ability to fee
bump transactions even under adversarial conditions allows LN nodes to
accept offchain transactions without worrying about feerates increasing in
the future. If it later becomes necessary to broadcast that offchain
transaction, the node can choose an appropriate feerate for it at
broadcast time. This simplifies the LN protocol and improves several
aspects of its security.

September

In a 2011 forum post, early Bitcoin contributor Hal Finney
described a method by Gallant, Lambert, and Vanstone (GLV) to reduce the
number of expensive computations needed to verify Bitcoin transaction
signatures. Finney wrote a proof-of-concept implementation, which he
claimed sped up signature verification by around 25%. Unfortunately,
the algorithm was encumbered by U.S. Patent 7,110,538 and so
neither Finney’s implementation nor a later implementation by Pieter
Wuille was distributed to users. On September 25th, that patent
expired. Within a month, the code was merged into Bitcoin Core. For users with the default settings, the speed
improvement will be most apparent during the final part of syncing a new
node or when verifying blocks after a node has been offline for a while.
Finney died in 2014, but we remain grateful for his two decades of work
on making cryptographic technology widely accessible.

Square announced the formation of the Cryptocurrency Open Patent Alliance (COPA) to
coordinate the pooling of patents related to cryptocurrency technology.
Members allow anyone to use their patents freely and, in exchange,
receive the ability to use patents in the pool in defense against patent
aggressors. As of this writing, the alliance had 18 members: ARK.io, Bithyve, Blockchain Commons, Blockstack,
Blockstream, Carnes Validadas, Cloudeya Ltd., Coinbase, Foundation
Devices, Horizontal Systems, Kraken, Mercury Cash, Protocol Labs,
Request Network, SatoshiLabs, Square, Transparent Systems, and
VerifyChain.

October

October saw a significant increase in discussion among LN developers
about solving the jamming problem first described in 2015, as well
as related problems. An LN node can route a payment to itself across a
path of 20 or more hops. This allows an attacker with 1 BTC to
temporarily lock up 20 BTC or more belonging to other users. After
several hours of locking other users’ money, the attacker can cancel the
payment and receive a complete refund on their fees, making the attack
essentially free. A related problem is an attacker sending 483 small
payments through a series of channels, where 483 is the maximum number
of pending payments a channel may contain. In this case, an attacker
with two channels, each with 483 slots, can jam over 10,000 honest
connection slots—again without paying any fees. A variety of possible solutions were discussed, including forward upfront
fees paid from the spender to each node along the path, backwards
upfront fees paid from each payment hop to
the previous hop, a combination of both forward
and backwards fees, nested incremental routing, and fidelity bonds. Unfortunately,
none of the methods discussed received widespread acceptance and so the
problem remains unsolved.

Two money-stealing attacks against LND that were discovered and reported
by Antoine Riard in April were fully disclosed in October. In one case, LND could be tricked into
accepting invalid data; in the other case, it could be tricked into
disclosing secret data. Thanks to Riard’s responsible disclosure and
the LND team’s response, we are unaware of any users who lost funds.
The LN specification was updated for both problems to help new implementations avoid them.

Over five years after the introduction of the initial segwit proposal,
and three years after its activation, there remains no universal way to
create and verify plain text messages signed using the keys that
correspond to a P2WPKH or P2SH-P2WPKH address. The problem exists more
generically as well: there’s no widely supported way to handle messages
for P2SH, P2WSH, and P2SH-P2WSH addresses either—nor a forward
compatible way that will work for taproot addresses. The BIP322
proposal for a generic signmessage function
is an attempt to fix all of these issues, but it’s failed to gain much
traction. This year saw an additional request for feedback from its champion, a simplification, and (in October) a nearly complete
replacement of its core mechanism.
The new mechanism makes message
signing potentially compatible with a large amount of existing software
and hardware wallets, as well as the PSBT data format, by
allowing the signing of virtual transactions that look like real
transactions but which can be safely signed because they aren’t valid
according to Bitcoin’s consensus rules. Hopefully, this improvement will
allow generic signmessage to start to receive adoption.

Jonas Nick, Tim Ruffing, and Yannick Seurin published
the MuSig2 paper in October describing a new variant of the
MuSig signature scheme with a two round signing protocol
and no need for a zero-knowledge proof. What’s more, the first round
(nonce exchange) can be done at key setup time with a non-interactive
signing variant that could be particularly useful for cold storage and
offchain contract protocols such as LN.

Also in October, Bitcoin Core became the first project to
merge an implementation of the version 2 addr
message. The addr message advertises the network
addresses of potential peers, allowing full nodes to discover new peers
without any centralized coordination. The original Bitcoin addr
message was designed to hold 128-bit IPv6 addresses, which also allowed
it to contain encoded IPv4 addresses and version 2 Tor onion addresses.
After almost 15 years in production, the Tor project deprecated version
2 onion services and will stop supporting them in July 2021. Newer
version 3 onion addresses are 256 bits, so they’re not usable with the
original addr messages. The BIP155 upgrade of the addr message
provides more capacity for Tor addresses and also makes it possible to use
other anonymity networks that require larger addresses.

November

As mentioned in the February section, one challenge faced in the current
LN network is that users and merchants need channels with incoming
capacity in order to receive funds over LN. A fully
decentralized solution to that problem could be the dual-funded channels
described earlier. However, in November, Lightning Labs took a
different track and announced a new Lightning
Pool marketplace for buying incoming LN channels. Some existing node
operators already provide incoming channels, either for free or as a
paid service, but Lightning Pool may be able to use its centrally
coordinated marketplace to make this service more standardized and
competitive. It’s possible this could also be upgraded to work with
dual funded channels when they become available.

December

Last year, Rusty Russell published a first draft of a proposed
specification for LN offers, the ability for a spending
node to request an invoice from a receiving node over the onion-routed
LN network. Although the existing BOLT11 provides an invoice
protocol, it doesn’t allow for any protocol-level negotiation between
the spender and receiver nodes. Offers would make it possible for the
nodes to communicate additional information and automate payment steps
that currently require manual intervention or additional tools. For
example, offers could allow LN nodes to manage recurring payments or
donations by having a spender node request a new invoice each month from
a receiver node. In December 2020, the first in a series of commits by
Russell to C-Lightning for implementing offers was merged.

Conclusion

One of the things we love about summarizing the past year’s events is
that every bit of progress is fully realized. The summary above does
not contain promises about what Bitcoin will do in the future—it lists
only actual accomplishments achieved in the past 12 months. Bitcoin
contributors have a lot to be proud of in 2020. We can’t wait to see
what they have in store for us in 2021.

The Optech newsletter will return to its regular Wednesday publication
schedule on January 6th.

—Source link—