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.



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.


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.


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.

2020 summary
Taproot, tapscript, and schnorr signatures

Nearly every month of 2020 saw some notable development related to the
proposed taproot soft fork (BIP341) which also adds
support for schnorr signatures (BIP340)
and tapscript (BIP342). Together, these
improvements will allow users of single-signature scripts,
multisignature scripts, and complex contracts to all use
identical-appearing commitments that enhance their privacy and the
fungibility of all bitcoins. Spenders will enjoy lower fees and the
ability to resolve many multisig scripts and complex contracts with the
same efficiency, low fees, and large anonymity set as single-sig users.
Taproot and schnorr also lay the groundwork for future potential
upgrades that may improve efficiency, privacy, and fungibility further,
such as signature aggregation, SIGHASH_ANYPREVOUT, and scripting language changes.

This special section concentrates the summaries about those developments
into a single narrative that we hope will be easier to follow than
describing each event separately in the month it occurred.

January started with a discussion of soft fork activation mechanisms,
with Matt Corallo proposing a careful and patient
approach to addressing disagreements between different sets of
stakeholders. Other developers focused on the BIP8 proposal to be
able to quickly bypass the type of procedural problem that delayed
segwit activation in 2016 and 2017. The discussion about what precise
activation mechanism to use would continue all year, in a dedicated IRC
and elsewhere, with there being both a
developer survey about mechanism design and a
survey of miners about their support for

February saw the first of several updates during the year to the
algorithms used to derive public keys and signatures in the BIP340
specification of schnorr signatures. Most of
these changes were small optimizations discovered from
experience implementing and testing the
proposal in libsecp256k1 and its experimental fork
libsecp256k1-zkp. Also in February, Lloyd Fournier
extended Andrew Poelstra’s previous
security proof for taproot.

In March, Bitcoin Core carefully changed its consensus
code—without introducing a fork—to remove an inefficiency in the
parsing of OP_IF and related flow control opcodes. Currently, the
inefficiency can’t be exploited to cause problems, but the extended
capabilities proposed for tapscript would have made it possible for an
attacker to use the inefficiency to create blocks that could take a
large amount of computation to verify.

Although much of the public attention on taproot focuses on its change
to Bitcoin’s consensus rules, taproot won’t be a positive contribution unless
wallet developers can use it safely. In April, and throughout the year,
several updates to BIP340 changed the recommendations for
how developers should generate public keys
and the signature nonce. The changes are probably only directly
interesting to cryptographers, but the history of Bitcoin has many
examples of people losing money because a wallet developer didn’t fully
understand the cryptographic protocol they implemented. Hopefully, the
recommendations from experienced cryptographers in BIP340 will help
avoid some of those types of problems in the future.

In May, there was renewed discussion about
the blinded ownership attack that makes it
dangerous to automatically sign transactions with a hardware wallet.
Ideally, hardware wallets could provide a mode where they’d automatically
sign transactions guaranteed to increase the wallet’s balance, such as
maker coinjoins and LN splices. Unfortunately, it’s
only safe to sign a transaction if you know for sure which inputs are
yours—otherwise an attacker can get you to sign a transaction that
looks like it only has one of your inputs, then get you to sign a
different version of the same transaction that also looks like it only
has one of your inputs (a different input than the first version), and
finally combine the signatures for the two different inputs into the
actual transaction that pays your money to the attacker. This
isn’t normally a risk because most people today only use hardware
wallets to sign transactions where they own 100% of the inputs, but for
coinjoins, LN splices, and other protocols, it’s expected that other users
may partly or fully control some of the inputs. It was proposed that
taproot provide an additional way to commit to inputs that can be used
in conjunction with data provided in a PSBT to ensure a
hardware wallet will only generate a valid signature when it has enough
data to identify all of its inputs. This proposal was later
accepted into BIP341.

Illustration of using a fake coinjoin to trick a hardware wallet into losing funds

In July, another discussion resumed about a previously known problem—the
bech32 address format being less effective than
expected at preventing users from sending money to unspendable
addresses. This doesn’t practically affect current bech32 address
users, but it could be an issue for planned taproot addresses where the
addition or removal of a small number of characters could lead to the
loss of funds. Last year it was proposed to simply extend the
protection current segwit v0 addresses have to segwit v1 (taproot)
addresses, but that would reduce the flexibility of future upgrades.
This year, after more research and debate, there seemed to be
agreement among developers that taproot and future segwit-based script
upgrades should use a new address format that’s a slight tweak on the
original BIP173 bech32 addresses. The new format will resolve the
deficiency and provide some other nice properties.

In September, the code implementing schnorr signature verification and
single-party signing functions from BIP340 was merged into libsecp256k1 and soon became part of Bitcoin
Core. This allowed the subsequent October merge of the verification code for taproot, schnorr, and tapscript.
The code consists of about 700 lines of consensus-related changes (500
excluding comments and whitespace) and 2,100 lines of tests. Over 30
people directly reviewed this PR and related changes, and many others
participated in developing and reviewing the underlying research, the
BIPs, the related code in libsecp256k1, and other parts of the system.
The new soft fork rules are currently only used in signet and Bitcoin Core’s
private test mode (“regtest”); they need to be activated before they can
be used on Bitcoin’s mainnet.

Many of the contributors to taproot spent the remainder of the year
focusing on the 0.21.0 release of Bitcoin Core with the intention that a
subsequent minor release, possibly 0.21.1, will contain code that can
begin enforcement of taproot’s rules when an appropriate activation
signal is received.


The payjoin protocol based on the 2018 Pay-to-EndPoint
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
(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
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.


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
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

  • Coinswap implementation: Chris Belcher posted
    a design for a full-featured coinswap implementation. His initial
    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
. 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.

2020 summary
Major releases of popular infrastructure projects

  • LND 0.9.0-beta released in January improved the access control list
    mechanism (“macaroons”), added support for receiving multipath
    , added the ability to send
    additional data in an encrypted onion message, and allowed requesting
    channel close outputs pay a specified address (e.g. your hardware

  • LND 0.10.0-beta released in May added support for sending
    multipath payments, allowed funding channels using an external wallet
    via PSBTs, and began supporting the creation of invoices
    larger than 0.043 BTC.

  • Eclair 0.4 released in May added compatibility with the
    latest version of Bitcoin Core and deprecated the Eclair Node GUI
    (referring users to instead to Phoenix or Eclair Mobile).

  • Bitcoin Core 0.20.0 released in June began defaulting to bech32
    addresses for RPC users, allowed configuring RPC permissions for
    different users and applications, and added some basic support for
    generating PSBTs in the GUI.

  • C-Lightning 0.9.0 released in August provided an updated pay
    command and an RPC for sending messages over LN.

  • LND 0.11.0-beta released in August allowed accepting large


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

    Fee overpayment attack illustration

  • 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
    , 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
    , 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

  • 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 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
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.


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.

2020 summary
Bitcoin Optech

In Optech’s third year, 10 new member companies joined, we
held a taproot workshop in London,
published 51 weekly newsletters, added 20 new pages to
our topics index, added several new wallets and services to our
compatibility index, and published several contributed blog
about Bitcoin scaling technology.


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
. 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:, 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


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
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.

Illustration of LN liquidity and HTLC jamming attacks

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
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
. 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.


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.


Last year, Rusty Russell published a first draft of a proposed
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.


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—

What do you think?

Kaiko 2020 Year in Review Kaiko Data – Medium

Announcing our first Bitcoin Core developer grants The Coinbase Blog – Medium