Closed chimp1984 closed 2 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.
Update: https://github.com/chimp1984/misq/discussions/5#discussioncomment-748405 & also the two documents linked above.
Do you think the scope of the project is completed? From what I see it seems so.
What remains, from my point of view:
capability
in the interface so that Misq knows if a provider can be used for what kind of trading methodologies (not all chains and not all wallet providers can satisfy the advanced use cases).Lets discuss in tomorrow's meeting.
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).
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.
Capability
enum to the wallet interface so clients can figure out what the chosen wallet can do. https://github.com/jmacxx/misq_prj52_WIP/tree/master/misqWalletRpc5Currently 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.
Close as completed
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.