New answers tagged

5

TL;DR: depending on what you mean, there is probably no published scheme with a security proof, but there is hope for such a scheme. First, a few clarifications Aggregation is just a concept, not an actual protocol, and there are many ways of accomplishing that. It is made significantly simpler due to Schnorr's linearity property, but the security of a ...


5

Taproot activated in block 709 632, but the first P2TR transactions were in block 709 635. A few P2TR transactions that may be useful for test vectors would be: 33e7…9036, the first P2TR transaction 3777…35c8, the first transaction with both a P2TR scriptpath and a P2TR keypath input 83c8…7d82 with multiple P2TR keypath inputs 905e…d530, the first ...


1

On mainnet there are a number of P2TR transactions in block 709635. A few transaction IDs are included in the index of my bitcoin-dev mailing list post.


1

Yes the payment point would have to be included instead of the payment hash. I believe other than that nothing in the invoices would have to change. Invoices have various fields with various semantics. One of them is the field for the payment hash. In order to stay backwards compatible I guess there will be a new field for payment points (public keys) ...


-1

Yes. Because of schnorr's linearity you can aggregate as many as you want.


0

I have an old pc with Atom N270 that I would like to use as full node, how can I do that? As you can see from the list of pre-compiled 22.0 binaries, there is no Intel 32-bit option available. There is a 32-bit ARM version available, but your Atom N270 is an Intel processor not an ARM processor. Therefore, you will have to download the source code and try ...


3

Bitcoin Core 22.0 only supports 64-bit x86 platforms. The Atom N270 is a 32-bit CPU, so it is not supported. It may be possible to compile the 22.0 source code yourself for a 32-bit platform however, and the result may still work. But you're on your own then.


3

This is unrelated to taproot. The "addresses" field in Bitcoin Core's RPC output was historical legacy that was at best outdated, and at worst confusing. Since 22.0 the field has been deprecated entirely, for all types of transaction outputs. It can (temporarily) be re-enabled using -deprecatedrpc=addresses, but in 23.0 it will be gone entirely. My ...


1

Generally, deprecated RPCs are available for one major release. That would mean this specific one will not be present in Bitcoin Core 23.0 anymore, but will be in any 22.x releases.


4

When wondering if version X of software Y supports feature Z, I find it useful to search for "release notes" Y X https://bitcoin.org/en/releases/0.21.1/ Notable changes Taproot Soft Fork Included in this release are the mainnet and testnet activation parameters for the taproot soft fork (BIP341) which also adds support for schnorr signatures (...


6

As far as I know, there is not even a published specification for MuSig2. One is being worked on at https://github.com/ElementsProject/secp256k1-zkp/blob/master/src/modules/musig/musig-spec.mediawiki, but it is incomplete and has no test vectors.


3

How am I supposed to broadcast a Taproot transaction to older nodes when they won't accept it? You can't. You need to broadcast it to new nodes for it to propagate.


1

Of course Taproot isn't activated at all so all nodes would have treated my transaction as an anyone-can-spend and my transaction would easily have made it into a block. No, the new output types for soft forks are constructed in a manner that they are non-standard for old nodes and thus do not get included in the mempool by old nodes, and therefore also not ...


1

You clarified in the comments that you are using BigQuery datasets and so you are right Taproot transactions should eventually be labelled as witness_v1_.... Taproot only activated a couple of days ago at the time of writing so presumably the authors haven't added Taproot support yet. You can either wait for them to do so (or request they do!) or find an ...


0

Multisignature and threshold signature schemes deal with keys: private and public keys. Addresses before Taproot were hashes of the public key (if it required a single signature from a single key) or the script (if it required a scriptSig to satisfy this script). If you wanted to use n addresses for a threshold signature scheme you would set it up using the ...


1

I don't know so alternative answers are welcome! If you look at the coinbase transaction in the block 709632 (mined by F2Pool) where full nodes started enforcing Taproot rules there is a scriptSig and 4 OP_RETURNs. The scriptSig is: OP_PUSHBYTES_3 00d40a OP_PUSHBYTES_44 fabe6d6db2182a1a8634a5b5c8e4c9102f69b795db3d02e80064a0b007408cca80f68dc110000000f09f909f ...


4

No, Taproot does not change how private keys and their corresponding public keys are generated. The same secp256k1 curve is used, and public keys are still points on that curve. What Taproot changes is the signature algorithm used for Taproot outputs and a few other script things. You can read the full specification in BIPs 340, 341, and 342.


3

As Pieter said in the comments there are Taproot test vectors that have recently been merged into BIP 341. You can also find additional P2TR spends on signet, testnet on block explorers e.g. mempool.space. Any transaction that is spending from a tb1p address is a Taproot spend (tb1q is SegWit version 0 and tb1p is SegWit version 1 as discussed here). ...


1

What can be the contents of an P2TR output script? Is it always OP_1 0x20 <32-bit public key>? A Taproot output contains a 32 byte witness program (or tweaked internal public key) after OP_1. The OP_1 (01) makes it clear that it is a SegWit v1 output rather than say a SegWit v0 output (00). Any scripts are included in the leaves of the Taproot tree ...


2

This is a draft answer. Alternative answers are welcome. Scenarios that don't pose a concern Scenario: A valid or invalid Taproot spend makes it into a mined block before activation (block 709632). It is just treated as anyone can spend as no one on the network is enforcing the Taproot rules until block 709632. This has already happened (executed by 0xB10C). ...


Top 50 recent answers are included