Topic: Taproot proposal - page 22. (Read 11651 times)

just to clarify, schnorr sigs are also needed to remove the distinction between single-sig and multi-sig, as signature aggregation (not possible with ECDSA sigs) reduces all the signatures from separate parties in a Multi-sig address to one (the signatures _are_ calculated separately, but the participants then literally add the signatures together to produce a single signature that validates the transaction)

without schnorr's sig-agg, multi-sig txs would still require the minimum quantity of sigs defined as the threshold minimum in the scriptSig, and more than one signatures necessarily means more than one signer (unless you're using multi-sig as a security measure where you sign with 2+ devices, taproot/schnorr protects that kind of user from revealing their security practices also)


but yes, in essence, the net effect of BIPS 340-342 will remove the distinction between "script hash" addresses (beginning with a "1" character) and "public key hash" addresses (beginning with a "3" character). They will appear identical as addresses encoded on the blockchain, and when multisig is used with the typical scripting opcode sequence (1 input, 2 output, locktime set to current block at signing time). Because Lightning opens and co-operative closes are exactly that kind of transaction, they will also now look identical to these pedestrian tx types too (but not for Lightning uncooperative closes, which require a future locktime)

But atypical scripts will still be just as noticeably different as before, the only difference being that alternate paths (i.e. OP_OR sections within the script) will not be recorded to the blockchain, only the path that is actually used to spend the output from the address is written to chain.

I am writing it mostly to merge the content into my head......

• Not all Bitcoin addresses and transactions are equal since we have different address types: addresses starting with “3” are scripts, meaning that they imply multiple keys or implement segregated witness
• Taproot gets rid of the 1/3 address type distinction. As said before, all txs look just like regular transactions from one person to another, no matter how many people participated

Example: let's imagine a payment channel that Alice and Bob opened on the LN. Once they are done, they want to close the channel and take their BTC back. Before Taproot, the channel’s closure implies the creation of a bulky tx, which would reveal too much about what happened. Enter Taproot, this action between A&B would appear as a regular transaction distributing funds to Alice and Bob, as if a third-party had sent them coins.

Sounds cool to me

I think that's not quite the case:  There is a privacy benefit in that single key, multisig, and channels will be less distinguishable, eventually improving the anonymity set for all transactions.  Specifically for coinjoins it means that you could have a single key and a multisig using party coinjoining and you couldn't distinguish them.

Though this is more of a long term benefit once the new style is the most common, initially privacy will be reduced somewhat through the proliferation of more address types.

You're absolutely right though that some people are confusing the aggregation benefits discussed previously with something taproot provides.

there will be no benefit to Coinjoins from BIPs 340-342. Originally, "cross-input signature aggregation" was vaunted to be included in the Schnorr implementation, but in the end was left out (to simplify the changeset IIRC). All that would have enabled is to make Coinjoins cheaper, they would be equally recognizable on-chain as they were before schnorr sigs



right, or anything using a hash-embedded script (including Lighting channels opens/closes)

this is why Coinjoins don't gain any privacy with Taproot, as a Coinjoin transaction is not script hash based

I want to add just a comment. Some people may be mistaking that Taproot will be able to make CoinJoin transactions harder to see, although, Taproots hide scripts and making multisig indistinguishable but it does not directly do anything for CoinJoin.” So, what I know for now about taproot is that it will make multisig transactions to look like single key transactions.

And I will like people to know that Bitcoin’s Taproot is ready now, only remaining it to be included in bitcoin core, but it's unlikely to be included in the next release. The Bitcoin Improvement Proposals 340 through 342 were merged into the Bitcoin codebase on Thursday, signaling that the anticipated Taproot upgrade is ready.

https://cointelegraph.com/news/bitcoin-s-taproot-is-ready-to-go-but-it-s-unlikely-to-be-included-in-the-next-release
https://cointelegraph.com/news/bitcoins-taproot-upgrade-wont-help-privacy-where-it-matters

Ok, cool. I will look into it more. However, the simple fact that openings and cooperative closures will be indistinguishable from ordinary single key payments is great in my opinion. That's a very good step forward. Eagerly waiting for it. 

I believe you will only be able to distinguish the lightning transactions if they are non-cooperative.  Openings and cooperative closures should be indistinguishable from ordinary single key payments.

[I say I believe because I'm not super well versed in lightning details, but this is indeed the idea.]

Let's see what happens has a truly encouraging name 
Anyway, I asked this before and it would be nice to have an answer to see whether I got it right or not.
Thanks

I'm never pessimistic about Bitcoin, but I don't trust the mining-cartel.

Or maybe I'm just excited for another drama, and proved right that full nodes control the consensus rules, not the miners.


What are the miners proposing?

Now the implementation is merged into the reference client, activation discussions slowly restarted on IRC (`##taproot-activation` on freenode).
Here is a wiki page (thanks to David Harding) summing up the "main" different activation methods proposed so far, as well as a rationale and pros / cons for each of them.

I suppose, given the lengths certain trolls are prepared to go to in causing drama, it's easy to get paranoid about this sort of thing.  But honestly, it would be too obvious they were clutching at straws if they tried to oppose such an obviously beneficial change.  Playing devil's advocate, what argument against it would you expect them to give?  I can't think of any downsides.

Miners, I figure, would be indifferent at worst.  There are no negative impacts on them that I'm aware of.  If anything, once aggregation is implemented later, it potentially allows them to earn a tiny fraction more in fees if we're making more efficient use of space within blocks and can occasionally squeeze in a few more transactions.

no-one's voiced any objections up to now. You keep saying it's going to be a problem though, like maybe 5 times already?


why would anyone care about a new scripting type that prevents choices in those scripts from being written to the blockchain?

• everything that _actually_ happens is written to the blockchain, for all to see
• everything that _does not_ happen is unrecorded

I'd be fascinated to hear the arguments that could possibly be mounted against excising unused script paths from transactions, all it does is make multi-path scripts more economical. Secondary effects of this don't change the fact that the chosen script path is still publicly available.

---

ot: You're very negative/pessimistic these days WindFURY, are you feeling ok?

This might be another big trial for the network and its participants after the scaling debate in my opinion. Let's wait, and see if some entities from the mining-cartel play nice.

So let me see if I got this right: after Taproot is activated will it be possible to know if a payment is the opening/closing/mutual closing of LN channel? As far as I understand this, it will be impossible to distinguish if such payment is, let's say, me opening a LN channel. Which is cool.
Right?

That would be really cool, but I dunno that it's almost certain.  One thing you can be certain of is that they'll be ready when they're released.

it's now merged

the schnorr/taproot code will be in 0.21.0, so it's almost certain that activation parameters will be released as a part of 0.21.1

we also have a new BIP 340-342 pull request to github.com/bitcoin/bitcoin (which makes small adjustments to the older pr): https://github.com/bitcoin/bitcoin/pull/19953

positive comments are accumulating already, the case for taproot activation code in 0.21.1 just became that little bit more promising

we may well see some


The most important point:

taproot only hides things that do not even happen. The script that is executed always appears on the blockchain when BTC is sent from a taproot address


stick to that argument, i say

(the troll reply is obvious: "no, the taproot secret script is encrypted with SHA256, not even Einstein and Hawking together could crack it and tell what's in the secret script. and money launderers, and Kazakh warlord gangsters. and people smoking Tide pods". Or something to that effect)

I wasn't expecting any.  It's not particularly controversial and there aren't really any coherent arguments to be made against it.

There's no drama from the trolls/big-blockers so far. Here's to hoping that this is activated as smoothly, and quickly as possible. Onward!