Add Wallet domain model and abstractions

[SuperJMN]

TL;DR

This PR lays the groundwork for implementing wallet functionalities, including transaction watching, wallet operations, and domain-specific data structures.

It constitutes the domain layer for virtually any basic wallet.

Wallet Domain Model

This PR introduces a clean domain model for our Bitcoin wallet core functionality. The goal is to provide a robust foundation that:

• Creates clear boundaries between domain logic and infrastructure
• Uses Clean Architecture patterns to better represent wallet concepts and business rules
• Will leverage our existing codebase (Angor.Shared, etc.) as the infrastructure implementation

Key Benefits

• Clearer separation of concerns
• More maintainable and testable core logic
• Existing functionality will be adapted as infrastructure implementations

Implementation Strategy

The current codebase (including Angor.Shared) will be used to implement the infrastructure layer, connecting to these new domain abstractions. This ensures we preserve our existing functionality while improving the overall architecture.

Next Steps

Once merged, we can gradually adapt our current implementations to work with this new domain model, ensuring a smooth transition without disrupting current features.

[DavidGershony]

We were having issues with NBitcoin package and .net 9 this might come up as a problem when you plug in the shared project

[SuperJMN]

Oh... Could you provide more details about the NBitcoin issues with .NET 9? I wasn't aware of any specific incompatibilities and it would help me better understand what we might need to address. We can switch to .NET 8 if needed, but I would like to keep current due to the performance improvements that were introduced lately :)

[dangershony]

I think the issue was with the latest version of NBitccoin not dotnet9, I recall the issue with dotnet9 was packaging the blazor application did not work well.
Here is the pr changes with NBitcoin that we made to make it work

I think it is not an issue for avalonia packaging and it will be backwards compatible so it is ok

[DavidGershony]

Will this all go in a DB once we plug one in?

[SuperJMN]

I have just removed the Fingerprint because we won't need it. It was used in the first iterations of the model and I think it's safe to just delete it.

[SuperJMN]

To clarify the persistence model, here are the contents of wallets.json from the implementation in the next follow-up PRs:

[
  {
    "Id": "c3e98932-4756-43c8-87be-cdf35c5a1e40",
    "EncryptedData": "O9kjcVa90lx\u002BuXr/6bRxUtwjRAJ4/St147ry6wVt5RF5zsTXOWNaA\u002BTm7y2xqlRGsWrFH20UBMyKfSemJxb/PgEaM1mv6CPs1wb/Minkuhw33wKSBFYCncBtmeZPgdX/KznwjUDfe6cvGpWUhC/DuevRb\u002BDZ5K4nZTx50CyEmc4LiQ\u002B/bY/3GXcdSmVT6NfnEk\u002BH/R1ufbt85IycfReOhHLloZK6zw6monwLEhuWS0hoZ9ufgUazFcjTs5Kt8UNbB3hgLqzbEls/7i5m8qWkV\u002BPNrKf6FdDT3Qlxkuq\u002B4GYhVhBcNGkhaXP5\u002BDYpApIClBC0c27TMChAJiJ7ni2L88th5Ss45abC71cWRPlyAWG5sD7oZQAezGLcee1cTQTGVw83/hwPcswpefskQReNfek4ySIdpzEMNS3LW9crEbHH0WZR3wMDea0pg/SEGoNp1WOUHBSZsBuBFN5zt7W8TyeDMslHAtJcvJW3OOe84L9/Sven245lKo4A7AacUedLZTCUSqBFs8uwqGG2kDFE4EPh6TeaOUTSOYFRHYKRhR4Uf\u002BsRq1O\u002Btd\u002B9kl6xiZY0q0\u002BlF8FsoRWJj00rGSvp3in3u/zmwkxAWylZ9K\u002BKnQV7s7h3NT2\u002BtUq/sfYn/up/epHzdKFTvadcbwcjZA0VGzg1Uq0v3MoVadaEH8RO3AzCDnq0nvRgL3ncMXM/OVME4mLITI53n\u002BZF6F1iHc69Qjw9aBZr\u002BQNwBiDP2N36aab0MTLnQVhtsu/8OHNm0v4XsyA/nZktvJE87bvcKiTmwWfMoYzG2OU23lTtqskQF\u002B7SNZ9j5dxJLTG92Iu42kqAFxvJzLcwCr\u002BTud10MRRbNA5\u002Bm4gER0WvoCqUOgvQegBQUIOxlZUWY1An0RDkShKk5mR\u002Ba51zgv1cv5hfded2uCM2skNRTpBXeVt0y7Mwt7m\u002BGIpFypbZ\u002BaqD23y6uyB0hmwJ6efgxbIFnDdGdIeL\u002BRDh2upUNVBMjI9081nX1Nk=",
    "Salt": "4XDdhcCEQXzoKwCYipFmSJojY7DyFOh89j1jEfe6fyE=",
    "IV": "4sa1cnbbGe1zn75BMVHoGw=="
  }
]

Note: Since we only support 1 single wallet right now, the Guid is prefixed and always the same. The wallet's essential data (including xpubs) is stored in the EncryptedData field. If we ever support multiple wallets, we'll already have the domain and services parts covered.

[dangershony]

instead of a random generated gui why not use the wallet xpub as the id?

[SuperJMN]

That's a a good question! I went with a GUID for WalletId instead of using the xpub for several reasons:

1. Separation of "identity" from "capabilities":

   • The GUID solely identifies the wallet in the system (even if we allow 1 wallet only)
   • The xpubs define what the wallet can do (derive addresses, etc.)
   • This separation makes the model cleaner and more flexible

2. Security considerations:

   • A GUID doesn't leak any information about the wallet's structure
   • Xpubs are sensitive data that we want to keep encrypted
   • Using xpubs as IDs would expose them in logs, URLs, etc.

3. Multiple xpubs support:

   • A wallet can have multiple xpubs (for different script types)

[dangershony]

xpubs are not really sensitive information AFAIK, on the contrary they are designed to be passed to a 3rd party watch node or so. maybe from a privacy point of view, but still I don't think it is such an issue.

None the less I don't think it is such a big deal we can keep using guids just guids just add unnecessary metadata IMO

[DavidGershony]

This is a bit confusing to me, are the transactions part of the wallet? where is the data coming from?

[SuperJMN]

You're right - I initially created a WalletDomainService thinking we needed domain logic for balance calculation, but I realized it wasn't necessary because:

1. Transactions aren't part of the Wallet entity:

   • They live in the blockchain (our source of truth)
   • The balance is just a derived value from these transactions

2. The data flow is straightforward:

   • Transactions come from our blockchain node
   • Balance is a simple sum of unspent outputs
   • No complex domain rules are involved

I'll remove the WalletDomainService since it's adding unnecessary complexity. The balance calculation can be handled directly in the infrastructure layer.

[DavidGershony]

Is this used for testing? seems very specific

[SuperJMN]

No, this is not just for testing - let me explain the design:

XPubCollection contains the extended public keys that define what a wallet can do. We need this specific implementation because the Infrastructure layer needs these xpubs to:

• Derive addresses
• Track UTXOs
• Calculate balances
• Monitor transactions

To simplify things even more I've changed XPubCollection to derive from Collection to remove unnecessary complexity, while still retaining its domain meaning and purpose.

[dangershony]

Very clean and readable code I like that, what I don't like us using the word Domain in some places. I think we can push this PR and in future PR rename and remove Domain