Taproot proposal - page 24. | Bitcointalksearch.org

Wind_FURY

legendary

Activity: 2898

Merit: 1823

Quote from: Carlton Banks on January 24, 2020, 03:23:04 PM

Quote from: fillippone on January 24, 2020, 10:02:23 AM

I am not the most technical user on this board but I have the feeling this time everyone is well aware of how this improvement is for bitcoin protocol and segwit adoption path drama is a lesson learned on how to manage the BIP process: keeping everyone onboard and proceeding step by step is a way of gathering consensus on the proposal.
do you share this view?

really, I think that it's unfair to everyone to discuss attempts to de-rail this proposal before any such attempts have occurred. it's certainly ironic considering this thread has already been drawn into personality clashes, which the OP was unhappy with seeing as this is the dev & technical board (for which I share some responsibility, regrettably)

But, without intending to derail, what would be a good technical debate against this proposal? Is there one? I believe there's none, or else we would already hear about it from people like franky1.

figmentofmyass

legendary

Activity: 1652

Merit: 1483

Quote from: pereira4 on January 24, 2020, 07:42:43 PM

How far are we from rendering efforts like "chainanalysis" useless?

Every single wallet should be sending transactions that by default obfuscate things so no one is liable of this bullshit idea of having "tainted coins", in other words, actual fungibility.

obviously, schnorr signatures are on deck. that'll allow for cross-input aggregation to make coinjoins indistinguishable from regular transactions. that's a pretty massive development given that exchanges are beginning to target coinjoin users. estimating based on segwit's activation timeline, that could happen by early 2021 or maybe even the end of this year, optimistically.

but "useless"? that's quite a strong word. Lips sealed

confidential transactions (CT) to obfuscate transaction amounts seems like an attractive next step. but my understanding is it requires extension blocks or a hard fork. so.....probably not gonna be implemented at the consensus layer. there's always sidechains though. liquid (blockstream's sidechain) supports CT for example.

pereira4

legendary

Activity: 1610

Merit: 1183

How far are we from rendering efforts like "chainanalysis" useless? As it stands, interacting with fiat exchanges is a risk by default. Most of us are regular people, we aren't criminals, yet, what those blacklisting services do is basically putting yourself into the insane liability of ending up in a risk linked to criminal activity because some of your addresses once pertained to an address that it's on their blacklists. On a long enough timeline, everyone's chances of having coins that are "tainted" increase to the point that it's absurd putting your coins in an exchange.

Every single wallet should be sending transactions that by default obfuscate things so no one is liable of this bullshit idea of having "tainted coins", in other words, actual fungibility. Until then, how is one supposed to deposit coins on exchanges? Again, as of right now, you are playing a sick lottery in which your coins may or not have traces of being tainted, and as time goes on and coins move, everyone's chances just keep going up.

fillippone

legendary

Activity: 2114

Merit: 15144

Fully fledged Merit Cycler - Golden Feather 22-23

Quote from: Carlton Banks on January 24, 2020, 03:23:04 PM

Quote from: fillippone on January 24, 2020, 10:02:23 AM

I am not the most technical user on this board but I have the feeling this time everyone is well aware of how this improvement is for bitcoin protocol and segwit adoption path drama is a lesson learned on how to manage the BIP process: keeping everyone onboard and proceeding step by step is a way of gathering consensus on the proposal.
do you share this view?

really, I think that it's unfair to everyone to discuss attempts to de-rail this proposal before any such attempts have occurred. it's certainly ironic considering this thread has already been drawn into personality clashes, which the OP was unhappy with seeing as this is the dev & technical board (for which I share some responsibility, regrettably)

Point taken.
I wasn’t in any case suggesting anyone to derail anything or clash to anyone.

Carlton Banks

legendary

Activity: 3430

Merit: 3071

Quote from: fillippone on January 24, 2020, 10:02:23 AM

I am not the most technical user on this board but I have the feeling this time everyone is well aware of how this improvement is for bitcoin protocol and segwit adoption path drama is a lesson learned on how to manage the BIP process: keeping everyone onboard and proceeding step by step is a way of gathering consensus on the proposal.
do you share this view?

