Taproot proposal

[kano]

Meanwhile, some noob pool shows up and mines a block without the taproot flag ... lulz.

Block 689182

But Taproot is already locked in and can not be changed, there is no point in signalling for it anymore since full nodes stopped counting.

I very much doubt a tiny pool like Zulu had the block version '4' turned on before then turned it off again.
I'd not be surprised if they didn't even know what Taproot was ...
It's literally the only block seen recently on the whole network without the '4'

Edit:
last coinbase with zulu in it was 28-Feb
the network's last block without the '4' was 687953 by binance on 17-Jun

[1714238702]

1714238702

[1714238702]

1714238702

[cygan]

“Taproot makes Bitcoin better...and is not yet priced in,” says D++ who views the potential for greater institutional adoption as a result of the upgrade to the network. She celebrates this amazing new technology: Bitcoin Script and smart contract improvements, plus multisig transactions including Lighting channels now all look the same, resulting in added privacy.

https://www.forbes.com/sites/jasonbrett/2021/07/08/are-institutional-investors-undervaluing-the-taproot-upgrade-to-bitcoin/

[nortwood]

My spy filtered node

I've searched but I'm unable to find where to learn more about this.

[Hueristic]

My spy filtered node

I've searched but I'm unable to find where to learn more about this.

Well then I guess its working.

[nortwood]

Quote from: nortwood on July 11, 2021, 09:17:09 PM
Quote
My spy filtered node

I've searched but I'm unable to find where to learn more about this.

Well then I guess its working.

Fair enough, lol

It's just that questions regarding best practices for running nodes has been on my mind. I'll start a different thread.

[cygan]

today i came across a very interesting homepage that shows in great details the preparations for the taproot upgrade
https://bitcoinops.org/en/preparing-for-taproot/

[Charles-Tim]

Cheaper to spend: it costs about 15% less at the input level to spend a single-sig P2TR UTXO than it does to spend a P2WPKH UTXO. An overly simple analysis like the table above hides the detail that the spender can’t choose which addresses they’re asked to pay, so if you stay on P2WPKH and everyone else upgrades to P2TR, the actual typical size of your 2-in-2-out transactions will be 232.5 vbytes—while all-P2TR transactions will still only be 211.5 vbytes.

But, I have few take about the transaction, it is true that the input comparison will make Taproot transactions fee to be low if compared to segwit, I mean the more the inputs, the lower the increasing fee of Taproot transaction if compared with segwit increasing fee. But segwit has the advantage of the output in which transaction will be lower in segwit transaction if compared to taproot transaction as a result of increasing output. I have posted about this before, you can check it through the link below for me to avoid repetition.

https://bitcointalk.org/index.php?topic=5348128.msg57421763#msg57421763

[cygan]

the taproot upgrade will optimize the rsk network also, making it easy to integrate dapps into the Bitcoin blockchain

As of now, the majority of the DeFi projects are built on Ethereum, primarily since Bitcoin wasn’t equipped to support the needs of developers building dApps for the DeFi ecosystem. However, with the introduction of RSK, the smart contract blockchain secured by the Bitcoin network, projects can leverage the trustless and transparent decentralized finance opportunities offered by Bitcoin to a greater extent.

https://btcmanager.com/bitcoin-taproot-upgrade-rsk/

[BlockchainYM]

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

Is there any opcode update details? For example, string link opcode?

[pooya87]

Is there any opcode update details? For example, string link opcode?

As the big text you just quoted states, a new OP code called OP_CHECKSIGADD is added to replace OP_CHECKMULTISIG(VERIFY) working with Schnorr signatures.
Apart from that the behavior of OP_CHECKSIG is also changed if it is inside a Taproot script as it needs a different sighash and treats signatures as Schnorr signatures not ECDSA.
There are also some small changes such as OP_(NOT)IF mandate "minimal if" (the item popped by the operation has to be empty array or 1).

[BlockchainYM]

Is there any opcode update details? For example, string link opcode?

As the big text you just quoted states, a new OP code called OP_CHECKSIGADD is added to replace OP_CHECKMULTISIG(VERIFY) working with Schnorr signatures.
Apart from that the behavior of OP_CHECKSIG is also changed if it is inside a Taproot script as it needs a different sighash and treats signatures as Schnorr signatures not ECDSA.
There are also some small changes such as OP_(NOT)IF mandate "minimal if" (the item popped by the operation has to be empty array or 1).

Thank you very much for your reply. I have two questions here. The first one uses Bitcoin script to implement string concatenation in the stack? I did not find a valid opcode in the latest Bitcoin script? Second, how can I better learn the Bitcoin script, or can I recommend some good information?

[pooya87]

The first one uses Bitcoin script to implement string concatenation in the stack? I did not find a valid opcode in the latest Bitcoin script?

