Documenting the process

[mouxdesign]

Thought it might be an idea to document the process that has been done so far.

1. Screen discussions

Screen discussions: We met virtually and all jammed on figma. This was done over a few calls where we looked at the individual screenstates of the current GUI and discussed various aspects of that. Some comments were made around certain features, as well as whether to move certain features to different screens and so forth. Figma file

2. Created an initial design document

Christoph created an initial planning document, outlining the possible steps we could take as well as things we would have to think about during the design process.

Planning document

3. Created user stories

Christoph created some initial user stories where he tried to think about the different user groups and how these groups would use the gui. He created 4 different user stories.

1. As a user, I want to…
2. As a casual user, I want to…
3. As an experienced user, I sometimes want to….
4. As a developer, I want to… The document with the user stories can be found here

Within the design document some initial sections were created which might exist within the interface.

4. Grouped user stories

Mo then grouped the user stories under the various categories (mentioned above). The purpose of this was to see which user story fitted under which area of the interface design. With a goal possibly being of when the initial designs are iterated we can go back and look at if the user stories are fulfilled by the design itself.

Figma file

We also thought about prioritizing the user stories and will be thinking more about that as well. We also thought about interviewing the devs to ask them about what user stories they would like included.

5. Collaboration guidelines

Christoph had an idea on how to collaborate on the design process, that can be found here https://github.com/BitcoinDesign/Bitcoin-Core-App/discussions/23

[mouxdesign]

Initial direction

After having a call with the devs yesterday, we discussed two things:

1) Minimum viable product

A minimum viable product (MVP). This would ensure that the build process is starting with some core fundamentals and then moving into the complexity as we move forward.

To build a MVP, I asked the question which part of the userflow could we best focus on. The devs mentioned in this initial phase it would be good to focus on:

Onboarding -> Create wallet -> Send and Receive

In the create wallet options an idea was to focus on:

• Single sig
• Multi sig
• Watch only

2) Menu layout options

Primarily there are 2 options to layout the menu, a horizontal menu layout as well as a vertical menu layout.

Christoph created some design ideas around both and we had a small discussion around which menu options would be available.

While both menu layouts have their strengths and weaknesses, at this stage all ideas are still being explored. We also discussed the layouts and the strengths and drawbacks of each layout.

[mouxdesign]

Block clock design

Christoph has come up with some variations of the block clock which he has shared on Youtube for some feedback. During the onboarding process the block clock is introduced showing the blocktime. There is a circular display indicating the clock and there are 2 variations of this. One variation has the blocks as individual units and the other variation has the clock as a continuous circle.

Link here to the video walkthrough

User flow

Mo created a user flow and we jointly worked within this flow yesterday exploring it and expanding it mostly within the send section.

Link to userflow

[mouxdesign]

We discussed issue #158

This issue addresses a cleanup of the available screens. From that discussion is was decided on to focus a bit more on:

Connection Screen settings

At the moment within this screenstate there are two settings:

• Database cache size
• Script verification threads There has been a discussion around possibly moving these to detailed/advanced settings.
  MASTER PR

Init Error message

This is essentially an error during the initialization phase. We had a discussion around re-designing this screenstate and at the moment have some rough modal designs.

Proxy Screen + Disabled screen settings

We did an initial design exploration around this screen today with the idea of presenting some ideas to the devs on the next call.

How to contribute page

Christoph has worked on the how to contribute page and has added alot more content to it. Suggestions to the content can be added here.

[mouxdesign]

During the last 2 calls; one of which was with the devs and the 2nd was a design focused call. We discussed the following:

Design documentation

We discussed the design documentation website which is live. The goal of this documentation is for new design contributors to have an overview of the project as well as the design principles as well as how design decisions were made. This is fully open for contributors and feedback.

Storage screen

There are currently 3 screens focused on storage, there is an idea to perhaps remove the 3rd screen.

Multisig signing screens

We reviewed the multi sign signing screens which were designed by Gene

Create wallet: Regular wallet

Some initial designs were created and an initial user flow for the create wallet flow. This is still in its very early stages and many further iterations will be made based on the feedback from the devs as well as some technical considerations which we will research.

Create wallet: Regular wallet: User flow

[mouxdesign]

During the last 2 calls we discussed and made decisions on the following:

Roadmap

Christoph created a roadmap to track all the tasks within the gui that are being worked on at the moment. This is a nice easy tool to use when there are multiple people working at the same time and keeps for easy clear collaboration

Blockclock

We decided now at the initial stages it would be best to go for the design of the blockclock that is the easiest to implement for the devs

Storage location settings

There are some duplicates in some of the settings. It will be worked on in the future as to how to work with these.

Clickable prototype

It was discussed to create a clickable prototype two parts of the userflows which have been designed; onboarding as well as the create wallet flow.

Blockclock

Shashwat has created an initail iteration of how the block clock could show up in the gui.

Focus states

Some design decisions were made around the focus states. The designers agreed that: Design decisions:

• The Focus outline would be in purple

• There would be an offset with the outline. Filled and outlined buttons would have an offset, free buttons the outline would be inset.

• List items: Hover: Orange light 1 Active: Orange light 2

• Error messages would show a red outline as well as red text under the input box with a warning icon.

[mouxdesign]

Our last 2 calls were very good, quick summary below:

Designers documentation

We discussed cross linking the design documentation with the developers documentation. We looked at the information architecture of the designers website. Below a quick look at the possible information architecture of the website.

Onboarding & Create wallet

We focused on the user flows for both onboarding as well as creating a wallet. During our second call we looked at the user flow of both and got some valuable input from the devs.

With the creating wallet flow we also looked more at the userflows for creating:

• A regular wallet
• A view only wallet
• A multisig wallet

[mouxdesign]

Blockclock

• The Blockclock is further along in development.
• Shavaan needs to figure out a workaround with regards to displaying the segments
• Suggestion from Christoph is to use the gradient approach

User expectations

We had a discussion around how to manage user expectations during the onboarding and create wallet process. Two things that affect the initial user exp are 1) The internet bandwidth it takes to sync to the network 2) The amount of hard drive space it uses on the users pc

We also discussed 2 things that a user could do during the IBD, at the moment there are only 2 things a user can do; 1) Seeing how much of history is downloaded 2) Seeing who you are connected to

Do we need to educate users about 1) That the initial download might slow down their pc. 2) There are some there tasks they can do (read the whitepaper) while waiting for the initialization process to continue.

Create wallet flow

We spoke about the create wallet flow which was further worked on by Micheal. We all commented on this flow idea and found it good as an initial iteration. The design can be seen below.

We also looked at the copy on the screenstates themselves as well as the copy on the labels and agreed that the copy itself needs a good thorough look to adjust it for consistency and understanding. Having good copy is going to be essential to the users exp of the gui.

Peers window

We also discussed whether in the future it might be relevant to create a screen for a peers. The purpose of this screen would be so that users can 1) Add more peers 2) See how many peers the currently have

[mouxdesign]

Block clock implementation

Shavaan has coded the block clock which now very closely resembles the original block clock design made by Christoph. The now coded design shows the different fractions of how the clock is broken up/fragmented.

Onboarding flow

Christoph worked further on the onboarding flow and we would say it is about 90% finished now. Some items that are still being discussed are:

• Do we want to make it optional in the beginning to allow a user to skip the encrypt wallet part until they make a first transaction? Or do we want to design it in a way that the encrypt wallet is highly suggested but allow an option to skip it.

Copy: With regards to terminology used we will during the process of looking at the designs also ensure that the copy amongts all the screenstates are related and connected. So for example using the word passphrase on one screen should then be used across the other screenstates as well to maintain consistency,

Dashboard time: This is another concept we discussed as to how that time with syncing with the network will be shown on the interface.

Top navigation

Design decisions and explorations are now also being made for the top navigation.

Create wallet flow

Some additional designs/iterations have been made to the create wallet flow as well:

• The create password section has been refined further which is now different to the previous design mentioned in previouos updates.
• Screen designs have also been added in for unsupported wallets as well as confirmation screens when imported wallets are recognized.
• Confirmation screen that wallet has been created

[mouxdesign]

Yesterday's call was focused on the Storage screen states.

Storage settings screen

• Storage space: Try a design with a slider and see how the different variations look

Storage location:

• Default directory (this is different for every operating system, will be stored in a folder)
• Custom directory (This is a custom location that they save) Will we need to show a file picker window? That would be the file picker from your computer 1) Does this happen as soon as they click? The file picker will automatically pop up. (the devs will try to code it so that it automatically opens the file picker on the persons computer)

  Copy on the screen of Storage location screen:

• Main heading is: Storage location 2 sub-options below would then read Default Directory and Custom Directory

