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


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


11

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


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

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


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


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

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


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


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

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


3

Taproot replaces having the script (say, for a smartcontract) written in the tx itself. It uses the MAST scheme to make it so that the redeem script only needs to validate whatever is in the MAST structure, not have the whole contract code, evaluate it and release the coins. (I'm not sure if I'm technically accurate here, I'm not a developer) It enhances ...


3

From what I've read and heard about MAST, it's an alternate version of pay-to-script-hash that uses a Merkle root instead of a regular hash digest. It combines this idea with that of an abstract syntax tree, which is a data structure that compilers use to parse source code. By "Merkelizing" a syntax tree, it allows redeemers to only expose the parts of the ...


3

First of all, let me clarify that this website just collects the sentiment of miners—it is in no way binding for the actual activation for which code isn't even proposed. Assuming that Taproot will use BIP8 as its activation mechanism, there is only one state in which miners are required to signal. Mining is mandatory in the last difficulty epoch of the ...


2

There are two related risks: Activating without a majority of hashpower supporting it over the long term. Let's use BIP 66 as an example. Imagine it had activated at the 95% threshold, but 30 minutes later, more than half of the miners reverted to the old implementation that doesn't support BIP66. What you now have is a situation where nodes that enforce ...


2

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


2

As per my understanding what you are proposing can be achieved with Schnorr signatures, which will be implemented with Taproot. Since Schnorr signatures permit key aggregation, you can construct a single public key (threshold public key) from multiple participant public keys, which in your case is N + initiator. When spending you can just combine the ...


2

Since it was set to an error by Satoshi and not a SUCCESS, this would be a hardfork for all clients in-between no matter if this was already used onchain before. Just imagine a miner with the new software (which redefines VER as SUCCESS) mining a transaction containing such an OP. All the clients between 0.3.5 and the new one would refuse the block, while ...


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