really, I think that it's unfair to everyone to discuss attempts to de-rail this proposal before any such attempts have occurred. it's certainly ironic considering this thread has already been drawn into personality clashes, which the OP was unhappy with seeing as this is the dev & technical board (for which I share some responsibility, regrettably)

DooMAD

legendary

Activity: 3724

Merit: 3063

Leave no FUD unchallenged

Quote from: Wind_FURY on January 24, 2020, 04:36:19 AM

This would clearly be the biggest Bitcoin update since Segwit on 2017. Are there some people within the community who are against it?

I hope no more drama ensues. Haha.

I'd anticipate that any conflicts would be purely verbal/written and not even remotely a threat to implementation. I doubt we'll see any alternative codebases popping up in opposition or anything like that.

The usual detractors will follow their predictable routine of trash-talk and stirring the pot, but I suspect that's about as far as it'll go.

fillippone

legendary

Activity: 2114

Merit: 15144

Fully fledged Merit Cycler - Golden Feather 22-23

Quote from: Carlton Banks on January 24, 2020, 09:53:39 AM

very positive that BIPs 340-342 are progressing, however mundane that is! I think though that the door is not shut on amendments, but this is still a milestone nevertheless.

I might add that I consider the Taproot soft-fork to be more significant than segwit, the improvement to BTC's money properties and the consequential impact to the overall bitcoin economy are far more substantial than the changes conferred by BIPs 140-144 (despite segwit providing several prerequisites that make taproot possible)

I am not the most technical user on this board but I have the feeling this time everyone is well aware of how this improvement is for bitcoin protocol and segwit adoption path drama is a lesson learned on how to manage the BIP process: keeping everyone onboard and proceeding step by step is a way of gathering consensus on the proposal.
do you share this view?

Carlton Banks

legendary

Activity: 3430

Merit: 3071

Quote from: fillippone on January 23, 2020, 08:36:54 PM

Quote from: Carlton Banks on January 23, 2020, 11:42:25 AM

the pull request is marked WIP (work in progress), so my guess would be no. I think sipa is just soliciting early feedback on his implementation of the BIPs (the details of which we can assume are essentially final)

Officially BIP!
Pieter Wuille on Twitter:

Quote

The Schnorr/Taproot proposal is now published as BIPs 340, 341, and 342; see github.com/bitcoin/bips/

Note that the assignment of BIP numbers is not any kind of stamp of approval; it just means the process was followed (which includes some amount of public discussion).

very positive that BIPs 340-342 are progressing, however mundane that is! I think though that the door is not shut on amendments, but this is still a milestone nevertheless.

I might add that I consider the Taproot soft-fork to be more significant than segwit, the improvement to BTC's money properties and the consequential impact to the overall bitcoin economy are far more substantial than the changes conferred by BIPs 140-144 (despite segwit providing several prerequisites that make taproot possible)

Wind_FURY

legendary

Activity: 2898

Merit: 1823

This would clearly be the biggest Bitcoin update since Segwit on 2017. Are there some people within the community who are against it?

I hope no more drama ensues. Haha.

fillippone

legendary

Activity: 2114

Merit: 15144

Fully fledged Merit Cycler - Golden Feather 22-23

Quote from: Carlton Banks on January 23, 2020, 11:42:25 AM

the pull request is marked WIP (work in progress), so my guess would be no. I think sipa is just soliciting early feedback on his implementation of the BIPs (the details of which we can assume are essentially final)

Officially BIP!
Pieter Wuille on Twitter:

Quote

The Schnorr/Taproot proposal is now published as BIPs 340, 341, and 342; see github.com/bitcoin/bips/

Note that the assignment of BIP numbers is not any kind of stamp of approval; it just means the process was followed (which includes some amount of public discussion).

https://twitter.com/pwuille/status/1220502956023283718?s=21

EDIT:
For the non technical and casual reader an article surfaced on Coindesk:
Bitcoin’s Privacy and Scaling Tech Upgrade ‘Taproot’ Just Took a Big Step Forward