There aren't any string concatenation OPs in bitcoin simply because there is no use cases for it in a payment system.
There used to be a couple of disabled OP codes in early version that are completely removed now that use to deal with string manipulation: OP_CAT, OP_SUBSTR, OP_LEFT, OP_RIGHT

Second, how can I better learn the Bitcoin script, or can I recommend some good information?

I don't know any source that explains everything but chapter 7 of the book called "Mastering Bitcoin" has a good explanation of the standard scripts that should give you enough information about how things work:
https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch07.asciidoc
(You may want to start in chapter 6 where it explains transactions).

For additional information and details you should check the source code and then ask questions here about any part that is unclear: https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp

[gmaxwell]

There aren't any string concatenation OPs in bitcoin simply because there is no use cases for it in a payment system.
There used to be a couple of disabled OP codes in early version that are completely removed now that use to deal with string manipulation: OP_CAT, OP_SUBSTR, OP_LEFT, OP_RIGHT

There absolutely are use cases!  Unfortunately the original construction could be abused to cause nodes to require petabytes of ram ...  Fixing that requires imposing additional restrictions, and without planning for specific uses it can be hard to be confident that the restrictions don't break them.

... and demand for fancy use cases seems pretty limited-- which doesn't motivate people to do the design and validation work needed to reintroduce the operations.

[pooya87]

There absolutely are use cases!

Any examples?

[gmaxwell]

There absolutely are use cases!

Any examples?

Sure!  I mean one of the main features of taproot could be substantially implemented with just using OP_CAT. https://blockstream.com/2015/08/24/en-treesignatures/   (but it's much more cpu/space/fee efficient to implement it directly).

Using string operators on and either a verify-signature-of-data-on-stack or some improved arithmetic operations lets you implement vaults: https://blockstream.com/2016/11/02/en-covenants-in-elements-alpha/

Using substr (or op_cat) you can implement a single show signature--  a output that requires a signature where if someone signs for it more than once, they'll leak the private key.  (You require that the signature use a specific R value). You can use this to make transactions with a double spend penalty.

I think arguably of all the disabled opcodes the "string" ones are really the most useful.

[thecodebear]

So forgive me for not understanding all the technicals or if I say something wrong here, but I was wondering about Defi possibilities on Bitcoin due to Taproot. I recently saw an article saying Taproot will bring Defi applications to Bitcoin. I had no idea that would be possible.

I assume this is because Schnorr signatures basically allows multiple signatures to be aggregated down into a single signature, so for any more advanced transactions that compresses the data in the tx down to the size of an ordinary tx, so more advanced types of transactions now takes up a lot less space and therefore complicated transactions won't have super high fees.

But Defi applications on Bitcoin will still be limited by its simple scripting abilities, so is it even possible to do Defi applications on Bitcoin? I have no idea how limited Bitcoin's script language is I just know it's not turing complete, I always assumed it is the limited scripting abilities and not the fees that stop Bitcoin from doing Defi. Are we, as a community, expecting Defi dapps to start coming out on Bitcoin after Taproot?? If so what sort of limitations would they have? Would they be limited to pretty basic things compared to whats on Ethereum? Don't Defi applications rely on smart contracts which Bitcoin doesn't have?

Thanks in advance for any answers. Just curious as I was surprised to see talk of Defi dapps on Bitcoin.

[garlonicon]

But Defi applications on Bitcoin will still be limited by its simple scripting abilities, so is it even possible to do Defi applications on Bitcoin?

Yes, but that simple scripting abilities are enough. If you can use Schnorr signatures, you can combine signatures together. So, if you can write something as a sum of public keys, then you can use Taproot. Probably even transactions could be written as public keys, if so, then the whole transactions could be combined in this way. For example: in multisig you need M-of-N keys, but you can also have N-of-N multisig and N-M signatures, in a typical transaction you have N inputs, so you need N signatures, you could for example own one private key and hold N-1 signatures, then you can move coins inside some second layer like the Lightning Network just by creating signatures!

The only limitation is expressing something as a public key. Many things can be expressed in this way, I can imagine for example Pedersen Commitments, where you have "rct=xG+aH(G)". You can just define "H(G)" as a public key where nobody knows any matching private key, multiply it by some blinding factor "a", and use some "x" you want to sum, multiplied by base point G. In this way you can join x'es in a provably fair way and "H(G)" will guarantee that as long as ECDSA is safe, nobody can take that coins alone.

Edit: Also note that Taproot is self-upgradeable. Now we have just the first version of Taproot, but there are many OP_SUCCESS opcodes, so I can imagine in the future some opcodes could be enabled again, for example OP_CAT or OP_SUBSTR. In general, I think that expressing something as a public key or introducing some new opcode is better than having Turing-complete Script, because then you can create opcodes fitting some particular purpose and do it more efficiently. In Ethereum you can do many things, but you have to repeat it over and over again on the blockchain, for me it's better to use "<some> <data> OP_SOMETHING OP_2DROP" than revealing some complicated program with loops and many different conditions each time you want to do something unusual. It's just cheaper to push data, execute one-byte OP_SOMETHING and few bytes dropping that data (to maintain backward-compatibility where OP_SOMETHING was just OP_NOP) than push the whole program over and over again (also because loops are expensive).

