Taproot proposal

[gmaxwell]

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html

Hello everyone,

Here are two BIP drafts that specify a proposal for a Taproot
softfork. A number of ideas are included:

* Taproot to make all outputs and cooperative spends indistinguishable
from eachother.
* Merkle branches to hide the unexecuted branches in scripts.
* Schnorr signatures enable wallet software to use key
aggregation/thresholds within one input.
* Improvements to the signature hashing algorithm (including signing
all input amounts).
* Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support
batch validation.
* Tagged hashing for domain separation (avoiding issues like
CVE-2012-2459 in Merkle trees).
* Extensibility through leaf versions, OP_SUCCESS opcodes, and
upgradable pubkey types.

The BIP drafts can be found here:
* https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki
specifies the transaction input spending rules.
* https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki
specifies the changes to Script inside such spends.
* https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
is the Schnorr signature proposal that was discussed earlier on this
list (See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html)

An initial reference implementation of the consensus changes, plus
preliminary construction/signing tests in the Python framework can be
found on https://github.com/sipa/bitcoin/commits/taproot. All
together, excluding the Schnorr signature module in libsecp256k1, the
consensus changes are around 520 LoC.

While many other ideas exist, not everything is incorporated. This
includes several ideas that can be implemented separately without loss
of effectiveness. One such idea is a way to integrate SIGHASH_NOINPUT,
which we're working on as an independent proposal.

The document explains basic wallet operations, such as constructing
outputs and signing. However, a wide variety of more complex
constructions exist. Standardizing these is useful, but out of scope
for now. It is likely also desirable to define extensions to PSBT
(BIP174) for interacting with Taproot. That too is not included here.

Cheers,

--
Pieter

[1714791753]

1714791753

[1714791753]

1714791753

[1714791753]

1714791753

[fillippone]

Fillippone just  a pawn in the game of Bitcoin, I have enormous amount of respect for Bitcoin developers, and the following statement doesn’t absolutely mean to disrespect the huge work behind this proposal: I fully endorse and how will evolve in a Bitcoin protocol enchantment.
Writing this disclaimer because I got misunderstood in some previous discussions.

The more you build on bitcoin protocol, the more it is difficult to change the protocol itself.
With L2 solution (LN and  Liquid) being more and more widespread, and impacting Btc ecosystem, and L3 solutions peeking over the horizon (see my monthly recap),  I guess those are the last possible chances to get something done at protocol level.
Protocol immutability is a feature, not a bug.
Nobody in her right mind would change the TCP/IP and Bitcoin is the TCP/IP of the internet money.

[aliashraf]

Fillippone just  a pawn in the game of Bitcoin, I have enormous amount of respect for Bitcoin developers, and the following statement doesn’t absolutely mean to disrespect the huge work behind this proposal I fully endorse and how will evolve in a BItcoin protocol enanchments.
Writing this because I got misunderstood in some previous discussions.

The more you build on bitcoin protocol, the more it is difficult to change the protocol itself.
With L2 solution (LN and  Liquid) being more and more widespread, and impacting Btc ecosystem, and L3 solutions peeking over the horizon (see my monthly recap),  I guess those are the last possible chances to get something done at protocol level.
Protocol immutability is a feature, not a bug.
Nobody in her right mind would change the TCP/IP and Bitcoin is the TCP/IP of the internet money.

Absolutely disagree. Although making an analogy between bitcoin and TCP/IP is void and meaningless it would be worth mentioning how a semi-decentralized infrastructure like TCP/IP was ruined by L2 protocols like SMTP and HTTP giving birth to Internet giants like Google, Facebook, Netflix, YouTube, etc.

It is easy to make void analogies and waste your and other people's valuable time by advocating for L2 and L3 garbage that have nothing to do with basic ideas of cryptocurrency, among them decentralization and anti-censorship. Every shallow minded junior software engineer is able to make fantasies about layers above layers of protocols, feeling smart to understand protocol stacking. They are always prone to this class of mistakes, using design patterns as templates that are applicable to every problem without gap analysis.

