Taproot Speedy Trial Code - - Merged Into Bitcoin Core

[LFC_Bitcoin]

Taproot Speedy Trial Code Merged Into Bitcoin Core
The merge puts an end to a long road of activation discussions – now all that's left is Taproot's actual activation.


Article Credit - Colin Harper - Apr 15, 2021 at 2:50 p.m. UTC
https://www.coindesk.com/taproot-speedy-trial-code-merged-into-bitcoin-core


The code for Taproot’s “Speedy Trial,” an activation method for Bitcoin’s biggest upgrade in years, has been merged into Bitcoin Core.

On April 15, Bitcoin Core developers Fanquake and Marco Falke merged two complementary pull requests authored by AJ Townes and Andrew Chow for Speedy Trial. With Speedy Trial now merged into Bitcoin Core’s source code, Taproot’s code is ready to start its first step toward activation when the code is released in May.

Bitcoin’s community, from developers to avid users, all agree that Taproot, which implements the Schnorr signature scheme into Bitcoin code, will be a boon for the network by making complex transactions (what the cool kids call “smart contracts”) more scalable and private.

Read more: How Bitcoin’s Taproot Upgrade Will Improve Technology Across Bitcoin’s Software Stack
No one has agreed on how to bring Taproot online, though. Because Bitcoin is decentralized, it requires painstaking coordination between actors to make sure an upgrade is released properly. After months and months of activation discussions led to a stalemate, Bitcoin developer David Harding and Russell O’Connor devised Speedy Trial as a way to put an end to the impasse.

How Speedy Trial works

The compromise allots a three-month activation window, during which time the network requires a certain threshold of miners to signal for the upgrade; if this threshold is reached, then Taproot is “locked in” and activates three months after the threshold is crossed.

Should this trial fail, then Taproot doesn’t activate (and the network will have only wasted three months trying, hence “speedy”).

The compromise brokered an agreement between those who wanted an activation via Bitcoin Improvement Proposal (BIP) 9, which means the upgrade fails if miners don’t adopt, and BIP8, which gives node operators (those running Bitcoin’s source code who act as “servers” for the network) an option to force the upgrade with a user activated soft fork if it fails.

Miners have shown no signs of blocking the upgrade, making the drawn-out discussions a source of frustration for some stakeholders.

[achow101]

This is some shoddy reporting.

Bitcoin core developer Gregory Maxwell, who has done extensive work on Taproot alongside Peter Wuille, merged the “pull request” for Speedy Trial around 16:00 UTC on April 15. With Speedy Trial now merged into Bitcoin Core’s source code,

Greg Maxwell neither has the ability to merge pull requests, nor was he significantly involved in the discussions that resulted in Speedy Trial. The person who actually merged it was fanquake, following months of review and revisions from several other developers.

[NotATether]

Bitcoin’s community, from developers to avid users, all agree that Taproot, which implements the Schnorr signature scheme into Bitcoin code, will be a boon for the network by making complex transactions (what the cool kids call “smart contracts”) more scalable and private.

But is anyone really planning to make, let alone merge into Bitcoin's integration tree, complex transactions (or as they call it "smart contracts) on Bitcoin's network? I don't see why that part is particularly exciting when Ethereum's already cluttered with those and it makes sense to just contain it there.

Today the choice is pretty simple - want to make some kind of complex transaction that involves fiddling with P2SH scripts? Then just build it on Ethereum's blockchain since the majority of users there are doing that. I don't think we want a surge of smart contracts on Bitcoin when they're mainly going to slow down real transaction confirmation time.


Usually what happens when someone builds an API is that fewer or no people use it than intended and it serves as an attack vector instead.

[Carlton Banks]

But is anyone really planning to make, let alone merge into Bitcoin's integration tree, complex transactions (or as they call it "smart contracts) on Bitcoin's network? I don't see why that part is particularly exciting when Ethereum's already cluttered with those and it makes sense to just contain it there.

the DLC project will eventually attract that type of use (referencing oracles to make contracts that respond to events external to bitcoin's blockchain; enables all possible types of betting, in essence). But to do this kind of thing, improving the scalability is a prerequisite; taproot and signature aggregation are (for me) only half of that picture. Really, it would all work much better off-chain, and I think that would mean conducting the transactions in channel factories (which needs another soft-fork: a no-input bitcoin script opcode, or some other way to create Bitcoin transactions that don't commit to the inputs)


great news IMO, I hope the miners are equally enthusiastic if not, fork 'em

[aliashraf]

Bitcoin’s community, from developers to avid users, all agree that Taproot, which implements the Schnorr signature scheme into Bitcoin code, will be a boon for the network by making complex transactions (what the cool kids call “smart contracts”) more scalable and private.

But is anyone really planning to make, let alone merge into Bitcoin's integration tree, complex transactions (or as they call it "smart contracts) on Bitcoin's network? I don't see why that part is particularly exciting when Ethereum's already cluttered with those and it makes sense to just contain it there.

Today the choice is pretty simple - want to make some kind of complex transaction that involves fiddling with P2SH scripts? Then just build it on Ethereum's blockchain since the majority of users there are doing that. I don't think we want a surge of smart contracts on Bitcoin when they're mainly going to slow down real transaction confirmation time.


Usually what happens when someone builds an API is that fewer or no people use it than intended and it serves as an attack vector instead.

I'm afraid you are misinterpreting the word "smart contract" here. Ethereum uses a Turing Complete scripting language/machine unlike bitcoin where we don't support loops and recursion using an Automata based programming language, hence for complex applications with multiple condition checks and branches, we need larger scripts in bitcoin. Besides other improvements e.g. implementing Schnorr signature scheme, Taproot uses a brilliant technique to reduce the size of such scripts dramatically.
How  
Taproot makes it possible for the actual script behind P2SH outputs to remain unrevealed forever except for the branches of execution that yield True with respect to the data supplied by the user.

So, Taproot doesn't add any new "feature" (for instance by mimicking Ethereum), it just makes it more feasible to use bitcoin's legacy capabilities with substantially fewer costs, nothing more.

[NotATether]

the DLC project will eventually attract that type of use (referencing oracles to make contracts that respond to events external to bitcoin's blockchain; enables all possible types of betting, in essence). But to do this kind of thing, improving the scalability is a prerequisite; taproot and signature aggregation are (for me) only half of that picture. Really, it would all work much better off-chain, and I think that would mean conducting the transactions in channel factories (which needs another soft-fork: a no-input bitcoin script opcode, or some other way to create Bitcoin transactions that don't commit to the inputs)

I'm perfectly fine with more soft forks with new opcodes like this being introduced if it gives developers their own playgrounds to script transactions in without interfering with the speed of real financial transactions.

I'm afraid you are misinterpreting the word "smart contract" here. Ethereum uses a Turing Complete scripting language/machine unlike bitcoin where we don't support loops and recursion using an Automata based programming language, hence supporting complex applications with multiple condition checks and branches need larger scripts in bitcoin.

...

So, Taproot doesn't add any new "feature" (for instance by mimicking Ethereum), it just makes it more feasible to use bitcoin's legacy capabilities with substantially fewer costs, nothing more.

In a way it feels like the journalist's use of the word smart contract is also wrong because this isn't enabling any more intrinsics to be used in bitcoin scripts, we just have the same agree scripts except they're more compressed now.

There should be a scope within which the words smart contract can be used, because a scripting language without loops and else-ifs can by no means be called that. It's like trying to calling things like Lisp and Scheme General-purpose programming languages.

Maybe there should be a basic literacy test about blockchain terminologies before people start writing articles, because errors like this don't reflect well on their competence.

[Wind_FURY]

The compromise brokered an agreement between those who wanted an activation via Bitcoin Improvement Proposal (BIP) 9, which means the upgrade fails if miners don’t adopt, and BIP8, which gives node operators (those running Bitcoin’s source code who act as “servers” for the network) an option to force the upgrade with a user activated soft fork if it fails.

I like it. That looks like the developers are trying to appease the miners, and not let them feel unimportant or not part of the decision-making process, but it will be the full nodes that will be the final decision-makers. Good hack.

Miners have shown no signs of blocking the upgrade, making the drawn-out discussions a source of frustration for some stakeholders.

Under Speedy Trial, I don’t think they have a choice?

[dkbit98]

Bitcoin core developer Gregory Maxwell, who has done extensive work on Taproot alongside Peter Wuille, merged the “pull request” for Speedy Trial around 16:00 UTC on April 15.

It was not him who merged it for sure, and it's easy to see this github that it was two Bitcoin Core devs Fanquake and Marco Falke by ajtownes and achow101, but Greg Maxwell is very active in overall Taproot activation subject.
Let's see what happens after 3 months but I don't see that miners are against this as 90% of total hashrate is supporting it, and I expect Taproot activation to finally be completed after this trial.
Average users who already use bech32 addresses will not even notice any change but under the hood there will be very important changes and improvements for multisig and privacy.

[gmaxwell]

Greg Maxwell is very active in overall Taproot activation subject.

No that is entirely untrue.  I think I've spent a total of an hour on the subject in the last three months not including time wasted reading the endless pointless shed-painting debates. And much of that hour just testing the activation setup and the rest was mostly correcting a bit of misinfo on reddit.

I am not a Bitcoin developer, I have not been a bitcoin developer for years. I was not materially involved in the discussion around taproot activation.  The article simply made a mistake-- it was corrected before I even knew about it (THANKS to whomever reported the error!).

[dkbit98]

No that is entirely untrue.  I think I've spent a total of an hour on the subject in the last three months not including time wasted reading the endless pointless shed-painting debates. And much of that hour just testing the activation setup and the rest was mostly correcting a bit of misinfo on reddit.

Let me rephrase it and be more accurate.
You started the main topic in bitcointalk about Taproot proposal in May 2019 and you posted 26 times in that topic.
I can't calculate exact time you spent writing this but I can appreciate it.

[gmaxwell]

Let me rephrase it and be more accurate.
You started the main topic in bitcointalk about Taproot proposal in May 2019 and you posted 26 times in that topic.

Great! So: Two years ago and entirely not about the current activation nonsense.