Carlton Banks

legendary

Activity: 3430

Merit: 3071

Quote from: fillippone on January 23, 2020, 07:55:52 AM

A Pull Request from Sipa (Pieter Wuille) for Taproot/Schnoorr consensus rules has been opened on the Bitcoin Core repository:

big news indeed.

Quote from: DooMAD on January 23, 2020, 10:14:31 AM

any elaborations on timescales?

the pull request is marked WIP (work in progress), so my guess would be no. I think sipa is just soliciting early feedback on his implementation of the BIPs (the details of which we can assume are essentially final)

DooMAD

legendary

Activity: 3724

Merit: 3063

Leave no FUD unchallenged

Quote from: fillippone on January 23, 2020, 07:55:52 AM

This is the first step toward the most important protocol change since Segwit, I dare to state.

Excellent news. I suspect a number of people will be watching with keen interest. Have there been any elaborations on timescales? Or are the waters still a little murky for that with so much stuff to figure out on the technical side? Obviously with a significant change like this, they'll be treading carefully.

fillippone

legendary

Activity: 2114

Merit: 15144

Fully fledged Merit Cycler - Golden Feather 22-23

A Pull Request from Sipa (Pieter Wuille) for Taproot/Schnoorr consensus rules has been opened on the Bitcoin Core repository:
[WIP] Implement BIP 340-342 validation (Schnorr/taproot/tapscript) #17977

Quote

