From: "David A. Harding" <dave@dtrt.org>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>,
John Barboza <johnbarboza@gmail.com>
Subject: Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173)
Date: Tue, 20 Oct 2020 06:29:52 -0400 [thread overview]
Message-ID: <20201020102952.4iwpugi5dxawufgo@ganymede> (raw)
In-Reply-To: <878sc120f5.fsf@rustcorp.com.au>
[-- Attachment #1: Type: text/plain, Size: 2520 bytes --]
On Tue, Oct 20, 2020 at 11:12:06AM +1030, Rusty Russell wrote:
> Here are my initial results:
A while ago, around the Bitcoin Core 0.19.0 release that enabled
relaying v1+ segwit addresses, Mike Schmidt was working on the Optech
Compatibility Matrix[1] and tested a variety of software and services
with a v1 address using the original BIP341 specification (33 byte
pubkeys; we now use 32 byte keys). Here's a summary of his results,
posted with his permission:
- abra: Bech32 not supported.
- binance: Does not pass front end javascript validation
- bitgo: Error occurs during sending process, after validation.
- bitmex: Bech32 not supported.
- bitrefill: Address does not pass validation.
- bitstamp: Address text input doesn’t allow bech32 addresses due to
character limits.
- blockchain.info: Error occurs during sending process, after
validation.
- brd: Allows sending workflow to complete in the UI. Transaction stays
as pending in the transaction list.
- casa: Fails on signing attempt.
- coinbase: Fails address validation client side in the UI.
- conio: Server error 500 while attemping to send.
- copay: Allows v1 address to be entered in the UI. Fails during
broadcast.
- edge: Allows sending workflow to complete. Transaction stays in
pending state. Appears to causes issues with the balance calculation
as well as ability to send subsequent transactions.
- electrum: Error message during broadcasting of transaction.
- green: Fails on validation of the address.
- jaxx: Fails on validation of the address.
- ledger live: Fails when transaction is sent to the hardwave device for
signing.
- mycelium: Fails during address validation.
- purse: Transaction can be created and broadcast, relayed by peers
compatible with Bitcoin Core v0.19.0.1 or above.
- river: Transaction can be created and broadcast, relayed by peers
compatible with Bitcoin Core v0.19.0.1 or above.
- samourai: Fails on broadcast of transaction to the network.
- trezor: Fails on validation of the address.
- wasabi: Fails on validation of the address.
- xapo: Xapo allows users to create segwit v1 transactions in the UI.
However, the transaction gets stuck as pending for an indeterminate
period of time
I would guess that some of the failures / stuck transactions might now
be successes if the backend infrastructure has upgraded to Bitcoin Core
>= 0.19.
-Dave
[1] https://bitcoinops.org/en/compatibility/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-10-20 10:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-08 0:21 [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173) Rusty Russell
2020-10-08 14:59 ` David A. Harding
2020-10-08 15:21 ` Russell O'Connor
2020-10-15 1:40 ` Rusty Russell
2020-10-16 21:09 ` Pieter Wuille
2020-10-19 0:49 ` Rusty Russell
2020-10-19 22:55 ` Pieter Wuille
2020-10-20 0:42 ` Rusty Russell
2020-10-20 3:31 ` Rusty Russell
2020-10-20 9:21 ` Riccardo Casatta
2020-10-20 10:29 ` David A. Harding [this message]
2020-10-20 20:12 ` Pieter Wuille
2020-10-20 23:52 ` Mike Schmidt
2020-10-21 4:51 ` Rusty Russell
2020-11-06 19:49 ` Mike Schmidt
2020-12-05 23:10 ` Pieter Wuille
2020-12-06 13:04 ` David A. Harding
2020-12-06 20:43 ` Pieter Wuille
2020-12-08 17:39 ` Ryan Grant
2020-12-18 2:02 ` Pieter Wuille
2020-10-21 3:05 ` ZmnSCPxj
2020-10-21 4:39 ` Rusty Russell
2020-10-28 0:20 ` Pieter Wuille
2020-12-05 22:59 ` Pieter Wuille
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201020102952.4iwpugi5dxawufgo@ganymede \
--to=dave@dtrt.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=johnbarboza@gmail.com \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox