smartvaults / smartvaults Goto Github PK

Instead of Coinstr - Dashboard [testnet], it could say Coinstr - Dashboard [lee] [testnet]

coinstr> spend 6a4a2d7c0cbb7faee9ba0f41260041875a063940048a53f69c77a710cf158973 mohjSavDdQYHRYXcS3uS6ttaHP8amyvX78 1200 "sending back to faucet"
error: unexpected argument 'back' found

However, using no double quotes or spaces seems to work fine:

coinstr> spend 6a4a2d7c0cbb7faee9ba0f41260041875a063940048a53f69c77a710cf158973 mohjSavDdQYHRYXcS3uS6ttaHP8amyvX78 1200 description
Spending proposal 6a4f229faddac9ae110515be1b08f73b407b53d8bbbae6abc11cc1eebba2bee7 sent

get policies should print the results as a table instead of a list

The table should have 3 columns: ID, Name, and Description

The ID should be the first 5 chars of the Event ID where the policy is saved.

get policy <policy_id> should print the entire policy, which includes the TapTree and bitcoin balances

Develop a single page client to verify a proof-of-reserve published to Coinstr as a Nostr event.

• Input will be the nostr event id
• Page will allow the user to select 1 of many relays from a drop down to read the event from
• Page will allow the user to select a bitcoin node and/or electrum node from a dropdown to verify the proof against
• Page will verify signatures of the transaction and show the balance of the reserve (at the time of the proof?)
• Page will show signatures and Nostr profile data of signers

A "policy" is made up of:

• name
• description
• bitcoin output descriptor

When the user creates and saves these, they should be saved to their self-DMs on the Nostr relay. Perhaps a new event kind or tag is needed for this (?).

Functions needed are:

• save policy
• get all saved policies

To reproduce, can use Lee and existing test policy. Create new PoR, Approve, and then Finalize.

Also, I'm unable to verify with the CLI:

coinstr> proof verify 1863e44f7457a1eb3a35db79bcd75f6f9e6f984f6fdcbb0625e8e7cfb64776e6
Error: sqlite: completed proposal not found

User should be able to configure a block explorer prefix (or select from a list), relays, and electrum endpoints in the GUI