This is an implementation of the Schnorr/taproot consensus rules proposed by BIPs 340, 341, and 342 (see current bitcoin/bips#876).

It consists of:

#16902 to avoid the O(n^2) behavior in IF/ELSE/END handling that would be exacerbated by the BIP 342 changes.
Addition of Schnorr signatures and 32-byte pubkey support to libsecp256k1 subtree (bitcoin-core/secp256k1#558 PR 558), following BIP 340.
The taproot validation specified in BIP 341.
Script validation under taproot (aka tapscript), specified in BIP 342.
Addition of signing logic for Schnorr/Taproot to the Python test framework, and tests for the above.
This does not include any wallet support.

Merging this is obviously conditional on getting community support for the proposal. It's opened here to demonstrate the code changes that it would imply.

This is the first step toward the most important protocol change since Segwit, I dare to state.

Xieta

member

Activity: 61

Merit: 40

Quote from: gmaxwell on May 06, 2019, 08:03:27 PM

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html

Quote

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

It's a shame this thread derailed.
Is this still the current proposal or has the discussion on this moved elsewhere?

Best Regards,
-Xi

Wind_FURY

legendary

Activity: 2898

Merit: 1823

Quote from: gmaxwell on May 08, 2019, 04:28:31 PM

Can y'all please stop derailing this thread?

Sorry.

aliasharf let's continue in this topic, https://bitcointalksearch.org/topic/on-bitcoin-and-externality-costs-5140929

gmaxwell

staff

Activity: 4158

Merit: 8382

Can y'all please stop derailing this thread?

aliashraf

legendary

Activity: 1456

Merit: 1174

Always remember the cause!

Quote from: Carlton Banks on May 08, 2019, 09:10:35 AM

Quote from: Wind_FURY on May 08, 2019, 04:16:01 AM

Says who?

Quote from: aliashraf on May 08, 2019, 06:04:07 AM

I say

right, and you make up your own facts

("miners broke the SHA-2 algorithm" which is demonstrably nonsense)

This is an act of trolling, Cheesy

@Wind_Fury started it by asking for ethos instead of logus and now you are accomplishing his job by directly questioning my right to say anything about bitcoin. Very interesting.

If you are mentioning my criticism about ASICs, it is indisputable. PoW is a cryptographic problem, it hates efficiency, any cryptographic scheme does. bitcoin basically was designed for owners of commodity devices with almost average efficiency who join and leave the network freely and voluntarily and pay fairly for blocks they mine:

Quote from: aliashraf on May 07, 2019, 04:58:51 AM

What is hard, the real challenge of bitcoin is improving it in consensus level such that it can accomplish its original mission as a p2p electronic cash system in a scalable fashion without compromising security and decentralization measures. Bitcoin Core developers have escalated this hurdle to an upper level by discouraging (even fighting against) hard forks. Unlike them, I don't see any reason to be such dogmatic about chain splits and hard forks, actually I see a handful of good reasons to have an overhaul every one decade or so.

As a pro you might have noticed that I'm directly questioning Buterin's claim about the existence of a trilemma and suggesting that refuting this claim is the most important job of any serious bitcoin developer and the main agenda for any development project.

What do you think?

Carlton Banks

legendary

Activity: 3430

Merit: 3071

Quote from: Wind_FURY on May 08, 2019, 04:16:01 AM

Says who?

Quote from: aliashraf on May 08, 2019, 06:04:07 AM

I say

right, and you make up your own facts

("miners broke the SHA-2 algorithm" which is demonstrably nonsense)

aliashraf

legendary

Activity: 1456

Merit: 1174

Always remember the cause!

Quote from: Wind_FURY on May 08, 2019, 04:16:01 AM

But every junior developer could also feel smart, and make fantasies of a perfect blockchain-based cryptocurrency too, without any regard for externalities, or without any regard for the risks in messing up the consensus layer.

And senior developers, (like you and Greg Tongue

) should remain open to such proposals and use them at least as an inspiration to confront the real problems instead of sticking with false analogies with a networking protocol and being happy with minor improvements, Right?

Quote from: Wind_FURY on May 08, 2019, 04:16:01 AM

Quote

There is a gap between bitcoin and a networking protocol like TCP/IP: bitcoin is a decentralized application while TCP/IP is a semi-decentralized transport protocol, a good engineer should beware of this gap and avoid stupid analogies between the two.

What is hard, the real challenge of bitcoin is improving it in consensus level such that it can accomplish its original mission as a p2p electronic cash system in a scalable fashion without compromising security and decentralization measures.

Says who?

I say

aliashraf

legendary

Activity: 1456

Merit: 1174

Always remember the cause!

Quote from: gmaxwell on May 07, 2019, 06:20:10 PM

Quote from: fillippone on May 07, 2019, 02:35:33 PM

Sure, I agree on that, but what I mean is that if you build multiple protocol layers over the fundamental layer of Bitcoin protocol, if you modify anything on the lower one, the risk of getting something wrecked in the upper layers increases dramatically.

The Bitcoin protocol has specific carve outs for extension. New extensions are done using these carve-outs. This largely avoids impact on things not using the new functionality.

One can not guarantee a complete lack of interaction-- after all, things built on bitcoin could be full of terrible bugs just waiting to be exploited, and any new behaviour might trigger one of those bugs--, but nothing new shows up in transactions that wasn't permitted all along which at least guarantees that nothing changed that some party couldn't have unilaterally done to you.

The reason technical commentators don't express your concern isn't because it hasn't occurred to them, it's because it has occurred and is largely addressed.

I find it kinda frustrating that no one bothers mentioning concerns like this in the crazy "bitcoin should hardfork once a quarter" threads. Sad

-- why must this kind of concern be conserved for sane proposals where it doesn't really apply?

I hope it wouldn't cause more frustrations but I think both Ethereum approach (hard-forking like quarterly) and yours (do it never ever) to cryptocurrency governance should be categorized as extremism and need to be reconsidered.

Above-thread I objected to @fillippone not to the problem he has brought up but to his solution. He pushes your extremism to its limits and its destiny: leave bitcoin as is! When you abandon radical improvements they need to be implemented on upper layers and besides the centralization and censorship threats involved there will be always a push like that: Don't touch my infrastructure please!

I am against L2 solutions, I think both mining/state-verification in a decentralized ecosystem and on-chain scalability of bitcoin are not achievable without applying revisions in some crucial choices Satoshi made from the first beginning: winner-takes-all approach to mining and linear structure of the blockchain. There is no soft way to do such revisions and no L2 solution would ever solve both scaling and centralization.

Issuing anathema statements against radical improvement proposals that typically involve hard-fork requirements is nothing less than condemning bitcoin.

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