Re: bitcoinj fork with Taproot support

Re: bitcoinj fork with Taproot support
From: n1ms0s @ 2021-11-17  3:17 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1250 bytes --]

 permalink raw reply	[|nested]
2021-11-17 19:00 ` Pieter Wuille
  
From: Andrew Chow @ 2021-11-17 18:07 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2360 bytes --]

 permalink raw reply	[|nested]
2021-11-17 18:07 [bitcoin-dev] bitcoinj fork with Taproot support Andrew Chow

  2021-11-17 20:05   ` n1ms0s
  
From: Pieter Wuille @ 2021-11-17 19:00 UTC (permalink / raw)
  To: Andrew Chow, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 478 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 683 bytes --]

 permalink raw reply	[|nested]
2021-11-17 19:00 ` Pieter Wuille

  2021-11-21  6:31     ` [bitcoin-dev] Finding peers that relay taproot spends, was " David A. Harding
  
From: n1ms0s @ 2021-11-17 20:05 UTC ( / )
  To: Pieter Wuille, Bitcoin Protocol Discussion



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
2021-11-17 20:05   ` n1ms0s

  
From: David A. Harding @ 2021-11-21  6:31 UTC (permalink / raw)
  To: n1ms0s, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]