Hot answers tagged

13

MuSig is interactive because each signer needs to provide a signature nonce (effectively randomness) before signing. This is not specific to MuSig, but applies to any discrete logarithm-based multisignature scheme as far as I know. Now to understand why multiple communication rounds are necessary let's look at what happens at each of them, starting from the ...


12

Background P2TR addresses will be encoded using Bech32, although likely an amended version. In anticipation of Taproot getting merged, some proponents tested the behavior of various wallets and services regarding segwit v1 outputs. BIP173 prescribes that known restrictions should be enforced for Bech32 addresses, but that "implementations MUST allow the ...


11

From the (very recently updated) bip-schnorr draft: Implicit Y coordinates are not a reduction in security when expressed as the number of elliptic curve operations an attacker is expected to perform to compute the secret key. An attacker can normalize any given public key to a point whose Y coordinate is a quadratic residue by negating the point if ...


8

Beginning with Taproot? Hmm... Something about this feels scary to me. Your mistrust is misguided. So, they are no longer making "signed" installers? The releases are still signed with the release GPG key, what is lacking is the Windows specific binary signatures which have to be made by a paid certificate by one of several authorities Microsoft ...


7

A P2WPKH PubKey is shorter than a P2WSH PubKey. No, not quite. A P2WPKH address is shorter than a P2WSH address. The addresses are both based on a hash of the underlying witness program (i.e. the locking conditions of the output). In the case of Pay to Witness Public Key Hash (P2WPKH) the witness program contains only the public key. On the other hand, Pay ...


7

There is the annex, leaf version, ext_flag, OP_SUCCESS, unknown pubkey types and you could probably include the existing witness version too. I believe that list is exhaustive. The ext_flag isn't so much an extension mechanism in itself; more a structure that permits safely reusing the sighashing code (as opposed to needing a new tag or other mechanism for ...


6

I think that's both very premature, and misses the point. Simplicity is a completely different approach to scripting, with significant advantages, but it's being designed from the ground up. There is lots of progress, but it will require more than just the base layer. You can't just write scripts in Simplicity, and if you have one, you can't just sign for it....


6

Taproot generally has two ways of spending. The default way is to spend the output using the key path: pay-to-taproot then behaves like a p2pk output except that it is using a schnorr signature and the corresponding address being encoded using bech32. The alternative is to reveal that the inner key was tweaked with the root of a Merkle tree, the Merkle path ...


6

Taproot benefits everyone who uses it, but it has the most benefit to those who use complex scripts and multisigs. Since that group is a small portion of users of Bitcoin, that may be why some people are saying it is useful only to that small part of the population. However I would not characterize such statements as meaning Taproot is not useful to anyone ...


6

With respect to the original wording of the question I believe Taproot will actually make the Lightning Network pointfull instead of pointless. While Taproot allows us to save some space on the bitcoin base layer, it will not make the Lightning Network obsolete. Remember, the main issue with respect to on-chain scaling is that a protocol in which every ...


6

Will Taproot allow me to skip Lightning Network and simply use pure Bitcoin Core? Well, Bitcoin Core doesn't support Lightning for now, and probably won't for the foreseeable future, but there is no reason why that can't change over time. I'm going to assume your question is: Will Taproot allow getting all the benefits the Lightning Network provides with ...


5

I think it's important to note first that BIP341-BIP342 are improvements to the Bitcoin script "framework" more than they are improvements to the smart contracting "functionality". All Bitcoin scripts can do in practice is enforce combinations of conditions on signatures by certain (sub)sets of signers, timelocks, and revealing hashes. At ...


5

To add to Michael Folkson's answer, a question one may have is what the differences are between witness versions and leaf versions. Why do we need both? Leaf versions are not revealed until an output is spent, and thus is not known in general to the payer (who is only given an address). For native witness outputs, the witness version is visible from the the ...


5

SegWit introduced versioned witness programs. When satisfying a script to spend coins you need to provide a redeem script consisting of a version byte and a witness program. The version introduced with SegWit was version 0 (zero). The Taproot proposal uses this SegWit versioning system by introducing spending rules for version 1. The witness program to ...


5

Taproot allows inputs to hide the fact that there is a script specifying a contract. If sufficient parties involved in that contract agree and cooperatively spend the Bitcoin, that input looks just like any other input, including ones that do not have contracts and have only one person. This helps privacy as the conditions of a contract are hidden. This ...


