Bitcoin Forum

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.

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.

New coinjoin mixing technique proposed: Max Hillebrand started a thread (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017585.html) on the Bitcoin-Dev mailing list about Wormhole, a method developed during a Wasabi design discussion (https://github.com/zkSNACKs/Meta/issues/49) 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  (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017587.html)that the technique is similar to tumblebit (https://bitcoinops.us18.list-manage.com/track/click?u=70c3f85e5d13ffec674f30af8&id=c22a69e2d8&e=cd3812be1f), which provides a trustless chaumian payment service. Hillebrand is requesting feedback on the design in the hopes of seeing it implemented in the future.

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.

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.

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.

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

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.

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