A Look at Innovation in Bitcoin’s Technology Stack [complete with references]

[fillippone]

I read a very interesting piece on Medium, summing up all the recent innovations in the bitcoin protocol.
For the not ubertechnical users like me it's a good summary of all the improvements in the Bitcoin stack.
I thought it would be handy to have a reference thread here on Bitcointalk, if available, for each of those technology.
I tried to start filling the boxes, please suggest new reference in case you know better ones.

A Look at Innovation in Bitcoin’s Technology Stack

• Layer 2
  • Lightning network:
    Basics of the Lightning Network
    The Lightning Network FAQ
  • Omni
  • Data identity
  • Data Anchors
• Sidechains
  
  • (RSK)Rootstock:
    Rootstock (RSK) - Smart Contracts for Bitcoin
  • Drivechain
    Drivechain - scaling solution?
  • Elements
    Elements Project testnet sidechain alpha released
  • Liquid
    [10/10/2018] Blockstream Liquid Sidechain Solution for Bitcoin Network Goes Live
    
• Mining
  
  • FIBRE:
    How (and why) pools (and all miners) should use the Relay Network
  • BetterHash
    BetterHash Mining Protocol BIP
    
  • Stratum
    [Stratum] Overlay network protocol over Bitcoin
    Stratum protocol documentation
  • Mining Derivatives
     Gauging Interest: Difficulty Derivatives? Miners lock in future Diff.
    
• Privacy
  
  • Coinjoin:
    CoinJoin: Bitcoin privacy for the real world
  • Dandelion
    [Discussion] Dandelion - A protocol to hide transaction origin
  • Confidential Transactions
    Confidential Transactions, Content privacy for Bitcoin transactions
  • Coinswap
    CoinSwap: Transaction graph disjoint trustless trading
    Tumblebit
    
• Smart Contracts
  
  • ChecktemplateVerify:
    CoinCovenants using SCIP signatures, an amusingly bad idea.
  • tBTC
  • MAST/TAPROOT
    Smart Contracts ..where are we now in their advancement
    Taproot proposal
    
  • Scriptless Scripts
    Scriptless scripts
    
  • Simplicity
    Simplicity new language for blockchains
    Simplicity - A new advanced programming Language for Bitcoin
    
  • Minsc
    New "Tier Three" Programming Language: Minsc
    
  • Ivy
  • Hivemind
• Performance and usability
  
  • Schnorr Signatures:
    [Schnorr] Should batched verification result in reduced weight per sig?
    MuSig: Schnorr Multisig and signature aggregation
    
  • Neutrino
  • Erlay
    Bandwidth-Efficient Transaction Relay
  • BtcPay
    The Merchants Guide to accepting Bitcoin directly no intermediates - BTCPay
  • uTreeXo, libMiniscketch, Tx Accumulators
    Can dynamic accumulators be used to store UTXOs
    
  
  

[1713500767]

1713500767

[1713500767]

1713500767

[1713500767]

1713500767

[fillippone]

Today Aaron van Wirdum (twitter @AaronvanW) published a good recap of potential bitcoin protocol innovation expected in 2020.
It's a good read to get a better, not ubertechical grasp at the picture in the OP.

2020 and Beyond: Bitcoin’s Potential Protocol Upgrades

Bitcoin’s consensus layer has remained unchanged for over two years now. Since Segregated Witness (SegWit), which activated in August 2017, no hard fork or soft fork protocol upgrades have been deployed at all*, marking Bitcoin’s longest stretch without consensus forks so far.

But this stretch may soon come to an end: several backward-compatible soft forks are currently in development. Optimistically, some of them may go live in 2020 — if they gather sufficient support from the Bitcoin ecosystem.

[fillippone]

An intresting recap about Taproot upgrade proposal:

Bitcoin's Taproot/Schnorr upgrade proposal is 'nearly ready' as it moves through developer feedback phase.

Taproot is expected to be bundled together with Schnorr, a related upgrade that seeks to enable signature aggregation and make Taproot’s implementation possible.