The keechain unlock password should be able to be entered as an environment variable or as an argument parameter (don't need both, but either). This will allow for coinstr-cli to be scriptable and not dependent on interactivity.

The relay.rip relay will be used for demos. We need to be able to reset the demo environment relatively easily via scripts. This issue tracks the progress of setting up the automation.

The following should be done for the Waterwell contacts and Trey Smith family contacts.

• Create profile metadata
• Set contact lists
• Create Signer (xpub) for each user
• Share Signer with contact list
• Create Policies
  • Waterwell majority of board members
  • Lee and Sarah 2 of 2
  • Henry and Margaret inheritance policy
• Create Proposals
  • Waterwell: big policy: fund new well project
  • Waterwell: 2 of 2: pay milestone 3 equipment installation
  • Henry and Margaret - pay for tuition for grandchild

To reproduce:

./target/release/coinstr subscribe --publisher bob --subscriber alice 

In other terminal, which works, is:

./target/release/coinstr publish --content "test content from bob" --user bob

User should be requested to select which UTXO(s) they wish to send as part of a transaction.

The names of the keys for the signer offering metadata event should be:

• temperature (possible values: warm, cold, air-gapped)
• response_time (time in minutes?)
• device_type (the brand of the cold card, view the comment below)
• cost_per_signature
• yearly_cost_basis_points(percentage of the vault balance that should be charged)
• yearly_cost

Some data within a coinstr policy is required as part of the policy itself, namely the output descriptor.

There is other metadata that may need to be stored with the policy that is used by the UI. For example, the blockly interface requires the xml field shown in the below.

Also, in the below, the keys represent users that are "Added to Policy" but may or may not be actually part of the output descriptor. In these cases, I think only the keys themselves are likely enough data since the contact list metadata will be retrieved by the UI every time the user logs in anyways.

{
    "xml": "<xml xmlns=\"https://developers.google.com/blockly/xml\"><block type=\"begin\" id=\"s3zMsKO[BDKY-|`ZE|Go\" deletable=\"false\" editable=\"false\" x=\"260\" y=\"10\"><field name=\"SPACE\"> </field><next><block type=\"thresh\" id=\"mgx]p@,N7_vgutsXjI?G\"><field name=\"Threshold\">1</field><field name=\"SPACE\"> </field><statement name=\"Statements\"><block type=\"pk\" id=\"E$tv{1KVJze^2#u{#tI+\"><value name=\"Key\"><block type=\"my_key\" id=\"F?Up(j{OmcNe^o^.;ffT\"/></value><next><block type=\"pk\" id=\"Y]F2x(BiZ|Y.m}bc29P@\"><value name=\"Key\"><block type=\"key\" id=\"=Vizxf0dm0nQQ:PNxG(I\"><field name=\"Key\">101e7953a54b18d0f41ea199b9adf2d7e643441b5af8e539531e6d7275cee1df</field></block></value></block></next></block></statement></block></next></block></xml>",
    "policyCode": "thresh(1,pk(ea527e059759d368a55253270454e58e9d6e4fe2e98d302d6e01821fa973259d),pk(101e7953a54b18d0f41ea199b9adf2d7e643441b5af8e539531e6d7275cee1df))",
    "keys": [
        [
            {
                "about": "Vice Chairperson, Water Well",
                "banner": "https://coinstr.app/coinstr.png",
                "display_name": "John Chen",
                "name": "john",
                "nip05": "[email protected]",
                "picture": "https://img.freepik.com/premium-vector/profile-icon-male-avatar-hipster-man-wear-headphones_48369-8728.jpg",
                "npub": "npub1zq08j5a9fvvdpaq75xvmnt0j6lnyx3qmttuw2w2nrekhyawwu80s7tz8rm",
                "bitcoinAddress": "101e7953a54b18d0f41ea199b9adf2d7e643441b5af8e539531e6d7275cee1df",
                "isSelectable": true,
                "label": "John Chen",
                "pk": "101e7953a54b18d0f41ea199b9adf2d7e643441b5af8e539531e6d7275cee1df"
            }
        ]
    ]
}

This is a list of improvement ideas for the UI.

• Add approval history to Proposal screen - it currently shows the approvals of the logged in user, but can it show all approvals on a given proposal, who approved, and when.
• Dashboard should show currently open proposals above the Transaction history, below the balance
• On proposal list screen, can the Policy ID be a link to open the Policy details screen
• Add timestamp (UTC or local time zone) to the transaction history list
• Dashboard should show approvals
• Policy list screen should show the current balance of each of the policies
• Policy list screen - Policy ID column should be more narrow since it should always be the same length. This will make more room for the description.
• Dashboard should show the sum balance of all policies (maybe it does this already)
• When dashboard initially opens, it shows with a blank screen before it becomes populated. Should this show as 'Loading..."?
• Save Policy screen should show multi-line input boxes (text area?) for the description and descriptor

The names of the keys for the additional properties in the key agent profile should be:

• jurisdiction
• x
• facebook
• linkedin
• smartvaults_nip05 (nip05 specific for smartvaults where will add the agents approved by us)

method name: sign_psbt

params: [network: string, psbt: string, descriptor?] //the descriptor could be optional

result: {
psbt: string,
finalized: boolean
}

On iOS, we are going to use the Keychain Service to store the mnemonic. It will be secured by biometrics, PIN, or both (?). This prevents the user from having to manage an additional password.

Once the mnemonic is unlocked on the device, it can be passed to the CoinstrSDK but shouldn't be stored in this case.

Description

When executing the "make gui" command on a MacBook Pro M2, the following error is encountered: " note: ld: warning: ignoring file /Library/Frameworks/Python.framework/Versions/3.9/lib/libpython3.9.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64 Undefined symbols for architecture arm64:". This error indicates a syntax issue with specifying the architectures.

Task Description

Investigate and resolve the compilation error that occurs when running the "make gui" command on a MacBook Pro M2.

Reason for Changes
Fixing the compilation error is crucial to ensure a successful build of the project. By addressing the syntax issue and providing possible solutions, the "make gui" command can be executed without errors on the MacBook Pro M2. Resolving this issue allows for further development and testing of the project.

The policy builder requires that the user be able to retrieve a list of who they follow from Nostr, including the avatar, display name, and NIP-05. The user uses this information to add users to the Policy Editor window.

The Rust/WASM feature required would be a function that returns the data set in a single call, a list of items with the avatar URL, display name, and NIP-05 already in the payload/return type.

Key agents are users/services that protect and use a key to sign transactions at hire of the subscriber. Key agents have a general profile and 1:n extended public keys associated with their profile.

What data on the key agent profile is public? IMO, it's like a public social media profile.

A key agent may share their key with users (or vice versa), and either party can create vaults with both participants. In many cases, the key agent will be the vault creator.

The key agent profile can be like a normal nostr profile with additional metadata, either key/value pairs or attributes like jurisdiction, social media links, etc.

Each key will have metadata, either key/value pairs, or attributes like temperature, response time, device type, cost per signature, monthly cost in basis points, etc.

What data on the key agent profile is public? IMO, it's like a public social media profile.

Key agents should be able to communicate with their clients directly in the app using Nostr DM protocols.

Key agents should be able to post public events to the Nostr timeline and have them appear with their profile in the app.

When new activity occurs (key shares, proposals, etc), users get a DM style message and push notification.

When a user generates a receiving address, they should be required to enter a label for the UTXO that is saved.

New command for proposing a send on a policy:

coinstr spend <policy_id> <memo> <to_address> <amount_in_sats>

This command should create a new transaction and set of PSBTs to be sent to each prospective signer. Each signer in the policy should receive a DM note (as a new kind?) that contains the memo, to_address, and amount_in_sats.

New command for reviewing proposals:

coinstr get proposals 
coinstr get proposal <proposal_id>

Subsequently, the command for approving proposals would be:

coinstr approve <proposal_id>

Which would sign the PSBT and return it to the proposer.

Would it be possible to add the #nostr tag to this repo I'll show up in this nice list here: https://github.com/topics/nostr

• Add display names, usernames and avatars for all users
• Add family policies for Trey and add Trey to Waterwell BOD
• Add demo script for Waterwell 3 of 5
• Add demo script for Family policies
• [ ]

I've been doing some tests to determine if it's possible to make signature, encryption and decryption actions to the browser signer extensions from WASM, and it seems to be possible, which opens the possibility of using the coinstr core library in the web app. For this to work I think that the cointr core library should receive an object that implements the SIgner trait (that handles signing, encryption and decryption), so that we could create various implementations of it, one of them being the WebSignerExtension. I was thinking of the Signer trait being something like the following:

#[async_trait(?Send)]
pub trait Signer {
    async fn public_key(&self) -> Result<XOnlyPublicKey, Error>;
    async fn encrypt(&self, public_key: &XOnlyPublicKey, plaintext: &str) -> Result<String, Error>;
    async fn decrypt(&self, public_key: &XOnlyPublicKey, ciphertext: &str) -> Result<String, Error>;
    async fn sign_event(&self, event: UnsignedEvent) -> Result<Event, Error>;
}


#[derive(Debug, thiserror::Error)]
pub enum Error {
    #[error("get public key error: {0}")]
    GetPublicKey(String),
    #[error("encryption error: {0}")]
    Encrypt(String),
    #[error("decryption error: {0}")]
    Decrypt(String),
    #[error("sign event error: {0}")]
    SignEvent(String),
    #[error(transparent)]
    Secp256k1(#[from] secp256k1::Error),
    #[error(transparent)]
    Unsigned(#[from] nostr_sdk::prelude::unsigned::Error),
    #[error(transparent)]
    Serde(#[from] serde_wasm_bindgen::Error),
    
}

Coinstr is a mash-up of BDK's Elephant, Nostr, Nostr Connect, and NBV of Hashed Network. It is the same product as 'Native Bitcoin Vaults'.

Here are some steps to get started understanding and working with the components.

• Read my article about nostr-connect and remote signing: https://coinstr.app/articles/nostr-connect/

• Use nostr-tool (or the Go CLI named noscl or a JS/Dart one) to query the events on our relay

mkdir ~/github.com/0xtrr && cd ~/github.com/0xtrr
git clone [email protected]:0xtrr/nostr-tool.git
cd nostr-tool
cargo build --release
./target/release/nostr-tool -r wss://relay.house list-events -l 1

• Run through the tutorial steps for testing rust nostr's nostr-connect example with the nostr-signer CLI. https://gist.github.com/3yekn/116ebb9ea4f1297b8fbbbca75ea28cb8 - let me know if there are errors in these steps or something isn't clear.

• Read through the MVP scenarios here: https://docs.google.com/presentation/d/1l9NV_Wh9RwH5A9NPlg4ZxK14i-aqeNPuc9APJrMs-Lc/edit?usp=sharing

• Try running some of the Coinstr tests: https://github.com/hashed-io/coinstr

• Does it make sense to have a consolidated User type that wraps around Bitcoin, Nostr, and Hashed users? Can you update the hashed_user.rs to be able to submit extrinsics? https://github.com/hashed-io/coinstr/blob/main/src/user/mod.rs#L11

Architectural decisions to make:

Web app

• Should the web app use BDK's rust-to-WASM approach to work with blockly and bitcoin? Or is it possible/ preferred to use pure JS/TS?
• Run our fork of elephant
• Try replacing the list of 'Remote Keys' (where it says Identities from Pallet or Nostr) with a list of users that the currently logged in user follows on Nostr.
  • https://github.com/hashed-io/elephant/blob/master/src/keymanager/mod.rs#L198
  • How do you read the list of followers from a relay? Or is that only saved client side? https://github.com/fiatjaf/noscl/blob/master/home.go#L12

Mobile app

The multi-purpose signer (Hancock) needs to integrate with Nostr, Bitcoin, and Substrate.

• Which mobile codebase is the best starting place for the multi-purpose signer?
  • Nostrum, React Native, knows Nostr and nostr-powered signature requests already
  • Hashed Wallet, Flutter, knows Substrate and EOSIO
  • Anchor or Parity Signer, native apps, which know EOSIO and Substrate respectively but not Nostr or Bitcoin

• Setup relay and test case for publish and subscribe for Alice, Bob, Charlie
• replicate FROSTR Multisig signing of new nostr events
• use nostr accounts to populate keys on elephant no-code blocks
• send DMs to users with signature requests
• users sign DMs and reply with signature
• merge and broadcast