Topic: Taproot proposal - page 25. (Read 11256 times)

Absolutely disagree. Although making an analogy between bitcoin and TCP/IP is void and meaningless it would be worth mentioning how a semi-decentralized infrastructure like TCP/IP was ruined by L2 protocols like SMTP and HTTP giving birth to Internet giants like Google, Facebook, Netflix, YouTube, etc.

It is easy to make void analogies and waste your and other people's valuable time by advocating for L2 and L3 garbage that have nothing to do with basic ideas of cryptocurrency, among them decentralization and anti-censorship. Every shallow minded junior software engineer is able to make fantasies about layers above layers of protocols, feeling smart to understand protocol stacking. They are always prone to this class of mistakes, using design patterns as templates that are applicable to every problem without gap analysis.

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.

Bitcoin Core developers has 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.

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.

Yes
--snip--

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.
So when you build many layers over Bitcoin protocol, this get “compressed as a Jenga piece” and becomes immutable, as the risk of touching it and wrecking something somewhere becomes too high.

After quick research, i just realized Taproot is combination of Schnorr and MAST. No wonder i never see any news about MAST.

I wonder if HTLC on Lightning Network can use Taproot (which would save fees/reduce tx size when open/close channel)?
But if Bitcoin use rolling-release/progressive approach (which is very unlikely)


I disagree, if there's way to optimize "lower" layer which also backward-compatible. I don't see anything wrong with it.
I'd agree if we're talking about implement complex feature on "lower" layer.

Nobody in her right mind would change the TCP/IP and Bitcoin is the TCP/IP of the internet money.

I wonder if HTLC on Lightning Network can use Taproot (which would save fees/reduce tx size when open/close channel)?

Fillippone just  a pawn in the game of Bitcoin, I have enormous amount of respect for Bitcoin developers, and the following statement doesn’t absolutely mean to disrespect the huge work behind this proposal I fully endorse and how will evolve in a BItcoin protocol enanchments.
Writing this because I got misunderstood in some previous discussions.

The more you build on bitcoin protocol, the more it is difficult to change the protocol itself.
With L2 solution (LN and  Liquid) being more and more widespread, and impacting Btc ecosystem, and L3 solutions peeking over the horizon (see my monthly recap),  I guess those are the last possible chances to get something done at protocol level.
Protocol immutability is a feature, not a bug.
Nobody in her right mind would change the TCP/IP and Bitcoin is the TCP/IP of the internet money.

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