bisq-network / projects

@bisq-network project management
https://bisq.wiki/Project_management
9 stars 2 forks source link

Specify interface and architecture for wallet and blockchain data modules #52

Closed chimp1984 closed 2 years ago

chimp1984 commented 3 years ago

_This is a Bisq Network project. Please familiarize yourself with the project management process._

Description

Research solutions for the wallet and blockchain data modules, provide a proposed solution and specify interface and architecture based on the targeted protocols and blockchains.

Rationale

For the multi-protocol / multi-blockchain project we need to support different blockchains and wallets. Beside that there should be also flexibility for users to make a trade off between best secruity/privacy (full node) vs. low resource requirements (light node).

Criteria for delivery

Measures of success

The provided results are considered sufficient to be used as base for refining the specification.

Risks

Tasks

Estimates

This investigation should be scoped from effort and time. I think 1 month for 1 contributor should not be exceeded. According to that the contributor should post their expected compensation.

Notes

We cannot ship all those different modules in the app, so we need a dynamic on-demand loading concept (see https://github.com/bisq-network/projects/issues/53).

We do not want to take liability for the wallets, so goal is to have only the wallet features required for Bisq trades and keep everything else outside. The wallet binaries will not be part of the Bisq installation but the user has to install them (or point to already installed ones). Reference implementations of wallets should be preferred.

Security is very important and there should be some option that the user can limit risks (e.g. max. allowed transfers per time period). An isolated wallet is preferred over the model that the user connects to their standard wallet which might contain large funds and carries higher risk. Hardware wallet integration should be considered, thought details about integration would be out of scope of that project.

@oscarguindzberg did an investigation about alternatives to BitcoinJ 2 years ago. The scope of the summary matches the expectation of that project. It also can be used as base for checking for light wallet alternatives for Bitcoin. Back then Neutrino was not considered production ready and Electrum was the best choice. https://github.com/bisq-network/bisq/issues/1062#issuecomment-446755367

The Farcaster project RFCs: https://github.com/farcaster-project/RFCs We do not require that level of detail and qualtiy at that stage, but their RCFs can be taken as inspiration and template.

This high level architecture can serve as inspiration as well: https://github.com/farcaster-project/RFCs/blob/master/03-farcaster-architecture.md They have similar challenges as they want to support different blockchains.

There will be some overlap with #53, #54. Those 3 related projects should interact to share findings and report on preliminary results.

ghost commented 3 years ago

I will devote up to 1 month on this and my estimate for cost would not exceed $8000. If my deliverable is not up to standards the DAO can decline my compensation request.

I will deliver progress reports twice a week posted to this thread so that:

Plan of work:

My intention is that prototypes would feature heavily as supporting evidence to the final deliverables.

Link to: Notes;
Link to: Work log;

ghost commented 3 years ago

Update: https://github.com/chimp1984/misq/discussions/5#discussioncomment-748405 & also the two documents linked above.

ghost commented 3 years ago
chimp1984 commented 3 years ago

Do you think the scope of the project is completed? From what I see it seems so.

ghost commented 3 years ago

What remains, from my point of view:

Lets discuss in tomorrow's meeting.

chimp1984 commented 3 years ago

Yes agree an interface for providing the implementations capability would be useful. Though I think we should focus on wallets which support all main use cases. Some blockchains like Monero will be excluded for some protocols due lack of some features (timelock), so that will an additional restriction we have to keep in mind.

I see a RFC document optional at that level, but you can start a draft for it if you think it helps.

Re Electrum/BitcoinJ: So the Electrum API does not support all the required functionality we need? That would be bad. Maybe we can extend it? I have my concerns to use BitcoinJ again due all the issues. Also having the wallet in the same process has higher security risks. For constructing a transaction we could use different approaches as its now in BitcoinJ (where we can construct it on OpCode level). For instance to use a byte representation of the script and replacing the keys which are marked as placeholders (Comit seems to use such an approach).

ghost commented 3 years ago

Spent a lot of time fighting to get electrum to be able to sign a combined transaction between Alice & Bob for funding a multisig trade. Electrum's transaction building routines are a bit weird and nowhere near as good as bitcoin core. Had to resort to deugging electrum code to find out how it works and eventually come up with something barely acceptable. Electrum 4 has rudimentary PSBT support and so alice and bob can each separately sign the same transaction then the PSBT can be combined into a finialized transaction. I did not try the payout part but it should work just the same as the deposit part - they are both two entities signing the same Tx.

https://github.com/jmacxx/misq_prj52_WIP/blob/master/misqWalletRpc4/README.md

I'll leave the Electrum demo at this stage and move on to LND.

ghost commented 3 years ago

Currently only referencing the mainchain functionality. Lightning functionality might conceptually be a sub-interface if possible. Especially as the LND API for lightning is large.

I've spent a month on this it should be concluded by now. Will shift gears back to legacy Bisq work.

chimp1984 commented 2 years ago

Close as completed