Look at the option to change this to Default and Custom

Storage amount screen

This screen is allowing the user to decide on how much data they want to store Choices:

• Reduce storage (uses 1GB) - Pruned (Reduce storage)
• Store all data (uses 440GB) - Full archival node (Store all data)

Added in some text to the design that with Store all data (they support the network) and with reduce storage (they are using it as a regular wallet)

[mouxdesign]

Main topic is preparing for the first release of V1

There is a plan to have a soft launch of V1, create awareness that this is happening and spread some awareness via various channels that we are looking for feedback on V1.

Main tasks to be done:

• Website

There might be some limitations wrt the model of android phones which V1 will run on. Maybe mention something about the android version that it can work on.

• Collect feedback

Airtable, Github, Twitter

• Testing will be done on

  1. Desktop windows
  2. Desktop mac
  3. Android
  4. Linux

• Media plan

If you are using the QT Gui you cannot replace it, it is very simple, it is not running a node. The mission of this app is to get people to run a full node.

Channels where we will do the announcements and ask for feedback:

1) Community call on November 30th we can do a soft release there through the community

2) Twitter:

3) Jarol long form blog post

December 9th - have the app out there

Coding to do:

• Block clock

[mouxdesign]

Some initial usability tests were done on V1.

Usability testing V1

[mouxdesign]

During the call with the devs we discussed the following:

Block clock

The block clock is further in development and the initial view for the clock has been developed as well as the pause screen.

Scroll view

This has now been fixed. The devs have come up with 2 different options. This is the automatic re-sizing that happens when the GUI is viewed on mobile.

Scroll View Github

Re-usable Settings

Re-usable settings Github

To do: Test 193 on android

Github

Proxy Settings Screen

The proxy settings screen would be for someone who wants to use these settings. However it might be an option to include this in V1.

Peer window

The original peer window contains alot of different information. This screen has now been simplified to contain just a few headings.

Christoph created a new view with buttons selection options, where the data can be sorted on Version, IP, Network and Ping

Might be an idea to add in sorting data by direction. Default sorting is by age of connection.

To do: Test out the peers window in the current version of the GUI.

[mouxdesign]

Design file cleanup

Main design file has been cleaned up.

Peers screens

Peers screens have also been added and some different screen variations has been created.

Block clock progress

• Block clock connecting to network this seems to be stuck atm and provides no clear feedback, it is currently showing that it is stuck on 0%
• Switch out logo
• Connecting circle
• Peer indicator moving pattern
• Peer indicator tool tip( Requires hit box change)
• Fade out/in when changing state
• Theme color switches (uses color variables)
• Estimated time number formatting
• Time estimation (confidence level showing an estimate)
• Minimum visual indicator of percentage display

5 dots is the connectivity

The color of the circles is showing how much of data has been downloaded (small dots at the bottom, if user clicks on that then it will show connectivity to peers, will show in red if there is a peer connection problem)

