apply D18785 diff raw & rebase

apply D18784 diff raw & rebase

apply D18656 diff raw & rebase

rebase, fix git remote and yeah lets arc land

rebase

rebase

fix author n rebase

fix author n rebase

rebase

fix author

fix author

[Cashtab] Rebase NFToa Protocol branches into a unified integration branch

rebase

rebase & rename branch

rebase

[Cashtab] Merge NFToa Protocol branches into a single integration branch

In D18785#428694, @bytesofman wrote:

arcpatch-D18785

and D18757 is branch arcpatch-D18757_2

how did you get these branch names?

general workflow can be found at https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/CONTRIBUTING.md

it's an issue bc it looks like the branches may not be on master, or the latest master, which could cause problems when you try to land them.

Added a demonstration video showcasing how the NFToa Protocol integration works in action on localhost, covering both Authentication Transaction and Regular Message Transaction as defined in the official NFToa documentation.

Remove ambiguous and unused test function

[Cashtab] NFToa: Clean up and update Protocol ID spec docs

[Cashtab] Add unit tests and adjust for NFToa Protocol ID behavior

[Doc] Restore missing NFToa documentation updates after rebase

[Doc] Fix Markdown table formatting for Phabricator rendering

This documentation update mandates function alignment in D18785 to ensure protocol consistency.

Depends on D18757

Squash commits and clean up the diff for clarity

Updating D18757: [Cashtab] About NFToa Protocol ID

Rebase issue fix

Updating D18757: About NFToa Protocol ID

refine regular message example

1. Updating D18656: Claim NFToa Protocol ID

Addresses all outstanding feedback and formalizes the NFToa Protocol ID specification.

I finally started to understand how I should properly contribute changes to a few lines of code in different parts of the Cashtab folder, specifically regarding the context of the protocol ID claim. This week, I’ll work on improving the way I submit diffs:

In D18656#425502, @Fabien wrote:

Similarly it's unclear why you need the nonce for. Transactions are unique already.

In D18656#425497, @bytesofman wrote:

4c6f67696e20746f2047617564696f20417070 // push "Login to Gaudio App" (17 bytes)

If the types of actions are expected to be limited and defined, it makes sense to assign a code to them. For example you could just say LOGIN for "Login to Gaudio App", or even "L"

The idea is to make OP_RETURN spec as compact as possible since the space is limited and you may wish to add more functionality / actions. There's no need to store "to Gaudio App" in the OP_RETURN since the prefix already takes care of this.

What is the intended use / experience for this? It is simple enough to add and track these kinds of txs, but keep in mind that token indexing would be more complicated than just adding the msgs.

Why the OP_FALSE? is this a version byte?