There is a gap between bitcoin and a networking protocol like TCP/IP: bitcoin is a decentralized application while TCP/IP is a semi-decentralized transport protocol, a good engineer should beware of this gap and avoid stupid analogies between the two.

What is hard, the real challenge of bitcoin is improving it in consensus level such that it can accomplish its original mission as a p2p electronic cash system in a scalable fashion without compromising security and decentralization measures. Bitcoin Core developers has escalated this hurdle to an upper level by discouraging (even fighting against) hard forks. Unlike them, I don't see any reason to be such dogmatic about chain splits and hard forks, actually I see a handful of good reasons to have an overhaul every one decade or so.

My first impressions about Taproot proposal:

• A good, still conservative step, forward.
• So many critical problems not addressed.

Let's read the details and discuss later.

[fillippone]

I am not a software engineer, so I am no way qualified to judge your more technical remarks.
For sure i can criticise the analogy with Facebook, but I won't indulge in that because if the basic analogy Bitcoin (protocol) <=> TCP/IP is not good, every derivate analogy will be bad too.

The point is I always say Bitcoin as a protocol, not as an application, as I said, I am not a software engineer, so I will dig more into this.

[Carlton Banks]

I wonder if HTLC on Lightning Network can use Taproot (which would save fees/reduce tx size when open/close channel)?

Yes

Lightning channels have 2 scripts branches ("update" and "close"). If one were using these proposed taproot enabled segwit v1 outputs, the update branch will only ever be processed when the channel is open, and does not need to be written to the blockchain at all when closing the channel. Conversely, the close branch is not written to the chain when opening the channel.

This not only optimises space usage on-chain, but also makes lightning open/close transactions more closely resemble regular transactions, and so improves fungibility. I think it's possible with taproot and signature aggregation (which is not in this proposed fork) to make channel open/close tx's indistinguishable from regular tx's on chain (and potential changes to aid scaling of lightning routing will mean that only a small subset of LN nodes will be aware of the existence of a given channel, so knowing where and when BTC enters and exits payment channels will be a much more difficult problem to solve)

Edit: it's better than I thought, it seems only a specific form of sig aggregation ("cross input aggregation") is not in this fork proposal, but the basic type is (where signatures in a single transaction are summed together). No idea how cross input form differs from the basic type, still reading...

[fillippone]

After quick research, i just realized Taproot is combination of Schnorr and MAST. No wonder i never see any news about MAST.

I wonder if HTLC on Lightning Network can use Taproot (which would save fees/reduce tx size when open/close channel)?
But if Bitcoin use rolling-release/progressive approach (which is very unlikely)

Nobody in her right mind would change the TCP/IP and Bitcoin is the TCP/IP of the internet money.

I disagree, if there's way to optimize "lower" layer which also backward-compatible. I don't see anything wrong with it.
I'd agree if we're talking about implement complex feature on "lower" layer.

Sure, I agree on that, but what I mean is that if you build multiple protocol layers over the fundamental layer of Bitcoin protocol, if you modify anything on the lower one, the risk of getting something wrecked in the upper layers increases dramatically.
So when you build many layers over Bitcoin protocol, this get “compressed as a Jenga piece” and becomes immutable, as the risk of touching it and wrecking something somewhere becomes too high.

[ABCbits]

Yes
--snip--

Thanks for detailed explanation

Nobody in her right mind would change the TCP/IP and Bitcoin is the TCP/IP of the internet money.

I disagree, if there's way to optimize "lower" layer which also backward-compatible. I don't see anything wrong with it.
I'd agree if we're talking about implement complex feature on "lower" layer.

Sure, I agree on that, but what I mean is that if you build multiple protocol layers over the fundamental layer of Bitcoin protocol, if you modify anything on the lower one, the risk of getting something wrecked in the upper layers increases dramatically.
So when you build many layers over Bitcoin protocol, this get “compressed as a Jenga piece” and becomes immutable, as the risk of touching it and wrecking something somewhere becomes too high.

Can't disagree with that, but :
1. That's why we always wait years for new improvement, due to through-full testing
2. Many improvement add new feature rather than modify existing feature, such as creating P2SH address for scripting and Bech32 for SegWit.

[gmaxwell]

