Replace compatibility with new matrix #1871

bitschmidty · 2024-09-05T13:47:04Z

Todo:

Fix merge markers in contributing @TorokNRoll
~~Add bluewallet data which appears to be missing~~ @TorokNRoll
Fix trailing spaces issues (https://app.netlify.com/sites/bitcoinops/deploys/66d9b65b37a5e10008b28d55) @TorokNRoll

en/matrix.md

_includes/functions/matrix-cell-os.md

bitschmidty · 2024-10-07T13:19:26Z

CONTRIBUTING.md

@@ -95,24 +95,18 @@ JEKYLL_ENV=local make build  # Do a clean build of the site to the _site directo
 diff -ruN _site _site.bak  # Compare the generated sites (-r for recursive, -u for unified, -N for new file)
 ```

-## Compatibility Matrix Data
+## Bitcoin Feature Matrix Data


@TorokNRoll do you want to include the new process for user-submitted contributions for the matrix here?

murchandamus

Hey, this is looking pretty good.

I had a few specific comments on items and fields that I left in the commits, but I was curious about a few more general things.

How do we deal with partial submissions? E.g. someone wants to contribute the bech32 support column and default receive type, but they don’t know about the software’s RBF behavior. Do we have a way of recording that we don’t have data for a field? Or do we just leave that field empty?
I would much prefer collecting "I’m not sure" for a field, instead of an incorrect value.
I think it’s a good idea to get rid of the screenshots, that was way too much work to maintain, but how do reviewers check whether a submission is accurate?
How do we track how recent information is? Is our expectation that all entries in the table are always up-to-date or should we track when a wallet’s information was last updated? If so, would there be a way for us to track that the information might have only been verified partially?

_posts/en/2019-08-20-compatibility-matrix.md

murchandamus · 2024-11-04T17:49:16Z

_data/matrix/Bitkit.yaml

+---
+name: "Bitkit"
+category: "Software Wallet (L1&L2)"
+keyfeatures: "Your ultimate Bitcoin toolkit. Self-custodial BTC and LN payments. Widgets, pay-to-contacts and more"


This sounds more like the project’s self-description. How come the field name is "keyfeatures"?

Since the Feature Matrix is only focused on a given set of features, I added the column Key Features / Use Cases. The objective here was to allow for product teams to highlight things which might differentiate their product, especially if any of their key features are not in the (current) scope of the matrix.

murchandamus · 2024-11-04T17:53:03Z

_data/matrix/Phoenix.yaml

+  default_receive: "P2TR via swap-in-potentiam"
+  bech32: "Send Support"
+  bech32m: "Full Support (send & receive)"
+  segwit_change: "No"


Phoenix having "No Support" for native segwit change when they only use P2TR outputs for receiving surprises me. Is this meant in the context of splicing out to pay someone? Should this field then perhaps be "Not Applicable"?

I will confirm this with the Phoenix team.

As a reminder, all of the entires at this point were submitted by the respective product teams (outside Bitcoin Core Wallet).

murchandamus · 2024-11-04T17:56:19Z

_data/matrix/Envoy.yaml

+  device: "Mobile"
+  os: "Android, iOS"
+  web: "No"
+  hw_interface: "No"


Isn’t Envoy the software wallet that goes with the Passport? If so, how can it not have a hardware wallet interface?

I will confirm with Envoy.

Likely a misunderstanding somewhere along the line.

murchandamus · 2024-11-04T17:57:36Z

_data/matrix/Passport.yaml

+  device: ""
+  os: ""
+  web: "Not Applicable"
+  hw_interface: "No"


Should this perhaps be "Not Applicable"? A hardware signing device wouldn’t be expected to have a HWI, would it?

Absolute novice talking my way through here: If HWI is technically a "_Python library and command-line tool used to interface with hardware wallets_", then I would expect HWI to be "Not Applicable" for Signing Devices (as you suggest).

Would you agree, is that a good way to put this point to rest?

Oh I see. I probably misunderstood that column. I thought hw_interface was generally referring to whether a software wallet can interact with a hardware signer, but now I get the sense that it specifically refers to whether something is compatible with the HWI library.

If that is the intended meaning, it might make sense to call the YAML field just hwi, at least that threw me off. Perhaps the tooltip for that column could also be changed in that regard, I’ll suggest something there.

murchandamus · 2024-11-04T18:27:07Z

_data/matrix/Phoenix.yaml

+
+feature:
+  device: "Mobile"
+  os: "Android, iOS"


In the past we had the issue that e.g. Phoenix had some features that were only live on Android but not on iOS or vice versa. How could we handle that situation in the future?

This is indeed a bit of a curveball, I will need to mull on this.

murchandamus · 2024-11-04T18:28:17Z

_includes/functions/matrix-cell-1-input.md

+{% elsif include.state == "No Support" %}
+  {% assign cell_emoji = "&#x274C;" %}  <!--- No Support --->
+  {% assign cell_tooltip = "No Support" %} <!--- No Support --->
+{% elsif include.state == "Not Applicable" %}
+  {% assign cell_emoji = "&#x2796;" %} <!--- Not Applicable --->
+  {% assign cell_tooltip = "Not Applicable" %} <!--- Not Applicable --->


Could you provide some guidance when to use "Not Applicable" vs "No Support"?

I will refine this, as mentioned above.

murchandamus · 2024-11-04T18:31:33Z

_posts/en/newsletters/2020-01-22-newsletter.md

@@ -115,6 +115,6 @@ wallets and services.*
 [whatsat]: https://github.com/joostjager/whatsat
 [news72 sphinx]: /en/newsletters/2019/11/13/#possible-privacy-leak-in-the-ln-onion-format
 [river twitter thread]: https://twitter.com/philipglazman/status/1216849483184476165
-[wasabi rbf notification]: /en/compatibility/wasabi/#receive-notification
+[wasabi rbf notification]: /en/compatibility/wasabi/


Suggested change

[wasabi rbf notification]: /en/compatibility/wasabi/

[wasabi rbf notification]: /en/matrix/

_posts/zh/newsletters/2020-01-22-newsletter.md

img/compatibility/bitcoin-core/rbf/BCW7-Send-RBF-Default.png

TorokNRoll · 2024-11-05T20:29:09Z

@murchandamus - thanks for the feedback. Regarding your 3 general points:

Partial Submissions - It needs to be noted, that the new submission approach will be via google form. The starting assumption is that actual product owners can easily complete the google form for their own product. In such cases, "I'm not sure" or "Unknown" should not be needed. Nevertheless, we will be happy if a non-product owner wants to provide a submission for their favourite wallet, for example. In such cases, we could anticipate / accommodate a "I'm not sure" /"Unknown".
Verifying submission accuracy w/o screenshots - Starting with my assumption that lots of product owners will manage their own submissions, I would expect accurate submissions. However for other submissions (not by product owners), Is it okay to approach this Wikipedia-like? Meaning: Assume quality submissions and then community can provide corrections if needed.
Tracking Information Freshness - I like this idea....I can create a new column to indicate when the record as a whole was last updated. Regarding the ability to track "information verification", that obviously ties into the point 2 above. Is the Wikipedia approach ok? (my guess is that is obviously way too much to expect reviewers to basically test each product/service).

As an additional note: all of the submissions in this commit were actually provided directly by the product owners.

I will continue with your other comments on various files tomorrow.....

murchandamus · 2024-11-06T15:57:26Z

@murchandamus - thanks for the feedback. Regarding your 3 general points:

Partial Submissions - It needs to be noted, that the new submission approach will be via google form. The starting assumption is that actual product owners can easily complete the google form for their own product. In such cases, "I'm not sure" or "Unknown" should not be needed. Nevertheless, we will be happy if a non-product owner wants to provide a submission for their favourite wallet, for example. In such cases, we could anticipate / accommodate a "I'm not sure" /"Unknown".

Okay that sounds good. I hope that works out, but I think our experience in the past was that we were doing a lot of the submissions ourselves. After something is submitted, how would we get an update on just one field, e.g. after a service adds support for something?

Verifying submission accuracy w/o screenshots - Starting with my assumption that lots of product owners will manage their own submissions, I would expect accurate submissions. However for other submissions (not by product owners), Is it okay to approach this Wikipedia-like? Meaning: Assume quality submissions and then community can provide corrections if needed.

Sure that should mostly work.

Tracking Information Freshness - I like this idea....I can create a new column to indicate when the record as a whole was last updated. Regarding the ability to track "information verification", that obviously ties into the point 2 above. Is the Wikipedia approach ok? (my guess is that is obviously way too much to expect reviewers to basically test each product/service).

Yeah, I was thinking about whether it would be useful or necessary to track the last update per field, but generally, we might want to surface the date of the last update to a service. It would however be possible that a field would have been updated recently, but there are still other outdated fields on the entry.

As an additional note: all of the submissions in this commit were actually provided directly by the product owners.

Well, one problem with that might be that some of the product owners are not that technical and do not respond accurately, see e.g. the contradiction in the Casa data.

TorokNRoll · 2024-11-08T08:08:57Z

@murchandamus - feedback to your latest comments:

1. Partial Submissions - "After something is submitted, how would we get an update on just one field, e.g. after a service adds support for something?"

Updating just one field will also leverage the google forms / sheets. Each entry can be reaccessed via a unique link. The "Updater", would just need to access the link, change the specific field then resubmit. As a heads up, from there, a script is run with generates the updated YAML, which is then dropped in the associated site folder.

here is an example of a unique form link to a test record:

https://docs.google.com/forms/d/e/1FAIpQLSe9HmLCd6Pm3x-QZ8SblSQ06paXBJyeRkvayQXQSlqG72xf9Q/viewform?edit2=2_ABaOnucBG80P--BK_BNY0XZiKDKhTSTgrDgrwEwWrVoW-UEZ28mhqMMUOkKODD5eMpLNav4

2. Verifying submission accuracy w/o screenshots - "Well, one problem with that might be that some of the product owners are not that technical and do not respond accurately, see e.g. the contradiction in the Casa data."

The general best case scenario is that representatives from the "product team" proactively manage their records, very simply via the google form. The google form should remove the friction for anyone to submit small updates, either from the "product team" (technical or not), bitcoin optech team, or just generally speaking. Regarding the Casa contradiction (I still need to review your feedback), once it is clarified, updating the matrix could technically be done in just a few minutes.

3. Tracking Information Freshness - regarding tracking record freshness or field freshness, of course both could be technically possible.

My gut says the tracking on the record level should be sufficient (at least to start with), especially when I consider (1) the extra effort required to actually to set that up (2) and the increased complexity it will add to the UI. Just just adding an extra column "last update" could be done without too much effort.

murchandamus · 2024-11-08T20:23:45Z

Updating just one field will also leverage the google forms / sheets. Each entry can be reaccessed via a unique link. The "Updater", would just need to access the link, change the specific field then resubmit.

Ah that’s really nifty.

3. Tracking Information Freshness - regarding tracking record freshness or field freshness, of course both could be technically possible.

My gut says the tracking on the record level should be sufficient (at least to start with), especially when I consider (1) the extra effort required to actually to set that up (2) and the increased complexity it will add to the UI. Just just adding an extra column "last update" could be done without too much effort.

Don’t worry too much about it, if it is a lot of work. I’m not sure how much value add it would translate to. Also, we can already see in the git log when something was last changed.

TorokNRoll · 2024-11-12T15:39:41Z

@murchandamus

Once v1 of the new matrix is released, I will have the "last update" column at the top of my backlog. I should be able to do that without too much effort. The value would be for casual viewers who would not be accessing git logs, etc.

I reviewed your detailed comments on the code above (which I will reply to now). I would summarise most of your feedback is related to the need to refine the No Support / Not Applicable concept (as you detected inconsistencies, related to that).

murchandamus

I went over the column headers in the table again and added a few more suggestions. These are not urgent or blocking for a merge, but I anticipate that our readers would also bring up similar questions regarding what criteria specifically are tracked in the columns.

murchandamus · 2024-11-12T18:29:59Z

en/matrix.md

+    <th rowspan="2">Category</th>
+    <th rowspan="2">Key <br/> Features / <br/>Use Cases<br/><font size="1"><i class="italic">(hover)</i></font></th>
+    <th class="col-platform" style="display: none;color:blue;" colspan="3">Platform</th>
+    <th class="col-hwinterface" style="display: none;" rowspan="2"><a href="https://bitcoinops.org/en/topics/hwi/">HWI</a></th>


How about:

Suggested change

<th class="col-hwinterface" style="display: none;" rowspan="2"><a href="https://bitcoinops.org/en/topics/hwi/">HWI</a></th>

<th class="col-hwinterface" style="display: none;" rowspan="2">Implements hardware signer support via the <a href="https://bitcoinops.org/en/topics/hwi/">HWI</a> library.</th>

Looks good! thanks for the suggestion.

_posts/zh/newsletters/2020-01-22-newsletter.md

murchandamus · 2024-11-12T18:37:59Z

en/matrix.md

+    <a href="https://bitcoinops.org/en/topics/bech32/">Bech32m <br/><font color="grey">P2TR</font></a><span class="tooltip">BIP350</span>
+    </div></th>
+
+    <th style="vertical-align:top;">Native <br/>Segwit<br/> Change</th>


To be more concrete, P2WPKH, P2WSH, and P2TR all belong to the category of native segwit outputs, but sometimes people use "native segwit" only to refer to P2WPKH and P2WSH while they call P2TR a "taproot output". Sometimes people even think that only P2WPKH is called "native segwit". Therefore, it would be helpful to clarify what the content of this column refers to specifically.

murchandamus · 2024-11-12T18:44:37Z

en/matrix.md

+    <th class="col-feebumping" style="display: none;"><div class="tooltip-container">
+    <a href="https://bitcoinops.org/en/topics/replace-by-fee/">Full RBF<br><font color="grey">Bump<br>Fee</font></a><span class="tooltip">full-RBF</span>
+    </div></th>
+
+    <th class="col-feebumping" style="display: none;"><div class="tooltip-container">
+    <a href="https://bitcoinops.org/en/topics/replace-by-fee/">Full RBF<br><font color="grey">Cancel<br>TXN</font></a><span class="tooltip">full-RBF</span>
+    </div></th>
+
+    <th class="col-feebumping" style="display: none;"><div class="tooltip-container">
+    <a href="https://bitcoinops.org/en/topics/replace-by-fee/">Full RBF<br><font color="grey">Notification</font></a><span class="tooltip">full-RBF</span>
+    </div></th>


For these three columns it would also be helpful to learn what they exactly refer to.

I assume it is:

Bump Fee: "Can use RBF to increase the feerate of a previously submitted transaction"

Cancel TXN: "Can use RBF to change the outcome of previously submitted transactions, e.g. to cancel a payment"

Notification: "Tracks when incoming transactions get replaced and notifies the user"

Good call. As you remember, there is a google form which serves as intake for the entries. On that form, I do have questions similar to what you are proposing. It totally makes sense to have the same questions (via tooltip) on the resulting matrix.

murchandamus · 2024-11-12T18:47:00Z

en/matrix.md

+    <a href="https://bitcoinops.org/en/topics/replace-by-fee/">Full RBF<br><font color="grey">Notification</font></a><span class="tooltip">full-RBF</span>
+    </div></th>
+
+    <th class="col-feebumping" style="display: none;"><a href="https://bitcoinops.org/en/topics/cpfp/">CPFP</a></th>


Similarly, I am curious what criteria gives a wallet a check here:

Suggested change

<th class="col-feebumping" style="display: none;"><a href="https://bitcoinops.org/en/topics/cpfp/">CPFP</a></th>

<th class="col-feebumping" style="display: none;"><a href="https://bitcoinops.org/en/topics/cpfp/">CPFP</a><span class="tooltip">Can create child-pays-for-parent transaction to bump an [incoming transaction|outgoing transaction|any transaction that pays the wallet|at least one of the above]</span></th>

murchandamus · 2024-12-11T20:24:03Z

Hey Steven, I chatted with a buddy from BitGo, he was open to having someone work on the form for the Matrix. Would that be something that we are interested in or should I wait until this is live?

TorokNRoll · 2024-12-27T09:28:25Z

Hey Murch (@murchandamus)....apologies for the slow response, a massive time sinkhole had recently appeared in my life! I am back in the saddle now.....

Regarding BitGo, I prefer to wait until we go live. With that, I will now start to work through your open comments.....which are the final steps before going live....

Once we go live, I would be grateful to have you get BitGo onboard asap! Rolling updates at that point should (theoretically) be a snap!

Thanks

bitschmidty marked this pull request as draft September 5, 2024 13:48

bitschmidty force-pushed the 2024-09-matrix branch from 560ad11 to 9bb645b Compare September 5, 2024 14:13

bitschmidty commented Oct 3, 2024

View reviewed changes

en/matrix.md Outdated Show resolved Hide resolved

bitschmidty commented Oct 3, 2024

View reviewed changes

_includes/functions/matrix-cell-os.md Outdated Show resolved Hide resolved

bitschmidty commented Oct 7, 2024

View reviewed changes

TorokNRoll force-pushed the 2024-09-matrix branch from b8c3461 to 04de591 Compare October 28, 2024 20:03

bitschmidty marked this pull request as ready for review October 30, 2024 13:22

TorokNRoll and others added 3 commits November 1, 2024 10:22

Replace compatibility with matrix

c3cf0be

Matrix: add initial services

493d22e

Additional cleanup items

0696025

bitschmidty force-pushed the 2024-09-matrix branch from 8a08093 to 0696025 Compare November 1, 2024 16:31

murchandamus reviewed Nov 4, 2024

View reviewed changes

bitschmidty requested review from moneyball, jonatack and LarryRuane November 7, 2024 11:26

murchandamus reviewed Nov 12, 2024

View reviewed changes

updates - murch feedback

6e80ac7

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Replace compatibility with new matrix #1871

Replace compatibility with new matrix #1871

bitschmidty commented Sep 5, 2024 •

edited

Loading

bitschmidty Oct 7, 2024

murchandamus left a comment

murchandamus Nov 4, 2024

TorokNRoll Nov 12, 2024

murchandamus Nov 4, 2024

TorokNRoll Nov 12, 2024

murchandamus Nov 4, 2024

TorokNRoll Nov 12, 2024

murchandamus Nov 4, 2024

TorokNRoll Nov 12, 2024

murchandamus Nov 12, 2024

murchandamus Nov 4, 2024

TorokNRoll Nov 12, 2024

murchandamus Nov 4, 2024

TorokNRoll Nov 12, 2024

murchandamus Nov 4, 2024

TorokNRoll commented Nov 5, 2024

murchandamus commented Nov 6, 2024 •

edited

Loading

TorokNRoll commented Nov 8, 2024

murchandamus commented Nov 8, 2024

TorokNRoll commented Nov 12, 2024

murchandamus left a comment

murchandamus Nov 12, 2024

TorokNRoll Nov 13, 2024

murchandamus Nov 12, 2024

murchandamus Nov 12, 2024

TorokNRoll Nov 13, 2024

murchandamus Nov 12, 2024

murchandamus commented Dec 11, 2024

TorokNRoll commented Dec 27, 2024

	[wasabi rbf notification]: /en/compatibility/wasabi/
	[wasabi rbf notification]: /en/matrix/

	<th class="col-hwinterface" style="display: none;" rowspan="2"><a href="https://bitcoinops.org/en/topics/hwi/">HWI</a></th>
	<th class="col-hwinterface" style="display: none;" rowspan="2">Implements hardware signer support via the <a href="https://bitcoinops.org/en/topics/hwi/">HWI</a> library.</th>

	<th class="col-feebumping" style="display: none;"><a href="https://bitcoinops.org/en/topics/cpfp/">CPFP</a></th>
	<th class="col-feebumping" style="display: none;"><a href="https://bitcoinops.org/en/topics/cpfp/">CPFP</a><span class="tooltip">Can create child-pays-for-parent transaction to bump an [incoming transaction\|outgoing transaction\|any transaction that pays the wallet\|at least one of the above]</span></th>

Replace compatibility with new matrix #1871

Are you sure you want to change the base?

Replace compatibility with new matrix #1871

Conversation

bitschmidty commented Sep 5, 2024 • edited Loading

Choose a reason for hiding this comment

murchandamus left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TorokNRoll commented Nov 5, 2024

murchandamus commented Nov 6, 2024 • edited Loading

TorokNRoll commented Nov 8, 2024

murchandamus commented Nov 8, 2024

TorokNRoll commented Nov 12, 2024

murchandamus left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

murchandamus commented Dec 11, 2024

TorokNRoll commented Dec 27, 2024

bitschmidty commented Sep 5, 2024 •

edited

Loading

murchandamus commented Nov 6, 2024 •

edited

Loading