5

Previous Bitcoin Core PR review club sessions A good starting point is the various Bitcoin Core PR review club sessions that have been held thus far on specific commits of the Taproot PR. The latest one was on "Implement Taproot validation" (hosted by John Newbery) and there are various notes and a transcript of the meeting there. There are also ...


5

Yes, you can commit to data this way, but there is nothing special about Taproot here. The Pay-to-Contract construction used to tweak the root key in Taproot is generally usable, and has in fact been used for exactly this purpose. In fact, it is one of the mechanisms used in OpenTimestamps to commit to timestamped data (including a variant sign-to-contract ...


4

If this question is about the recently published bip-taproot proposal, the answer is no, you cannot use a v0 script inside a v1 output. The general reason for this is that some of the goals the BIP is trying to achieve are incompatible with v0 scripts. That on itself doesn't make it impossible to support v0 scripts, but reasoning about the benefits of the ...


4

This particular response is approximately tripe. Building on Pieter Wullie's comment. find an appropriate post-quantum DSA and it might push the the time to make Bitcoin quantum-secure from 5-10 to 10-20 years, as much more research is needed. We really know what to do to make Bitcoin Quantum safe, there's been methods for doing hash based ...


4

The idea of Merklized Alternative Script Trees (or previously Merklized Abstract Syntax Trees) dates back to an idea Russell O'Connor had in 2012. The original idea was that you could have alternative scripts or script fragments stored as leaves in a Merkle tree and then the leaves of the tree that weren't used could be pruned away and not take up valuable ...


4

You may have heard before that "Bitcoin is programmable money". Bitcoin uses a simple programming language called Script to encode payment conditions. While today the vast majority of transactions uses standard single-sig outputs (P2PK, P2PKH, P2WPKH) or one of a small set of common scripts (wrapped segwit, 2-of-3 multisig, 2-of-2 multisig with 1-...


4

Pieter Wuille answered this on Twitter. The most important complication of cross input aggregation is explained in this Bitcoin dev mailing list post by AJ Towns. TL;DR: if softforks change which signatures are checked, they mustn't change what is aggregated together. This is especially complicated when they interact with BIP341's OP_SUCCESSx upgrade ...


3

MAST/TAPROOT SCHNORR These improvements are specified in BIP340, BIP341, and BIP342. These documents are fairly mature, and there seems to be community traction for them (though, disclaimer: I may be biased as I'm a co-author), but it's inherently hard to predict when activation will happen. Submarine Swaps This is a Lightning feature, as far as I know. ...


3

Let me start by addressing the misconceptions in the posts you're quoting. DSA (and Schnorr) are inherently based on the discrete logarithm problem, which is vulnerable to (sufficiently powerful) quantum computers. As a result, there is no such thing as a "post-quantum DSA". DSA also doesn't have Schnorr's linearity property - if "linear DSA" means anything ...


3


3

This article expands on the security proof a bit more (with visual aids!) https://medium.com/blockstream/reducing-bitcoin-transaction-sizes-with-x-only-pubkeys-f86476af05d7


3

In general, Segwit v1 is cheaper than segwit v0 to spend but slightly more expensive to create. Segwit v1 output scripts as defined by the proposed taproot BIP will always be 35 bytes in length. However Segwit v0 output scripts are either 22 bytes (for the single key case) or 34 bytes (script hash case). This means that the person sending to segwit v1 will ...


3

It is not part of the BIP drafts we're working on for Taproot, and there has not been any development on it apart from publishing the basic idea. The reason is simply that there are far too many ideas to include all at once; ultimately everything boils down to costs/benefits, and I think just G'root is only marginally useful. And softforks are more than a ...


3

No, it will not be possible to use Taproot on BCH after the hard fork. Taproot requires additional script constructions and interpretations of stack elements which the Schnorr signature algorithm by itself cannot provide. The BCH hard fork merely changes the signature algorithm for specific kinds of OP_CHECKSIG and OP_CHECKDATASIG outputs. No other changes ...


3

1) MAST: Essentially folded into Taproot 2) Taproot: Planned to be part of the upcoming SegWit V1 softfork. A formal proposal for that has been about two weeks away for half a year, so could appear any day now. ;) 3) Schnorr: All SegWit V1 transactions will only allow Schnorr signatures and no ECDSA signatures. I am not sure whether the first release of ...


Only top voted, non community-wiki answers of a minimum length are eligible