Sure, I agree on that, but what I mean is that if you build multiple protocol layers over the fundamental layer of Bitcoin protocol, if you modify anything on the lower one, the risk of getting something wrecked in the upper layers increases dramatically.

The Bitcoin protocol has specific carve outs for extension. New extensions are done using these carve-outs. This largely avoids impact on things not using the new functionality.

One can not guarantee a complete lack of interaction-- after all, things built on bitcoin could be full of terrible bugs just waiting to be exploited, and any new behaviour might trigger one of those bugs--, but nothing new shows up in transactions that wasn't permitted all along which at least guarantees that nothing changed that some party couldn't have unilaterally done to you.

The reason technical commentators don't express your concern isn't because it hasn't occurred to them, it's because it has occurred and is largely addressed.

I find it kinda frustrating that no one bothers mentioning concerns like this in the crazy "bitcoin should hardfork once a quarter" threads. -- why must this kind of concern be conserved for sane proposals where it doesn't really apply?

[Wind_FURY]

Fillippone just  a pawn in the game of Bitcoin, I have enormous amount of respect for Bitcoin developers, and the following statement doesn’t absolutely mean to disrespect the huge work behind this proposal I fully endorse and how will evolve in a BItcoin protocol enanchments.
Writing this because I got misunderstood in some previous discussions.

The more you build on bitcoin protocol, the more it is difficult to change the protocol itself.
With L2 solution (LN and  Liquid) being more and more widespread, and impacting Btc ecosystem, and L3 solutions peeking over the horizon (see my monthly recap),  I guess those are the last possible chances to get something done at protocol level.
Protocol immutability is a feature, not a bug.
Nobody in her right mind would change the TCP/IP and Bitcoin is the TCP/IP of the internet money.

Absolutely disagree. Although making an analogy between bitcoin and TCP/IP is void and meaningless it would be worth mentioning how a semi-decentralized infrastructure like TCP/IP was ruined by L2 protocols like SMTP and HTTP giving birth to Internet giants like Google, Facebook, Netflix, YouTube, etc.

It is easy to make void analogies and waste your and other people's valuable time by advocating for L2 and L3 garbage that have nothing to do with basic ideas of cryptocurrency, among them decentralization and anti-censorship. Every shallow minded junior software engineer is able to make fantasies about layers above layers of protocols, feeling smart to understand protocol stacking. They are always prone to this class of mistakes, using design patterns as templates that are applicable to every problem without gap analysis.

But every junior developer could also feel smart, and make fantasies of a perfect blockchain-based cryptocurrency too, without any regard for externalities, or without any regard for the risks in messing up the consensus layer.

There is a gap between bitcoin and a networking protocol like TCP/IP: bitcoin is a decentralized application while TCP/IP is a semi-decentralized transport protocol, a good engineer should beware of this gap and avoid stupid analogies between the two.

What is hard, the real challenge of bitcoin is improving it in consensus level such that it can accomplish its original mission as a p2p electronic cash system in a scalable fashion without compromising security and decentralization measures.

Says who?

Bitcoin Core developers has escalated this hurdle to an upper level by discouraging (even fighting against) hard forks. Unlike them, I don't see any reason to be such dogmatic about chain splits and hard forks, actually I see a handful of good reasons to have an overhaul every one decade or so.

That's your opinion. An opinion that many in the community do not share.

[aliashraf]

Sure, I agree on that, but what I mean is that if you build multiple protocol layers over the fundamental layer of Bitcoin protocol, if you modify anything on the lower one, the risk of getting something wrecked in the upper layers increases dramatically.

The Bitcoin protocol has specific carve outs for extension. New extensions are done using these carve-outs. This largely avoids impact on things not using the new functionality.

One can not guarantee a complete lack of interaction-- after all, things built on bitcoin could be full of terrible bugs just waiting to be exploited, and any new behaviour might trigger one of those bugs--, but nothing new shows up in transactions that wasn't permitted all along which at least guarantees that nothing changed that some party couldn't have unilaterally done to you.

The reason technical commentators don't express your concern isn't because it hasn't occurred to them, it's because it has occurred and is largely addressed.

