TODO: Add Tapscript / Taproot feature

[junderw]

This will be a place to brainstorm ideas...

Needs:

1. Tagged Hashes (maybe make a smaller separate package)
2. Taproot builder (can we wedge this into the existing Payments API??? it seems to act similar to p2sh and p2wsh, and the lazy-loading should help greatly with performance due to the crypto operations to calculate the tweaked pubkey)
3. Segwit v1 Address generation via the Payments(Taproot) API
4. Schnorr signing module. (Modify tiny-secp256k1... not sure what to do with native JS though.)

Questions:

1. When should this be implemented? I'm guessing we should wait for at least a testnet release of Taproot before spending time on it... But at the same time, it would help the development of taproot if we can look at taproot with fresh eyes / a new perspective and make suggestions based on problems while implementing.
2. This is going to be a pretty big change... so maybe it should be a major version bump and that way we can reconsider existing API structure when adding Taproot.

Thoughts and comments welcome.

[junderw]

Working on it now.

Starting with tiny-secp256k1.

I am thinking of implementing TaggedHash and schnorr signing in tiny-secp256k1 itself since it is very bitcoin-specific. There is a PR currently up against secp256k1lib and I'll use that for the C++ addon for now.

WASM was considered to begin with for browsers but we'll put that off for now.

[andrewtoth]

Is there any update on this? I would like to help out if possible.

[junderw]

Hi @andrewtoth, thanks a lot.

There are quite a few large things I need to work on in order to get this out.

You helped a ton with # 3, thanks.

In order of difficulty, the next step would be to create a TaggedHash module. You can take care of that if you'd like. If you want you can just write a single js file and post a gist or create your own repo and I can take it into the BitcoinJS org. If you don't want to maintain it, it should be simple enough so we won't mind maintaining it.

After that... 2 is code-wise next difficult... but concept-wise it's one of the most difficult. I have been debating whether to just scrap the Payment API for a similar API that is more aligned with Output Descriptors. I envision an API where the methods would be able to calculate and output ranges of addresses, and there would be a toOutputDescriptor() method that would output the checksummed output descriptor.

As far as tiny-secp256k1 is concerned... I just need to sit down and do the work... I am thinking of borrowing code from node-secp256k1 so we can update to using N-API for native bindings.

Also I think bitcoinjs-lib should remove tiny-secp256k1 as a direct dependency but rather have it be passed as an optional dependency, that way anyone who doesn't need key operations can use bitcoinjs-lib without installing native addons. Also, you could plug in your own tiny-secp256k1 (I am making a WASM version in rust).

I also want to try and get the WASM version usable for the browser...

It's a daunting task. Though the recent discussions of a deployment schedule have pushed things forward.

[andrewtoth]

Ok, I will get started on a TaggedHash module. Leave that with me.

I have some general thoughts on how we should approach this. I think making big changes before releasing some basic taproot features is a bit too ambitious. It could make taproot adoption for single sig wallets harder than it needs to be.

I started with # 3 because I think getting the ecosystem upgraded to allow sending to taproot is the best way to encourage adoption. Many projects need to have assurance that a good percentage of users will be able to send to a taproot address before integrating receiving and spending. I appreciate your point that backporting BIP350 could break some assumptions so it likely isn't safe to do so. I think we should cut a release with just the address and output generation right now as v6, to give many slow moving projects the ability to upgrade easily.

Next we should add a payments.p2tr that can receive and spend from a single key. That should then be released as a minor v6.1. I think for the vast majority of single sig wallets this will allow them to integrate taproot without burdening them with having to also move away from using the payments API. Adding unnecessary friction to simply switch to a different payment type is the wrong approach IMO.

I think the project should wait for a v7 before adding any complex tapscript functionality that breaks existing API. Let me know your thoughts.

[junderw]

I am against releasing a v6 with just the address changes.

If you are really set on releasing the address change ASAP, add some new methods and revert the changes to the old methods. Then we can release it as a minor version change to v5, and switch back to the currently merged method for v6.

[junderw]

fromBech32m,
toBech32m,
bech32mFromOutputScript,
bech32mToOutputScript

They should probably contain a deprecation warning with console.warn saying they will be removed in v6 for integration in fromBech32 etc.

[junderw]

I would be willing to release that immediately.

[andrewtoth]

But that would make https://github.com/bitcoinjs/bitcoinjs-lib/blob/master/ts_src/transaction_builder.ts#L231 no longer just work with taproot, which is the key benefit in my view.

[andrewtoth]

Ok it would be better than nothing if users of v5 can do txBuilder.addOutput(baddress.bech32mToOutputScript(taproot_address), value) instead of having no way to decode the new addresses.

[junderw]

I made a new branch https://github.com/bitcoinjs/bitcoinjs-lib/tree/v5 (I haven't actually published up to this point yet, but the changes are minor, so we can add the new methods to this and publish it.)

You can add the new methods to that.

[junderw]

Also, unrelated, TransactionBuilder is deprecated and will be removed in v6, so people coding in v5 should be moving to PSBT anyways.

[andrewtoth]

@junderw here's the TaggedHash module if you want to pull it into BitcoinJs https://github.com/andrewtoth/tagged-hash.

[andrewtoth]

It can be optimized by saving the mid state after hashing the prefix. I left an issue comment browserify/sha.js#70. If it's worth it we can implement our own mid state savable implementation. I haven't found any.