Right now, the Taproot/Schnorr soft fork – proposed in May by Bitcoin Core developer Pieter Wuille – is moving through the ecosystem feedback phase as developers recommend and review possible changes to the draft.

On Dec. 17, Wuille put out an update on the project during the final scheduled meeting of the Taproot review group, where he revealed that developers were finishing addressing all comments from the review and that the Taproot proposal was “nearly ready.”

The proposal moving forward is designed to save 30% to 75% in fee use and accelerate block validation by up to 2.5 times, Square Crypto product manager Steve Lee predicted during a presentation from last summer.

It's a process that has attracted interest and excitement from different quarters of the crypto ecosystem. Recent survey data collected by The Block that indicates that Taproot is high on the list of technological developments being followed.

[Last of the V8s]

He missed out statechains
old thread: https://bitcointalk.org/index.php?topic=5153301.0

[fillippone]

Regarding Tumblebit, from this week Bitcoin Optech Newsletter #81:
 

New coinjoin mixing technique proposed: Max Hillebrand started a thread on the Bitcoin-Dev mailing list about Wormhole, a method developed during a Wasabi design discussion for sending payments as part of a chaumian coinjoin. The protocol prevents even the spender from learning the receiver’s Bitcoin address (within the limits of the anonymity set). Developer ZmnSCPxj notes that the technique is similar to tumblebit, which provides a trustless chaumian payment service. Hillebrand is requesting feedback on the design in the hopes of seeing it implemented in the future.

[fillippone]

Bitcoin Optech Newsletter #94 is out.

BTCPay implemented PayJoin

BTCPay adds support for sending and receiving payjoined payments: payjoin is a protocol that increases the privacy of Bitcoin payments by including inputs from both the spender and the receiver in an onchain transaction. This prevents an outside observer examining block chain data from assuming all inputs in that transaction belong to the same user (e.g.1). If a significant number of people use payjoin, this makes the common input heuristic used by block chain analysts much less reliable, improving privacy for even Bitcoin users who aren’t using payjoin.

This week, BTCPay announced the release of version 1.0.4.0 which includes an implementation of payjoin support for both receiving payments in payment processor mode and sending them using BTCPay’s internal wallet. For details on using the protocol, see their user guide. For technical details on their implementation, see their specification or the issue where future improvements are being actively discussed. For this change to have the maximum impact, other popular wallets need to implement support for creating compatible payjoin payments.

Executive summary:
What is a Payjoin?

[fillippone]

Bitcoin Optech Newsletter #94 is out.

BTCPay implemented PayJoin

--snip--

PayCoin is exciting feature, but both spender and receiver must be real careful when spending their Bitcoin. Consolidating or moving their Bitcoin (by using all input altogether) could weaken the privacy.
For other CoinJoin implementation such as Wasabi is aceptable since participant number is very high.

Hopefully popular wallet will implement PayJoin protocol soon.

As usual, privacy feature are more useful when their use is widespread, otherwise you could end up having the opposite effect (e.g. when you are alone doing coinjoin), as beautifully put here by Giacomo Zucco.
So yes, adoption trough appropriately simple interfaces are a nice thing to see in the future.

[fillippone]

Simplicity is moving a little bit closer to production, even if in the Liquid Sidechain, not on Bitcoin Mainnnet.


I opened a new thread here, to discuss this:
Simplicity - A new advanced programming Language for Bitcoin

I linked in that thread a very interesting article from LongHash and a link to a Webinar by Adam Back.

Added reference in the OP too.

[fillippone]

An interesting read by Aaron van Wirdum on the way Taproot could be implemented in the Bitcoin Protocol.

BIP 8, BIP 9 Or Modern Soft Fork Activation: How Bitcoin Could Upgrade Next

Taproot, a proposed protocol upgrade that would improve Bitcoin’s privacy and flexibility, is in its late stages of development. Bitcoin Core contributors agree that the upgrade would benefit Bitcoin, and so far it generally appears to be welcomed by the wider Bitcoin ecosystem as well. It’s therefore likely that Taproot will make its way into a Bitcoin Core release, with other Bitcoin implementations possibly to follow.