[Block Clock interactive states](https://stupefied-jones-dd209f.netlify.app/)]

User feedback/UX Research

Use both avenues to collect user feedback as it might hep to inform the design more (First have to wait for block clock to be integration to be further implemented)

• Usability tests
• Feedback form

Naming of the downloads:

[gui-qml/src/qml at main · bitcoin-core/gui-qml](https://github.com/bitcoin-core/gui-qml/tree/main/src/qml)

The devs can instead build a separate binary and rename that something a bit easier.

Options handling

Test option 3 and provide feedback

[mouxdesign]

21 December call notes:

During this call mainly the input fields were discussed as well as the blockclock.

• Testing guide: Jarol will start to put together a testing guide
• The Gui is frozen on testnet at the moment, the screen should indicate in someway that they are on testnet. People would need to know that they cannot get onto the mainnet.

Input fields:

• Automatic validation
• Error states for input fields to make UI designs
• The input fields are pre-populated

Good practices of Input fields:

• Error states
• Maximum input numbers (minimum numbers and max numbers)
• Feedback: The user needs to be informed when the info they have provided is incorrect
• Back-end code: Technically it should have a pre-cleanup that does not allow certain data to enter the system

Blockclock

• The clock will start at zero and as a block is mined then the clock will add on a part/section to the clock, a bar.
• The clock has a timer which is for updating the tip…the next rectangle point being shown on the clock

[Link](https://github.com/bitcoin-core/gui-qml/pull/148](https://github.com/bitcoin-core/gui-qml/pull/148) to download blockclock

[mouxdesign]

Tasks

• [ ] Peer screen: Make the selection criteria horizontally scrollable instead of 2 layers one under the other.

• [ ] Error states and behavior to the design system

Add to the design documentation, if you go into a setting screen and you tap a field and you type in text. If you enter 10 billion. If it goes beyond the max value value that we allow. does it show an error message?

Add these to the design system. The logic only exists in code, but adding in the logic about these error states into the design documentation as well

• [ ] Peer screen (copy)

Release planning

• [ ] 1. Come up with a proposal on how we can organize the release

• [x] Create a UX Research plan 3 circles of research

1. Initial audience (the initial circle ore of people who are initially active) (week 1)

2. 2nd circle (bitcoin design community)

3. 3rd larger community

• [x] Mo to test this version with a focus on error states:

[[DO NOT MERGE] Review current state by jarolrod · Pull Request #267 · bitcoin-core/gui-qml (github.com)](https://github.com/bitcoin-core/gui-qml/pull/267)

[mouxdesign]

To do:

• [ ] Ideate on application release notes

• [x] Open up a PR for the spelling of the file name to change it from insecure to unsecure.

• [ ] Graph toggle: There is a graph that collects network data and you want to see a graph, the app needs to have collected the application. An option is to only start capturing the data from when you start using the graph.

Toggle: By default do not always collect this history. (Start with 24 hours)

UX Research

A question was asked; what would the devs like to know once it's launched and what would we like t know from the design perspective?

Devs questions: What are they interested in knowing

• The developers are interested in technical issues such as crashing or freezing
• What feeling do they get when they run it? Is it too scary for them?
• Do they feel confident, I can run a full node and it doesn’t feel like jumping in the deep end?
• Mission: Did you run a node before? Will this make you likely to run a node in the future?

We want both groups of people: those who have run a node and those who have not run a node.

Design questions: What is interesting to learn more about from the design side of things?

• Do they find it useful?
• What device are they using?
• How do they manage the initial block download?
• Is the download process clear?
• How many people stumble on the download process?
• How does it fit into peoples lives
• Do they see themselves letting it run?
• Does the block clock make sense to them?
• Do they find the block clock interesting and useful

Will use the above to create a list of questions which will inform the research questions we as first time testers.

[mouxdesign]

UX Research: Milestone 1

Why?

• We wanted to test out milestone 1 with a smaller audience before testing it on a wider circle.
• We wanted to understand how the installation process was experienced by people
• We wanted to understand the Initial general impressions as well as impressions of the block clock

How? We hosted a call within the bitcoin design community. During this call one of the Bitcoin Core developers were present as well as the Christoph and Mo. Two people tested milestone 1 on Macs.

Link to call

Image shared

Post that was shared:

Tomorrow 13 April at 14:00 UTC we are going to be having a super fun UX Research call. We will be doing some live testing of Bitcoin Core App. It's going to be really hands on. We will onboard ourselves and walk through the interface together. The only prep before the call is to install it on your device of choice. :arrow_right: Check out the Github link where you'll find the latest download links. The team have been working away to bring this new design to the ecosystem and we are really keen to see how you the community experience it.

Where was the post shared?:

• Bitcoin Design Community Slack
• BDK Discord
• Fedimint Discord

What we discovered?

Installation process

• Installation process errors if there is a previously installed version of Bitcoin Core.
• Onboarding userflow is skipped if there was a previous version installed. -Mac user might need guidance on finding the signing path during the installation process

Syncing screen:

• When the app fails to sync we could provide feedback that the app is failing to sync

Block clock:

• When clicking the block clock it pauses, it may require feedback in the hover state to provide guidance that when clicked the clock pauses.

Settings screen:

• Users were a bit surprised to find the peers/network traffic in the settings screen.

Repository:

A repository has been created where all of the user feedback can live and be captured from milestone 1 Why?

• An open public place where all builders can look at the live raw feedback from UX research that was conducted.
• A hub where all UX research insights can live
• An insight into the main friction areas in the user flow

How? A public repository was created in Github. Link to repository

[mouxdesign]

Quick update after the last call. During the last call Christoph suggested a more structured way of working towards the future milestones.

What are our goals?

• Easier to maintain - new framework
• Android - billions more people can use it
• Design foundation & maintenance
• Better feedback loops
• In the conversation of self-custody

V1 Screens

In addition to the screens which are already designed, V2 will have additional screens added to the user flow. The additonal screens are highlighted with a star in the below diagram and figma document.

V2 QT Parity Screens

Version release plan

Link to document

[mouxdesign]

Christoph has further bucketed the design process into mini buckets:

V2 Parity Mini buckets:

• Navigation restructure
• Wallet import
• Wallet creation
• Activity and balance
• Receive
• Send
• Other

[mouxdesign]

Navigation explorations

The navigation is being built out atm.

Development needs atm:

• A Design top bar state for when app is built without wallet features.

App can also be built without:

• Port Mapping, NATPNP, UPNO - disappear of disable

Clickable prototype navigation

Jakub created a clickable prototype in Figma for the navigation explorations.

Widget design explorations

Christoph has done some widget design explorations here.

Project Management

Christoph has also created a repo for project management which covers milestones and a roadmap.

UX Research

We will be kicking off a research initiative which is in the process of being developed. The goals of the research initiative are to;

• Understand the personas using Bitcoin Core
• Understand the jobs that the interface needs to do to meet the needs of these personas
• Understand the parts of the UI that are being used more heavily than others
• Understand their struggles and hopes of people when using the GUI
• Understand what frustrates or makes people happy when using the GUI

So far a research plan has been created and together we are reaching consensus on what would be the best approach.

[mouxdesign]

Mapping UX Research done on Bitcoin Core

Mapped out the current research initiative as well as past research initiatives that have been done on core. The purpose of doing this was to:

• Visually see how all the past and present research initiatives are connected to each other.
• Pool all documents from current and previous research together in one place.
• Visually see the previous initiatives kicked off.
• Ideate on what is missing in the current research plan and improve it. Link to mapping By clicking on the individual squares they then open up links to files and documents associated with that topic.

  Visual of mapping

  

Research project plan

Github project board

[mouxdesign]

Dev update

• Working towards 1.1 polish milestone
• Reworking a few things for a better technical foundation moving forward

UX Research update

• Mo and Jakub gathered 20 interviews with Core users
• Also interested in talking to developers to learn about their needs
• Gui could have a dev mode
• Idea is interview developers and understand their needs so that there is a separate environment that is developed for them
• We now have a developer options screen, the console is also a developer option tool

Wallet import

Michael presenting import wallet flow work Figma file File figma: Wallet Import 1.3

Import wallet screen

• No seed or descriptor import option - file import is enough
• Multiple imports require multiple flow walkthroughs
• Descriptor import as a possible additional feature in the future
• Any extra permissions needed for picking files? Johnny and Jarol to discuss
• Add text input for single address or xpub
• Drag and drop on mobile?
• Is view-only an import function or a create wallet function?
• Wallets that are not supported: What are the criteria of a wallet that won’t be able to be imported?
• Wallet update: If a BDB state is imported then its state would need to be updated (Need to design Wallet update error screen)

View only and Multisig designs will be worked on later Since we are focused on this user flow right now, we’ll try to cover future feature additions as well and not just the first implementation.

[mouxdesign]

Wallet import flow update

(Figma)

• Designs for view only, multikey, single key
• What about fringe case if your node is not properly set up? Ask dev input
• Node only option, so also include an option to not import a wallet
• Add in info about the type of wallet that was imported, for example this is a ⅔ wallet.
• Add in the option to edit the wallet name (this would better be in settings, to keep this userflow as short as possible)

Node runner/Wallet user flows

• In the future having 2 separate paths for the node runner and then for the person who would use it for wallet functionality

Research update

(ChatGPT summary, raw transcript, Figjam)

• Research is still being worked on, it is being bucketed so that the main areas/insights are clear
• Goal would be to move the insights into a place where people can just search and all tags around a particular work will be pulled up
• To do: Present it in a report and present it in a searchable database

Top nav bar update

(Figma)

• Added in a state but did not have time to work on the wallet selector
• Will be merged into the main file

To open up milestone 4 wallet creation

[mouxdesign]

Dev updates

Build Artifacts

There has been a re-introduction of the build artifacts. . Designers can now grab the binaries and build the wallet to test it. Basically download and install the application. It automatically builds based on the current master file. This will allow many people to test on android.

Proxy & Data entry picker

Data directory picker is finished. Proxy, you can set the proxy on the proxy screen we might want to revisit that design. Currently in implementation Tor and regular proxy.

Design documentation

• The design documentation website is being maintained and updated by Christoph at present and would welcome contributions. The repo for this is here.
• Design documentation website
• @rabbitholiness has also contributed to the design documentation with these PR's.

Research

The UX research that was done was a great collaborative effort supported by many people. The next phase of the process is now bucketing the insights and presenting it. Updates on the process can be found here.

[mouxdesign]

Update on the research

Bitcoin Core App website

There is a write up being created about the past research efforts done on Bitcoin Core App. This will be added as an additional page to the website. It is currently a WIP but we can see that there's been some discovery research that has been done as well as qualitative and quantitative research done. This shows that there could be some more experimental research that could be done in terms of A/B testing current designs before they move to development.

Bitcoin research summary

Qualitative interviews were conducted with current and potential bitcoin core users. A report is now being created based on those interviews.

What's next?

• Finish research summary
• Decide on what research could be valuable to the project moving forward
• Make all past research efforts public and accessible on Github.

[mouxdesign]

UX research report

The following research report was created after doing a research sprint to try to understand the users of bitcoin core.

Link to affinity diagram where we sorted through the data and bucketed it.

[stackingsaunter]

Love it @mouxdesign !!!

Some feedback from me:

• Chart with wallets needs a scale. I suggest showing exact number (it's better for low amounts than %) and a total somewhere eg: (N=30)

• Love illustrating here, especially the plane part!!!

• When we gather screenshots from Sparrow we can add those parts that are in insights as screenshots there to better communicate what people like about it

• I think report feels a bit cut off at this moment. Maybe missing some straight recommendations for the design? Maybe this is something I can expand it with, as per our chat with @GBKS on Discord :)

• I'd also add directions of further research, eg:

  • bitcoin.conf
  • what are good practices with running bitcoin core? do they depend on a use case? should we encourage and propose good practices by proposing good defaults settings or different onboardings, etc (or this educational onboarding while it's syncing that someone from bitcoin discord mentioned

If you share your Figma file I can help with expanding it! I also wanted to look at the data and diagram one more time to see If I can find anything worthwhile to add (I feel bad I didn't take part in the analysis process too much)

Minor typo/copy:

• While there are many users of the current Qt Widgets GUI for Bitcoin Core. We currently do not understand this user base and have not connected with them to establish their needs.

  • This feels a bit unnatural when the sentence stars with "While" the second sentence should be a part of first one (although it's a bit long) eg:

  • While there are many users of the current Qt Widgets GUI for Bitcoin Core, we currently do not understand this user base and have not connected with them to establish their needs.

• Is the GUI called "Widgets"? Haven't had an idea about it

• Bitcoin Core users are fairly experienced in the bitcoin space, they have been using a wallet for many years now.

  • Should be either: have been using "the wallet" or "bitcoin wallets" for many years

• Last slide typo: "The second larget group"

[mouxdesign]

User needs: Bitcoin Core Node Runners

The Jobs to be done framework from the UX Research toolkit to speak with a bitcoin miner to understand if it would be useful for the project to speak with more miners.

During the interview a few questions were asked to identify the "jobs" that bitcoin core app would need to do to meet with the needs of miners.

Questions asked and the replies

• Q: When was the last time you opened bitcoin core with reference to mining? A: Last week

• Q: Why did you open it and what was the context? A: Testing V2 so we needed a bitcoin core node and get it up and running. For me to to mine SV2 you need a bitcoin core node.

• Q: When do you typically use bitcoin core? A: Usually just for mining. That's it.

• Q: What do you generally love about bitcoin core? A: It's what we as a bitcoin community agree on it's the best bitcoin out there. its the best code out there so I'm happy to use it.

• Q: What do you find frustrating? A: Nothing

• Q: What settings are the most relevant for you as miner? A:

• The bitcoin core has a template provider. So Stratum version 2 pool you're gonna need Bitcoin Core running locally on your comp because you'll need block template creation. Solo miners: So for a solo miner to build their own block template they will have to run their own node. Great for decentralization.

• Bitcoin core has a rule as a recommend set up which is it adds the transactions which has the highest fees, that's an important setting for us as miners.

Open ended conversation: Efficiency for pool mining: The miner creates a block not a pool for decentralization efforts. You'll need a node to do this. You don't want to lose efficiency with money.

When you are connected to a pool you send shares and if those shares are late or stale. Then you don't make any money. Bitcoin running on your system is a better way. Its much more efficient. There's miners in far away places. They are in the middle of the jungle. They really want to use the pool. But they will need to run their own node.

Solo mining vs pool mining; Pool mining you have a payment system, they aggregate all the miners and shoot that at bitcoin which increases the chances of finding a block.

Solo miners are those trying to reach the block on their own, we provide the infrastructure for them. People would rather connect to a solo pool.

It's two different pools. The solo mining is more of a community thing. The pool mining that's where money is made. That's the main emphasis.

Does it require a graphical interface? It will require a GUI, it will require a dashboard. Stratum V2 is already open source.

GUI connected to a pool. The software which is another service. Every miner has a different UI.

Summary User Needs: Bitcoin Core Node Runners (Preliminary)

Interview Findings:

Frequency of Usage:

Miners typically open Bitcoin Core for mining purposes, and the last usage was reported to be within the past week.

Use case:

The primary use of Bitcoin Core for miners is to support the mining process, solo and pool miners would need to run their own bitcoin core node.

Relevant Settings:

The most relevant settings for miners include

1. The ability to use Bitcoin Core as a template provider for mining pools
2. Recommended set up of adding transactions with the highest fees is of the most value

Efficiency Concerns:

Efficiency is essential for miners both with solo and pool mining to prevent losses in revenue.

Miners use a dashboard depending on which mining tool/pool they are connected to.

Conclusion:

Jobs to be done:

1. As a miner I want to use the block template creator so that I can provide the mining software I use with information. This info is used to construct a coinbase transaction.
2. As a miner I want to add transactions with the highest so that I can prevent loss in revenue.

getblocktemplate RPC An improved method is the Bitcoin Core “getblocktemplate” RPC. This provides the mining software with much more information: The information necessary to construct a coinbase transaction paying the pool or the solo miner's bitcoind wallet.

• More investigation into the use cases of miners would be interesting to hear from a larger group of people how they are using bitcoin core for mining. This initial investigation shows that this is an audience with a clear use case who are using bitcoin core on a weekly basis and might be in the more frequent group of users.
• More investigation into node runners in general

[mouxdesign]

Peer screens

Second PR for peers details - help test (one, two)

PR 388 is the most recent one and would be the best to test.

Miniscript explorations

Michael: Some explorations for Miniscript capabilities, based on the how it works page and the time-based recovery reference design.

Assume UTXOs prototype

• Gee will start working on this again very soon.
• Quick online test for different feature names via Discord poll
• Currently there are 4 prototypes: Design assumeUTXO user flow · Issue #79 · BitcoinDesign/Bitcoin-Core-App (github.com)

Error messages

• Make sure initial crashes communicate something useful so that users understand what happened as well as next steps they can take.
• Jakub’s crash was related to different prune settings in existing core vs new onboarding settings
• Do we need a migration document for people who have Bitcoin-QT installed?

[mouxdesign]

During the last call we discussed the project roadmap. Points discussed:

• MVP of the wallet features by Summer 2024 and a more solid version by Fall, and then potentially the application go live as part of Bitcoin Core (replacing the current GUI) by next April.

To dos:

• User documentation for onboarding current plus new existing users
• Create or expand on the FAQ's
• Discuss PRs to test in weekly calls

Prototyping and quality testing prior to the release in a staggered format would ensure that when it's released to the wider public the user exp is as smooth as possible.

There is also currently a case study that is in progress which describes the importance of this project as well as the process.

[mouxdesign]

Design Specs

A developer has requested that some guidance be created around the different interactive states. Specifically the wallet selector was requested.

Ideally then the interactive states in the various forms would also reflect in the prototype. Prototype: Bitcoin Core App Prototype (lively-kashata-cfde7e.netlify.app)

Planning

• Continue with designs for Activity as well as send flows and prepare prototypes for testing

User testing and UX Research roadmap

• A roadmap has been created to break the MVP into chunks to allow for user testing of the prototypes before they go into development.
• The user testing is being documented here

[mouxdesign]

Milestones progress as well as what's being worked on atm

First use and create wallet: 1.4

• Prototypes created and tested on new and existing users

Using the wallet: 1.5: Activity

• Designs being finalized

Using the wallet: 1.6: Receive

• Designs being worked on

[mouxdesign]

The send flow and receive flow are being worked on now in sync. The activity flow is mostly wrapped up however there are still some states that are being designed as we speak.

Send flow

The MVP scope for the send flow is being designed

Receive