<p>The idea of using the leaves of a Merkle tree to store alternative Bitcoin scripts dates back to Russell O'Connor in <a href="https://diyhpl.us/wiki/transcripts/london-bitcoin-devs/2020-07-21-socratic-seminar-bip-taproot/" rel="nofollow noreferrer">2012</a>. The idea of using Schnorr signatures instead of ECDSA has been discussed for at least as long. So you could say that what we will collectively call BIP-Taproot (BIP 340, BIP 341 and BIP 342) has been in the making for over eight years at this point.</p>
<p>However, there have been different iterations of how to apply these ideas and what we now consider BIP-Taproot was <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html" rel="nofollow noreferrer">first proposed</a> on the Bitcoin dev mailing list by Greg Maxwell in January 2018.</p>
<p>The draft of the Schnorr BIP (what became BIP 340) was first <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html" rel="nofollow noreferrer">sent</a> to the Bitcoin dev mailing list in July 2018.</p>
<p>The draft of the Taproot BIP and the Tapscript BIP (what became BIP 341 and BIP 342) were <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html" rel="nofollow noreferrer">sent</a> to the Bitcoin dev mailing list in May 2019. The BIPs were all allocated BIP numbers in <a href="https://github.com/bitcoin/bips/commit/1faa4b19bcfaec44a964a665f68a5bdaba85337e#diff-102055dfc9759e7d1d7ccbf81cb11a04140b568722dc61af66b5a5b670c8449e" rel="nofollow noreferrer">January 2020</a>.</p>
<p>Jonas Nick laid out the full timeline of BIP-Taproot progress <a href="https://nickler.ninja/blog/2020/11/29/bip-%7Bschnorr/" rel="nofollow noreferrer">here</a>.</p>
<p>Greg Maxwell compared how long it took SegWit to go from draft specification to merged into Bitcoin Core in this Reddit <a href="https://www.reddit.com/r/Bitcoin/comments/hrlpnc/technical_taproot_why_activate/fyqbn8s/" rel="nofollow noreferrer">post</a>.</p>
<blockquote>
<p>Segwit went from early public discussions to merged in six months. So in spite being more complex and subject to more debate due to splashback from blocksize drama, segwit was still done in significantly less time already.</p>
<p>Taproot has also been exceptionally widely discussed by the wider bitcoin community for a couple years now. It's application is narrow, users who don't care to use it are ultimately unaffected by it (it should decrease resource consumption by nodes, rather than increase it) and no one is forced to use it for their own coins. It also introduces new tools to make other future improvements simpler, safer (particularly, taproot leaf versions), and more private... so there is a good reason that other future improvements are waiting on tapoot.</p>
</blockquote>

CC BY-SA 4.0
2020-12-01T11:58:45.227Z
2021-04-21T14:13:13.610Z
2021-04-21T14:13:13.610Z
Michael Folkson
<p>It seems BIP-Taproot has been discussed for years now. How long has it taken to go from draft specification to potential activation?</p>

<taproot>
How long has it taken for BIP-Taproot to go from draft specification to activation?
Michael Folkson
# How long has it taken for BIP-Taproot to go from draft specification to activation?

(Asked by: username_0 on 2020-12-01)

It seems BIP-Taproot has been discussed for years now. How long has it taken to go from draft specification to potential activation?

**Tags:** taproot


---

## 1 answers

### Answer by username_0 on 2020-12-01. Score: 1 | Accepted answer

The idea of using the leaves of a Merkle tree to store alternative Bitcoin scripts dates back to Russell O'Connor in [2012](https://diyhpl.us/wiki/transcripts/london-bitcoin-devs/2020-07-21-socratic-seminar-bip-taproot/). The idea of using Schnorr signatures instead of ECDSA has been discussed for at least as long. So you could say that what we will collectively call BIP-Taproot (BIP 340, BIP 341 and BIP 342) has been in the making for over eight years at this point.

However, there have been different iterations of how to apply these ideas and what we now consider BIP-Taproot was [first proposed](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html) on the Bitcoin dev mailing list by Greg Maxwell in January 2018.

The draft of the Schnorr BIP (what became BIP 340) was first [sent](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html) to the Bitcoin dev mailing list in July 2018.

The draft of the Taproot BIP and the Tapscript BIP (what became BIP 341 and BIP 342) were [sent](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html) to the Bitcoin dev mailing list in May 2019. The BIPs were all allocated BIP numbers in [January 2020](https://github.com/bitcoin/bips/commit/1faa4b19bcfaec44a964a665f68a5bdaba85337e#diff-102055dfc9759e7d1d7ccbf81cb11a04140b568722dc61af66b5a5b670c8449e).

Jonas Nick laid out the full timeline of BIP-Taproot progress [here](https://nickler.ninja/blog/2020/11/29/bip-%7Bschnorr/).

Greg Maxwell compared how long it took SegWit to go from draft specification to merged into Bitcoin Core in this Reddit [post](https://www.reddit.com/r/Bitcoin/comments/hrlpnc/technical_taproot_why_activate/fyqbn8s/).

> Segwit went from early public discussions to merged in six months. So in spite being more complex and subject to more debate due to splashback from blocksize drama, segwit was still done in significantly less time already.
>
> Taproot has also been exceptionally widely discussed by the wider bitcoin community for a couple years now. It's application is narrow, users who don't care to use it are ultimately unaffected by it (it should decrease resource consumption by nodes, rather than increase it) and no one is forced to use it for their own coins. It also introduces new tools to make other future improvements simpler, safer (particularly, taproot leaf versions), and more private... so there is a good reason that other future improvements are waiting on tapoot.


---