I find it kinda frustrating that no one bothers mentioning concerns like this in the crazy "bitcoin should hardfork once a quarter" threads. -- why must this kind of concern be conserved for sane proposals where it doesn't really apply?

I hope it wouldn't cause more frustrations but I think both Ethereum approach (hard-forking like quarterly) and yours (do it never ever) to cryptocurrency governance should be categorized as extremism and need to be reconsidered.

Above-thread I objected to @fillippone not to the problem he has brought up but to his solution. He pushes your extremism to its limits and its destiny: leave bitcoin as is! When you abandon radical improvements they need to be implemented on upper layers and besides the centralization and censorship threats involved there will be always a push like that: Don't touch my infrastructure please!

I am against L2 solutions, I think both mining/state-verification in a decentralized ecosystem and on-chain scalability of bitcoin are not achievable without applying revisions in some crucial choices Satoshi made from the first beginning: winner-takes-all approach to mining and linear structure of the blockchain. There is no soft way to do such revisions and no L2 solution would ever solve both scaling and centralization.

Issuing anathema statements against radical improvement proposals that typically involve hard-fork requirements is nothing less than condemning bitcoin.

[aliashraf]

But every junior developer could also feel smart, and make fantasies of a perfect blockchain-based cryptocurrency too, without any regard for externalities, or without any regard for the risks in messing up the consensus layer.

And senior developers, (like you and Greg  ) should remain open to such proposals and use them at least as an inspiration to confront the real problems instead of sticking with false analogies with a networking protocol and being happy with minor improvements, Right?

There is a gap between bitcoin and a networking protocol like TCP/IP: bitcoin is a decentralized application while TCP/IP is a semi-decentralized transport protocol, a good engineer should beware of this gap and avoid stupid analogies between the two.

What is hard, the real challenge of bitcoin is improving it in consensus level such that it can accomplish its original mission as a p2p electronic cash system in a scalable fashion without compromising security and decentralization measures.

Says who?

I say 

[Carlton Banks]

Says who?

I say  

right, and you make up your own facts

("miners broke the SHA-2 algorithm" which is demonstrably nonsense)

[aliashraf]

Says who?

I say  

right, and you make up your own facts

("miners broke the SHA-2 algorithm" which is demonstrably nonsense)

This is an act of trolling,  
@Wind_Fury started it by asking for ethos instead of logus and now you are accomplishing his job by directly questioning my right to say anything about bitcoin. Very interesting.

If you are mentioning my criticism about ASICs, it is indisputable. PoW is a cryptographic problem, it hates efficiency, any cryptographic scheme does. bitcoin basically was designed for owners of commodity devices with almost average efficiency who join and leave the network freely and voluntarily and pay fairly for blocks they mine:

Nodes can leave   and   rejoin   the   network   at   will,   accepting   the   proof-of-work   chain   as   proof   of   what happened while they were gone.  They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them.  Any needed rules and incentives can be enforced with this consensus mechanism.

I think a better practice would be making your own argument about what I said above-thread:

What is hard, the real challenge of bitcoin is improving it in consensus level such that it can accomplish its original mission as a p2p electronic cash system in a scalable fashion without compromising security and decentralization measures. Bitcoin Core developers have escalated this hurdle to an upper level by discouraging (even fighting against) hard forks. Unlike them, I don't see any reason to be such dogmatic about chain splits and hard forks, actually I see a handful of good reasons to have an overhaul every one decade or so.

As a pro you might have noticed that I'm directly questioning Buterin's claim about the existence of a trilemma and suggesting that refuting this claim is the most important job of any serious bitcoin developer and the main agenda for any development project.

What do you think?

[gmaxwell]

Can y'all please stop derailing this thread?

[Wind_FURY]

Can y'all please stop derailing this thread?

Sorry.

aliasharf let's continue in this topic, https://bitcointalk.org/index.php?topic=5140929.0

[Xieta]

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html

Hello everyone,

Here are two BIP drafts that specify a proposal for a Taproot
softfork. A number of ideas are included:

