gmaxwell (OP)
Moderator
Legendary
Offline
Activity: 4228
Merit: 8644
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2019, 12:03:27 AM Merited by EFS (8), fillippone (7), Welsh (6), ABCbits (6), hugeblack (6), suchmoon (4), Foxpup (3), Carlton Banks (3), bitbollo (3), LoyceV (2), nutildah (2), Jating (2), DdmrDdmr (2), o_e_l_e_o (2), DireWolfM14 (2), bones261 (2), Heisenberg_Hunter (2), Coding Enthusiast (2), OgNasty (1), d5000 (1), JayJuanGee (1), mindrust (1), o48o (1), Chikito (1), 1miau (1), notblox1 (1), franckuestein (1), NotATether (1), Xavofat (1), Taipan_ (1) |
|
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.htmlHello 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.mediawikispecifies the transaction input spending rules. * https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawikispecifies the changes to Script inside such spends. * https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawikiis 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
|
|
|
|
fillippone
Legendary
Online
Activity: 2254
Merit: 16234
Fully fledged Merit Cycler - Golden Feather 22-23
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2019, 07:15:30 AM Last edit: May 07, 2019, 07:45:32 AM by 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
Legendary
Offline
Activity: 1456
Merit: 1174
Always remember the cause!
|
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
Legendary
Online
Activity: 2254
Merit: 16234
Fully fledged Merit Cycler - Golden Feather 22-23
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2019, 09:13:16 AM |
|
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
Legendary
Offline
Activity: 3430
Merit: 3080
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2019, 06:31:58 PM Last edit: May 07, 2019, 08:51:16 PM by 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...
|
Vires in numeris
|
|
|
fillippone
Legendary
Online
Activity: 2254
Merit: 16234
Fully fledged Merit Cycler - Golden Feather 22-23
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2019, 06:35:33 PM |
|
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
Legendary
Offline
Activity: 2968
Merit: 7801
Crypto Swap Exchange
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2019, 06:44:11 PM Merited by fillippone (1) |
|
Yes --snip--
Thanks for detailed explanation ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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 (OP)
Moderator
Legendary
Offline
Activity: 4228
Merit: 8644
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2019, 10:20:10 PM |
|
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. ![Sad](https://bitcointalk.org/Smileys/default/sad.gif) -- why must this kind of concern be conserved for sane proposals where it doesn't really apply?
|
|
|
|
Wind_FURY
Legendary
Offline
Activity: 3010
Merit: 1878
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 08, 2019, 08:16:01 AM |
|
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.
|
| .SHUFFLE.COM.. | ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ | ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ | . ...Next Generation Crypto Casino... |
|
|
|
aliashraf
Legendary
Offline
Activity: 1456
Merit: 1174
Always remember the cause!
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 08, 2019, 09:37:52 AM Last edit: May 08, 2019, 10:08:45 AM by 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. ![Sad](https://bitcointalk.org/Smileys/default/sad.gif) -- 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
Legendary
Offline
Activity: 1456
Merit: 1174
Always remember the cause!
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 08, 2019, 10:04:07 AM |
|
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 ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) ) 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 ![Cool](https://bitcointalk.org/Smileys/default/cool.gif)
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3080
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 08, 2019, 01:10:35 PM |
|
Says who?
I say ![Cool](https://bitcointalk.org/Smileys/default/cool.gif) right, and you make up your own facts ("miners broke the SHA-2 algorithm" which is demonstrably nonsense)
|
Vires in numeris
|
|
|
aliashraf
Legendary
Offline
Activity: 1456
Merit: 1174
Always remember the cause!
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 08, 2019, 05:49:01 PM Last edit: May 08, 2019, 06:04:06 PM by aliashraf |
|
Says who?
I say ![Cool](https://bitcointalk.org/Smileys/default/cool.gif) right, and you make up your own facts ("miners broke the SHA-2 algorithm" which is demonstrably nonsense) This is an act of trolling, ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) @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 (OP)
Moderator
Legendary
Offline
Activity: 4228
Merit: 8644
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 08, 2019, 08:28:31 PM |
|
Can y'all please stop derailing this thread?
|
|
|
|
Wind_FURY
Legendary
Offline
Activity: 3010
Merit: 1878
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 09, 2019, 07:01:50 AM |
|
Can y'all please stop derailing this thread?
Sorry. aliasharf let's continue in this topic, https://bitcointalk.org/index.php?topic=5140929.0
|
| .SHUFFLE.COM.. | ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ | ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ ███████████████████████ | . ...Next Generation Crypto Casino... |
|
|
|
Xieta
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 61
Merit: 40
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 07, 2019, 10:56:44 AM |
|
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.htmlHello 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.mediawikispecifies the transaction input spending rules. * https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawikispecifies the changes to Script inside such spends. * https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawikiis 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
Legendary
Online
Activity: 2254
Merit: 16234
Fully fledged Merit Cycler - Golden Feather 22-23
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 23, 2020, 11:55:52 AM Last edit: January 23, 2020, 12:17:46 PM by fillippone Merited by Carlton Banks (1), squatter (1) |
|
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) #17977This 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
Legendary
Offline
Activity: 3878
Merit: 3178
Leave no FUD unchallenged
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 23, 2020, 02:14:31 PM |
|
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
Legendary
Offline
Activity: 3430
Merit: 3080
|
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)
|
Vires in numeris
|
|
|
fillippone
Legendary
Online
Activity: 2254
Merit: 16234
Fully fledged Merit Cycler - Golden Feather 22-23
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 24, 2020, 12:36:54 AM Last edit: January 24, 2020, 09:32:07 AM by 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=21EDIT: 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
|
|
|
|
|