bitcoinj fork with Taproot support

Hello all, I am currently working on a fork of bitcoinj with basic Taproot support. Currently it supports basic sending and receiving with Taproot addresses using a bitcoinj SPV wallet. See here: https://github.com/n1ms0s/bitcoinj

It supports the above along with public/private key tweaking. Feel free to take a look, and leave feedback or even work on it yourself and submit a pull request.

One issue I am running into right now though is when broadcasting a Taproot transaction to older nodes (old as in ~0.18.0) I get an error response of "Witness version reserved for soft-fork upgrades". Anyone have any idea why this happens? I have a stackexchange question open here for it: https://bitcoin.stackexchange.com/questions/110787/issue-when-broadcasting-taproot-transaction-to-older-nodes

n1ms0s

Prior to 0.19.0, creating outputs with an unknown witness version was considered non-standard. This was a violation of BIP 173 and was fixed for 0.19.0+ in PR #15846.

On 11/16/2021 10:17 PM, n1ms0s via bitcoin-dev wrote:

> Hello all,
> I am currently working on a fork of bitcoinj with basic Taproot support. Currently it supports basic sending and receiving with Taproot addresses using a bitcoinj SPV wallet.
> See here: https://github.com/n1ms0s/bitcoinj
>
> It supports the above along with public/private key tweaking. Feel free to take a look, and leave feedback or even work on it yourself and submit a pull request.
>
> One issue I am running into right now though is when broadcasting a Taproot transaction to older nodes (old as in ~0.18.0) I get an error response of "Witness version reserved for soft-fork upgrades". Anyone have any idea why this happens? I have a stackexchange question open here for it:
> https://bitcoin.stackexchange.com/questions/110787/issue-when-broadcasting-taproot-transaction-to-older-nodes
>
> n1ms0s

On Wednesday, November 17th, 2021 at 1:07 PM, Andrew Chow via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:

> Prior to 0.19.0, creating outputs with an unknown witness version was considered non-standard. This was a violation of BIP 173 and was fixed for 0.19.0+ in PR #15846.

That's correct, but I think OP's problem is with getting P2TR _spends_ to relay. Those will be rejected by all post-segwit pre-taproot Bitcoin Core releases, as far as I know.

This seems to be the case. I saw your reply on Bitcoin StackExchange as well. In bitcoinj I just made it so the client only connects to nodes with at least protocol version 70016. Seems to work well.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, November 17, 2021 7:00 PM, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:

> On Wednesday, November 17th, 2021 at 1:07 PM, Andrew Chow via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
>> Prior to 0.19.0, creating outputs with an unknown witness version was considered non-standard. This was a violation of BIP 173 and was fixed for 0.19.0+ in PR #15846.
>
> That's correct, but I think OP's problem is with getting P2TR _spends_ to relay. Those will be rejected by all post-segwit pre-taproot Bitcoin Core releases, as far as I know.
>
> --
> Pieter

On Wed, Nov 17, 2021 at 08:05:55PM +0000, n1ms0s via bitcoin-dev wrote:

> This seems to be the case. I saw your reply on Bitcoin StackExchange
> as well. In bitcoinj I just made it so the client only connects to
> nodes with at least protocol version 70016. Seems to work well.

Hi,

This is a clever solution, but when I looked into this I found that P2P protocol version 70016 was introduced in Bitcoin Core version 0.21.0[1]. This release will not ever relay taproot spends because it doesn't contain taproot activation parameters[2]. So this heuristic is imperfect: it only works when it happens to connect to the 0.21.1 and 22.0 versions of Bitcoin Core (or compatible nodes) which were programmed to begin relaying taproot spends starting one block before activation.

Can anyone recommend a better heuristic lite wallets can use to ensure they're connecting to a taproot-activated node? (If not, maybe this is something we want nodes to advertise during activation of future protocol extensions.)

Thanks,

-Dave

[1] https://github.com/bitcoin/bitcoin/commit/ccef10261efc235c8fcc8aad54556615b0cc23be
    https://bitcoincore.org/en/releases/0.21.0/

[2] https://github.com/bitcoin/bitcoin/pull/20165