But one question remains: how should the Bitcoin network itself upgrade? Taproot is a consensus protocol change, which means that Bitcoin nodes must somehow switch from the old rules to the new rules without splitting the network into factions enforcing different rules. For various reasons, this has in the past sometimes proven to be a challenge.

Improved strategies to activate protocol upgrades are now being contemplated.

If you are interested on technical discussion specifically about Taproot activation, I suggest you to follow this thread :

Technical: Taproot: Why Activate?

[fillippone]

Minsc added to the Bitcoin Scripting Language branch, with a new thread started:
New "Tier Three" Programming Language: Minsc

[fillippone]

Aaron Van Wirdum goes on detailing Taproot future: Payment Pools.


Building On Taproot: Payment Pools Could Be Bitcoin’s Next Layer Two Protocol

Taproot, a potential upgrade to the Bitcoin protocol first proposed by Bitcoin Core contributor Gregory Maxwell, is in its late stages of development. The technology consists of a clever combination of crypto-tricks that would let users hide complex smart contracts inside regular-looking transactions — the complexity is only ever revealed if parties to a contract are uncooperative.

Leveraging this idea, Bitcoin Core contributors including (but not limited to) Jeremy Rubin, Antoine Riard, Gleb Naumenko and Gregory Maxwell himself have been speculating about a general concept referred to as payment pools, joinpools or coinpools. These pools — we’ll stick to calling them payment pools for now — would let groups of users share ownership of the same coins (technically: UTXOs) as recorded on the Bitcoin blockchain, while letting any of these users make (or receive) payments with them. As the group and its individual members “hide” in a Taproot structure, all of them enjoy more privacy, smart contract flexibility and other benefits… and they potentially even enjoy these benefits off-chain, making payment pools a new Layer Two solution.

This could it thought as a Layer-1 scaling alternative to complement the Layer-2 solutions? Or rather to oppose?
Privacy-wise, I also wait how the Regulators will react to this, totally negating their heuristic-based-chain analysis efforts.

[Last of the V8s]

Containerise everything!  a work in progress https://github.com/NGUtech/bitcoin-stack

Docker setup for Bitcoin, Elements/Liquid, LND, C-Lightning, & Eclair in regtest mode

This docker-compose template launches bitcoin, two lnd containers named alice & bob, with a clightning container as carol, and an eclair container as frank.

Additionally it can launch an elements sidechain (aka Liquid), with clightning implementation containers as dave & emma servicing the LBTC asset.

An application demo node is include which demonstrates how to connect to LND and listen to invoice messages and is able to generate transaction spam for fee estimation.

Everything is configured to run in regtest mode but can be adjusted as required.

[fillippone]

A very good news for everyone running a bitcoin node.
Due to patent expiry, from next bitcoin core major release the activation of a new technology to cryptographically verify signatures will enable an improved performance of about 10% (conservative estimate) in the IBD and block verification.
This feature has always been present in bitcoin libraries, but it was defaulted off just to avoid patent litigations.

Hal Finney’s Proposal for Optimizing Bitcoin to be Enabled in Bitcoin Core

Today, a patent involving the acceleration of cryptographic operations on elliptic curves has expired. Invented by Gallant, Lambert, and Vanstone, this technique is commonly referred to as GLV Endomorphism and can now be activated in Bitcoin Core in order to improve the speed and efficiency of Bitcoin’s signature verification.

Interestingly enough, this technique was originally proposed in a bitcointalk post

[ABCbits]

A very good news for everyone running a bitcoin node.
Due to patent expiry, from next bitcoin core major release the activation of a new technology to cryptographically verify signatures will enable an improved performance of about 10% (conservative estimate) in the IBD and block verification.
This feature has always been present in bitcoin libraries, but it was defaulted off just to avoid patent litigations.

--snip--

As additional references, it's also discussed at [validation performance] ECDSA GLV endomorphism patent expires Sep 25th 2020