* Taproot to make all outputs and cooperative spends indistinguishable
from eachother.
* Merkle branches to hide the unexecuted branches in scripts.
* Schnorr signatures enable wallet software to use key
aggregation/thresholds within one input.
* Improvements to the signature hashing algorithm (including signing
all input amounts).
* Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support
batch validation.
* Tagged hashing for domain separation (avoiding issues like
CVE-2012-2459 in Merkle trees).
* Extensibility through leaf versions, OP_SUCCESS opcodes, and
upgradable pubkey types.

The BIP drafts can be found here:
* https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki
specifies the transaction input spending rules.
* https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki
specifies the changes to Script inside such spends.
* https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
is the Schnorr signature proposal that was discussed earlier on this
list (See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html)

An initial reference implementation of the consensus changes, plus
preliminary construction/signing tests in the Python framework can be
found on https://github.com/sipa/bitcoin/commits/taproot. All
together, excluding the Schnorr signature module in libsecp256k1, the
consensus changes are around 520 LoC.

While many other ideas exist, not everything is incorporated. This
includes several ideas that can be implemented separately without loss
of effectiveness. One such idea is a way to integrate SIGHASH_NOINPUT,
which we're working on as an independent proposal.

The document explains basic wallet operations, such as constructing
outputs and signing. However, a wide variety of more complex
constructions exist. Standardizing these is useful, but out of scope
for now. It is likely also desirable to define extensions to PSBT
(BIP174) for interacting with Taproot. That too is not included here.

Cheers,

--
Pieter

It's a shame this thread derailed.
Is this still the current proposal or has the discussion on this moved elsewhere?

Best Regards,
-Xi

[fillippone]

A Pull Request from Sipa (Pieter Wuille) for Taproot/Schnoorr consensus rules has been opened on the Bitcoin Core repository:
[WIP] Implement BIP 340-342 validation (Schnorr/taproot/tapscript) #17977

This is an implementation of the Schnorr/taproot consensus rules proposed by BIPs 340, 341, and 342 (see current bitcoin/bips#876).

It consists of:

#16902 to avoid the O(n^2) behavior in IF/ELSE/END handling that would be exacerbated by the BIP 342 changes.
Addition of Schnorr signatures and 32-byte pubkey support to libsecp256k1 subtree (bitcoin-core/secp256k1#558 PR 558), following BIP 340.
The taproot validation specified in BIP 341.
Script validation under taproot (aka tapscript), specified in BIP 342.
Addition of signing logic for Schnorr/Taproot to the Python test framework, and tests for the above.
This does not include any wallet support.

Merging this is obviously conditional on getting community support for the proposal. It's opened here to demonstrate the code changes that it would imply.

This is the first step toward  the most important protocol change since Segwit, I dare to state.

[DooMAD]

This is the first step toward  the most important protocol change since Segwit, I dare to state.

Excellent news.  I suspect a number of people will be watching with keen interest.  Have there been any elaborations on timescales?  Or are the waters still a little murky for that with so much stuff to figure out on the technical side?  Obviously with a significant change like this, they'll be treading carefully.

[Carlton Banks]

A Pull Request from Sipa (Pieter Wuille) for Taproot/Schnoorr consensus rules has been opened on the Bitcoin Core repository:

big news indeed.

any elaborations on timescales?

the pull request is marked WIP (work in progress), so my guess would be no. I think sipa is just soliciting early feedback on his implementation of the BIPs (the details of which we can assume are essentially final)

[fillippone]

the pull request is marked WIP (work in progress), so my guess would be no. I think sipa is just soliciting early feedback on his implementation of the BIPs (the details of which we can assume are essentially final)

Officially BIP!
Pieter Wuille on Twitter:

The Schnorr/Taproot proposal is now published as BIPs 340, 341, and 342; see github.com/bitcoin/bips/

Note that the assignment of BIP numbers is not any kind of stamp of approval; it just means the process was followed (which includes some amount of public discussion).

https://twitter.com/pwuille/status/1220502956023283718?s=21

EDIT:
For the non technical and casual reader an article surfaced on Coindesk:
Bitcoin’s Privacy and Scaling Tech Upgrade ‘Taproot’ Just Took a Big Step Forward