[thecodebear]

But Defi applications on Bitcoin will still be limited by its simple scripting abilities, so is it even possible to do Defi applications on Bitcoin?

Yes, but that simple scripting abilities are enough. If you can use Schnorr signatures, you can combine signatures together. So, if you can write something as a sum of public keys, then you can use Taproot. Probably even transactions could be written as public keys, if so, then the whole transactions could be combined in this way. For example: in multisig you need M-of-N keys, but you can also have N-of-N multisig and N-M signatures, in a typical transaction you have N inputs, so you need N signatures, you could for example own one private key and hold N-1 signatures, then you can move coins inside some second layer like the Lightning Network just by creating signatures!

The only limitation is expressing something as a public key. Many things can be expressed in this way, I can imagine for example Pedersen Commitments, where you have "rct=xG+aH(G)". You can just define "H(G)" as a public key where nobody knows any matching private key, multiply it by some blinding factor "a", and use some "x" you want to sum, multiplied by base point G. In this way you can join x'es in a provably fair way and "H(G)" will guarantee that as long as ECDSA is safe, nobody can take that coins alone.

Edit: Also note that Taproot is self-upgradeable. Now we have just the first version of Taproot, but there are many OP_SUCCESS opcodes, so I can imagine in the future some opcodes could be enabled again, for example OP_CAT or OP_SUBSTR. In general, I think that expressing something as a public key or introducing some new opcode is better than having Turing-complete Script, because then you can create opcodes fitting some particular purpose and do it more efficiently. In Ethereum you can do many things, but you have to repeat it over and over again on the blockchain, for me it's better to use "<some> <data> OP_SOMETHING OP_2DROP" than revealing some complicated program with loops and many different conditions each time you want to do something unusual. It's just cheaper to push data, execute one-byte OP_SOMETHING and few bytes dropping that data (to maintain backward-compatibility where OP_SOMETHING was just OP_NOP) than push the whole program over and over again (also because loops are expensive).

Interesting. This is making me want to get into the technicals of Bitcoin more. Maybe I'll have to finally start working my way through that Mastering Bitcoin book I have!

So are opcodes basically a set of predefined instructions, and this is what the bitcoin scripting language is made up of? So scripting in Bitcoin is limited to whatever you can do with opcodes? But with Taproot more opcodes can be added later so greater functionality could be added to bitcoin later on? So it could allow more sophisticated defi apps to be built on bitcoin like what exists on smart contract platforms, but it would potentially be less prone to bugs (and more compact data-wise) because you're just limited to whatever these predefined opcodes let you do rather than the more error prone approach of developers coding up smart contracts from scratch? Am I getting this roughly correct?

[garlonicon]

So are opcodes basically a set of predefined instructions, and this is what the bitcoin scripting language is made up of? So scripting in Bitcoin is limited to whatever you can do with opcodes? But with Taproot more opcodes can be added later so greater functionality could be added to bitcoin later on? So it could allow more sophisticated defi apps to be built on bitcoin like what exists on smart contract platforms, but it would potentially be less prone to bugs (and more compact data-wise) because you're just limited to whatever these predefined opcodes let you do rather than the more error prone approach of developers coding up smart contracts from scratch? Am I getting this roughly correct?

Yes. But also note that even if you use the current version of Taproot, you can do everything that can be expressed as a sum of public keys. If you can convert something to a public key and guarantee that nobody can guess the sum of all keys without everyone else's agreement, then it's safe. Schnorr signatures just allow adding numbers in a trustless way, you hold some number, someone else holds another number, and both parties can produce the sum without knowing all numbers.

[Carlton Banks]

is it even possible to do Defi applications on Bitcoin?

"Defi" is just the latest media-hype buzzword. Asking anyone "what does Defi actually mean?" is a good way of discovering what kind of person they are (hint: the more confident and/or specific reply they give, the more full of shit they are ) It's part of a newsmedia storyline designed to influence how people think about the cryptocurrency marketplace, and so not particularly reflecting reality

taproot/schnorr do indeed enable cheaper complex scripting, and they add some more possibilities of what Bitcoin scripts can achieve. But this is really laying the groundwork for future possibilities, all of which need taproot/schnorr simply to make complex contract scripting viable (i.e. the transactions cannot be too expensive)


for something real, regarding Bitcoin at least, check out "discrete log contracts" (DLC). That technology is _a step_ toward some kind of network layers on top of Bitcoin that could enable more possible types of smart contract systems (but does not focus on smart contracts, it enables a panoply of other possibilities also)

DLC is still in full-on research and design mode afaia, didn't check the details recently. It too will have limitations (assuming it actually come to fruition)