Pages:
Author

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

legendary
Activity: 3430
Merit: 3080
October 20, 2020, 07:11:44 AM
#69
  • 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

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 Wink (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.
legendary
Activity: 2310
Merit: 1422
October 20, 2020, 04:14:22 AM
#68
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
staff
Activity: 4284
Merit: 8808
October 19, 2020, 07:40:39 PM
#67
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.
legendary
Activity: 3430
Merit: 3080
October 19, 2020, 02:37:25 PM
#66
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.

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


So, what I know for now about taproot is that it will make multisig transactions to look like single key transactions.

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
legendary
Activity: 1512
Merit: 4795
Leading Crypto Sports Betting & Casino Platform
October 19, 2020, 11:17:24 AM
#65
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
legendary
Activity: 2310
Merit: 1422
October 17, 2020, 07:35:13 AM
#64
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.]
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.  Wink
staff
Activity: 4284
Merit: 8808
October 17, 2020, 05:21:46 AM
#63
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.]
legendary
Activity: 2310
Merit: 1422
October 17, 2020, 03:11:48 AM
#62
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.
Let's see what happens has a truly encouraging name  Grin
Anyway, I asked this before and it would be nice to have an answer to see whether I got it right or not.
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?
Thanks
legendary
Activity: 2898
Merit: 1823
October 16, 2020, 11:29:41 PM
#61
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.

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?


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

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.


What are the miners proposing? Cool
sr. member
Activity: 279
Merit: 435
October 16, 2020, 06:11:52 PM
#60
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.
legendary
Activity: 3948
Merit: 3191
Leave no FUD unchallenged
October 16, 2020, 08:10:50 AM
#59
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.

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.
legendary
Activity: 3430
Merit: 3080
October 16, 2020, 04:00:13 AM
#58
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.

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?
legendary
Activity: 2898
Merit: 1823
October 16, 2020, 01:10:51 AM
#57
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

it's now merged Cool

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 Smiley

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.
legendary
Activity: 2310
Merit: 1422
October 15, 2020, 08:13:58 AM
#56
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?
staff
Activity: 4284
Merit: 8808
October 15, 2020, 06:05:57 AM
#55
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 Smiley
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.
legendary
Activity: 3430
Merit: 3080
October 15, 2020, 03:58:47 AM
#54
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

it's now merged Cool

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 Smiley
legendary
Activity: 3430
Merit: 3080
September 18, 2020, 11:00:06 AM
#53
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 Cool
legendary
Activity: 3430
Merit: 3080
September 18, 2020, 10:47:22 AM
#52

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)
legendary
Activity: 3948
Merit: 3191
Leave no FUD unchallenged
September 15, 2020, 10:36:46 AM
#51
There's no drama from the trolls/big-blockers so far.

I wasn't expecting any.  It's not particularly controversial and there aren't really any coherent arguments to be made against it.
legendary
Activity: 2898
Merit: 1823
September 15, 2020, 06:18:49 AM
#50
it's now merged: https://github.com/bitcoin/bitcoin/pull/19944

Smiley

(and this is the secp256k1 subtree merged into the bitcoin core repository, it now looks that 0.21.1 will very likely include the taproot/schnorr activation code)


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!
Pages:
Jump to: