Topic: Taproot proposal - page 4. (Read 11253 times)

Not necessarily. Based on some very basic knowledge I have on this, the interest rates on some platforms are around 10%. Some offer less, some more. The taxes differ from country to country, but let's say that 15% to 20% is the average value. Maybe I don't want to sell my bitcoin today and buy back less in a year from now when I pay back my loan. 

You lost me here, sorry.

Are there such platforms and solutions that provide such services?

The idea looks good on paper but it stops there.

Your argument is flawed.
For starters as you mentioned there is an interest involved which could be higher than the tax you have to pay, and that is basically usury!

But more importantly you are comparing an act on a centralized platform (CEX) with an act on what is assumed to be decentralized (DeFi). Change the first part to DEX (no tax report) or change the second part to a centralized token (mandatory tax report) and you'll see that you no longer have an argument.

And finally another big problem is that there is no security in what you described simply because there is no decentralized cryptographic connection between the two chains (eg. bitcoin and a shittoken on a token creation platform like ethereum) and why would you even need a token in first place? You give them bitcoin and receive fiat, when you pay back the fiat you receive the bitcoin. That token doesn't solve anything in this process since the token doesn't ensure return of bitcoin or fiat. Not to mention that bitcoin script language is capable of creating smart contracts needed for a loan which is more than enough.

It’s very laughable that the community that are supporting “DeFi” are saying “Reject Regulations”, are also the same people who are calling for the goverment to stop the U.S. Congress from passing a law that would tax its participants. The Irony of “DeFi”.

I hope I won't sign sound full of shit, but I don't think all aspects of DeFi are useless. Especially the opportunities that have arisen in the money borrowing/lending niche. If you are a law-abiding, tax-paying citizen, you know that every time you sell your Bitcoin or exchange it for another cryptocurrency, you create taxable events. But if you need cash, you can provide your coins as collateral and receive a loan, and that doesn't generate taxable events. Of course, there is interest and other fees to account for, but I don't think this is bad for those who can't get a personal loan, don't want or can use the services of traditional banks. Then there is the interest you can get by lending out your money to such platforms.  

It's very simple, the script interpreter starts with evaluating the output script being spent and when it is version 1 witness script it uses a different route for evaluation. That way it executes the script in another method that checks the OP code to be in a certain range (including those disabled OP codes) and considers them OP_SUCCESS and simply returns true when they are in a Taproot script.
In a way it is bypassing the old evaluation where these disabled OP codes are rejected.

I don’t know if you have noticed the word redefine. I don’t understand how the disabled opcode is redefined by OP_SUCCESS.

once again i came across a very interesting and very informative article today about the upcoming taproot upgrade, which i would like to share with you guys


https://seekingalpha.com/article/4450212-the-bitcoin-taproot-upgrade-is-bigger-than-you-think

OP_SUCCESS simply means "this script is automatically valid", it is the opposite of OP_RETURN that means "this script is automatically invalid". It is needed, because if you want to make upgrades in the future, you want a situation where old nodes consider new scripts as valid, so old nodes will see OP_SUCCESS and accept that as valid without any conditions, but new nodes will add some restrictions.

I'm sorry .When I saw tapscript, I paid attention to this sentence: Many previously disabled opcodes are redefined to be OP_SUCCESS opcodes that unconditionally render the entire script valid to simplify soft fork upgrades. I don't quite understand what is the use of OP_SUCCESS opcodes? Could you explain that?

"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)

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.

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?

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 " 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).

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.

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.

Any examples?

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.

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

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

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?

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).