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

_data/matrix/Bitkit.yaml

_data/matrix/Phoenix.yaml

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.

_data/matrix/Passport.yaml

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.

Hello...This point is still open, I have added it to my personal Matrix V2 backlog. Once V1 is released, I will again mull on this.

Point Closed (for V1 matrix release).

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

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

_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.

en/matrix.md

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

en/matrix.md

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.

Hey now....I updated the tooltips with your proposed comments. helpful for sure!

Point Closed.

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>

Also updated per your suggestion!

Point Closed.

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

TorokNRoll · 2025-01-27T13:19:26Z

Hi @murchandamus

to review the status of your comments:

I have updated everything per your requests for Matrix v1, except for two things:

Casa Contradiction: Waiting for your final feedback on the point above.
Passport/Envoy Point: Waiting for feedback from their team

For my Matrix V2 backlog:

Add a last updated field for each record
Determine means to deal with features for a given product which may be live for certain platforms but not others (i.e. your Phoenix example.

....Mike sent out a couple of more review requests, otherwise....we might soon be ready to go. I will be happy to have you then direct BitGo to provide a submission (via the google form). I am looking forward to finally getting this live!

Thanks!

murchandamus

Cool, the tool tips look nice!

This looks like it is basically done. There is a little typo, and one example seems strange to me, but maybe it’s ready for merge and we take care of that in a follow-up PR?

en/matrix.md

Gustavojfe · 2025-01-27T23:31:09Z

I just did an extensive review, great job on this to everyone involved. I have very little feedback, here it is.

"swap-in-potentiam" under Default Receive Address for Phoenix could benefit from a link to https://bitcoinops.org/en/topics/swap-in-potentiam/
The phrasing of the description of each wallet's key features / use cases is not standardized. for example, Envoy's "Envoy is a simple Bitcoin mobile wallet with powerful privacy features." but Bitkit's "Your ultimate Bitcoin toolkit. Self-custodial BTC and LN payments. Widgets, pay-to-contacts and more" . I don't have an opinion here, just pointing this out.

TorokNRoll · 2025-01-28T06:38:13Z

@Gustavojfe - thanks for your feedback! much appreciated.

to your points:

"swap-in-potentiam" - good idea. I will integrate that link...and learn or thing or two!
key features - your point is understood. the basic idea here was to give the products/services the ability to differentiate themselves a bit, especially if the matrix (in whatever "current" form) does not include features which are "key" to them. When I approached some early participants, I could sense they felt uncertain about participating if their "focus" was not explicitly a part of the matrix.

...in the meantime, the update has been pushed with the "swap-in-potentiam" link...that was a top tip!

Thanks again!

Co-authored-by: Mark "Murch" Erhardt <[email protected]>

LarryRuane

Just a few small grammar suggestions. I tested (using the deploy preview) that selecting the various feature checkboxes worked as expected, but I didn't verify any of the content. I'll try to spend a little more time looking at this, but overall it looks good, don't wait for me.

en/matrix.md

LarryRuane · 2025-01-28T22:15:08Z

en/matrix.md

+  <span class="bold">Approach:</span><br/>
+  &#x1F538; The initial features within the matrix have been selected by bitcoinops with a focus on interoperability.  <br/>
+  &#x1F538; The matrix will be split by category, once enough results are collected.<br/>
+  &#x1F538; New feature as well as Product/Service requests are welcome!  Open a PR in the Optech Github.<br/>


Suggested change

🔸 New feature as well as Product/Service requests are welcome! Open a PR in the Optech Github.<br/>

🔸 New features, as well as Product/Service requests, are welcome! Open a PR in the Optech Github.<br/>

Co-authored-by: Larry Ruane <[email protected]>

murchandamus

Good improvements of the phrasing, nice work @LarryRuane.

I think this is getting pretty good, and we can easily address minor improvements like the ones we have been getting in the past days in a follow-up PR, getting more eyes on this might get us a batch of good feedback quickly. I would say this is ready for merge and I am excited to invite people to submit data.

Thanks for your good work and tenacity, @TorokNRoll!

murchandamus · 2025-01-29T13:43:00Z

_data/matrix/Nunchuk.yaml

+  pbst_version: "V0"
+  pbst_export: "Yes"
+  pbst_update_finalize: "Yes"
+  musig2: "No Support"


Could be "Yes" now: https://bitcoinops.org/en/newsletters/2025/01/24/#nunchuk-adds-taproot-musig2-features, but we can also update that later.

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

murchandamus reviewed Jan 27, 2025

View reviewed changes

en/matrix.md Outdated Show resolved Hide resolved

en/matrix.md Outdated Show resolved Hide resolved

TorokNRoll and others added 2 commits January 28, 2025 08:00

Update en/matrix.md

2a21bfb

Co-authored-by: Mark "Murch" Erhardt <[email protected]>

updates - murch/gustavo feedback

439e94f

LarryRuane reviewed Jan 28, 2025

View reviewed changes

TorokNRoll and others added 5 commits January 29, 2025 08:03

Update en/matrix.md

6792c8f

Co-authored-by: Larry Ruane <[email protected]>

Update en/matrix.md

56a0a42

Co-authored-by: Larry Ruane <[email protected]>

Update en/matrix.md

ee0a979

Co-authored-by: Larry Ruane <[email protected]>

Update en/matrix.md

329cd55

Co-authored-by: Larry Ruane <[email protected]>

updates - LR feedback

c276786

murchandamus approved these changes Jan 29, 2025

View reviewed changes

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

TorokNRoll Jan 27, 2025

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

TorokNRoll Jan 27, 2025

murchandamus Nov 12, 2024

TorokNRoll Jan 27, 2025

murchandamus commented Dec 11, 2024

TorokNRoll commented Dec 27, 2024

TorokNRoll commented Jan 27, 2025

murchandamus left a comment •

edited

Loading

Gustavojfe commented Jan 27, 2025

TorokNRoll commented Jan 28, 2025 •

edited

Loading

LarryRuane left a comment

LarryRuane Jan 28, 2025

murchandamus left a comment •

edited

Loading

murchandamus Jan 29, 2025

	<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>

	🔸 New feature as well as Product/Service requests are welcome! Open a PR in the Optech Github.<br/>
	🔸 New features, as well as Product/Service requests, are welcome! Open a PR in the Optech Github.<br/>

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

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

murchandamus commented Dec 11, 2024

TorokNRoll commented Dec 27, 2024

TorokNRoll commented Jan 27, 2025

murchandamus left a comment • edited Loading

Choose a reason for hiding this comment

Gustavojfe commented Jan 27, 2025

TorokNRoll commented Jan 28, 2025 • edited Loading

LarryRuane left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

murchandamus left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bitschmidty commented Sep 5, 2024 •

edited

Loading

murchandamus commented Nov 6, 2024 •

edited

Loading

murchandamus left a comment •

edited

Loading

TorokNRoll commented Jan 28, 2025 •

edited

Loading

murchandamus left a comment •

edited

Loading