Replies: 3 comments 4 replies
-
|
from @johnsBeharry re: testing Contacts, Payment RequestsPhase 1: What is the minimal implementation that most bitcoin wallets can adopt? PHASE 1 MAINSTREAM CONCEPTUAL TESTING
PHASE 2 TECHNICAL TESTINGWith existing bitcoin users to see how it maps to their existing mental models and what limitation may arise for more advanced users. |
Beta Was this translation helpful? Give feedback.
-
|
Just wanted to say thanks for doing this! I'm not sure about the timing, but it's a very important work. |
Beta Was this translation helpful? Give feedback.
-
|
Good to see you here! I agree with the sentiment about timing because I think ultimately to scale properly we need payjoin & lightning packaged and presented. What were you thinking as far as timing? |
Beta Was this translation helpful? Give feedback.
-
|
By timing, I was thinking about the timing of Wasabi - or any other wallet that doesn't make Bitcoin UX its core mission - to adopt something that changes the UX. In my estimation, it's most efficient to wait out what strategy will gain wide acceptance and only work on it then, otherwise you'll just end up having something in the wallet that - due to lack of network effect - confuses users further. |
Beta Was this translation helpful? Give feedback.
-
|
I certainly understand that it is a concern. So I hope to address it in #116 (comment). The next steps would be to put these new (to bitcoin) ui abstractions to the test. Firstly, does the PeterMcCormack type user, or even no-coiner find the experience intuitive. Then find out if bitcoiners' who go out of their way to gain privacy would also be accepting. Hopefully even if it may not have the network effect with implementations, if there is a rigorous user testing and feedback process with dumb prototypes it would add more credibility. I will also try to get some wallets onboard who are open to more to adopting more experimental things. The ultimate proving factor would be having it in a wallet, and getting feedback from angry/happy users. |
Beta Was this translation helpful? Give feedback.
-
|
We got the treat of @barefoot-88 presenting his work on Coin Selection BitcoinDesign/Meta#76 now it's my turn to write down my notes. Thank you Ed :> LabelsThe most important question remains, as Daniel asked: "Why are we labeling?" Even with the clue card people don't get it yet. I was just on the phone with a user this week as they tried to make a send. They were stuck and worried about what to do here. Saying "for example if you were receiving from me, you'd write 'Dan'" clarified it. Putting that language there may solve it. We can use labels to quantify tradeoffs as discussed in that section Quantifying TradeoffsPRIVACY vs COST vs SPEEDChristoph made a great point that we need to quantify the tradeoffs to make choices. Contact labels allow us to figure out who has a view of each transaction. Chain analysis calculates a "risk" score based on the source of funds. That's what this is and exactly how we can quantify privacy. To get technical, we can analyze each contact's points of view into our wallet. We calculate the point of view of each contact the transaction with x% certainty or ambiguity, and can feed that to a model to automate transaction building. I'm confident in practice there is a setting for auto-selection that satisfies 99% of usage cases. OutputsAnother clear problem was communicating the idea of a transaction output which is the thing we label. An output is a discrete amount of value with a stamp (txID+index+script) that has all the information we need to verify it's authenticity. That's sounds like a bag we can weigh, bullion, bar, billet, or ingot to me. That discussion helped me realize how bad "coin" is in the term "coin selection" because we associate coins with standard denominations. Why do people need to understand outputs? Those are the things they label. If we assume users can make better decisions than computers (even if only for now) at selecting outputs to fund transactions, then we need to convey what they are. Ideally we give heuristics for making better decisions, too. I think they can, and the most basic example is spending whole outputs to maintain privacy and save on fees. They are certainly something we could visualize and animate. We could show balance as a pile of different sized bags. Could even extend to lightning as a change-of-state to a plasma that floats in clouds or fills some valved pipes people set up as a channel. I think visualizations have a huge place in communicating what is going on, and can extend to the transaction builder that you proposed ~~~~~ I feel a bit premature and excited re: visualization. I don't think we can come up with a solution until we more fully understand the problem. |
Beta Was this translation helpful? Give feedback.
-
|
This is an interesting analysis of labels with regards to the importance of outputs. If a user sees an input field asking them "Label this transaction" for a send flow, they might assume it's something to remind them at a later date of what those funds left their wallet for. However, this sounds to me as if what they're actually doing is labelling the change output of the transaction that returns back to their wallet (at a new address).
As for visualisations of bags, I assume what we're talking about here are clusters of outputs? Agreed regarding using visualisations as a means to communicate whats going on, this is going to be super important and presents a nice design challenge for the community. Look forward to speaking more soon. |
Beta Was this translation helpful? Give feedback.
-
Our focus has been on improving bitcoin's usability. A big sticking point is that labels and addresses are easily misused. In addition, labeling is "dumb" right now in that the software doesn't yet do anything to suggest grouping of labeled coins. We have seen hidden service payments via bip78 provide an alternative to addresses that can even negotiate more complicated transfers than payjoin which it already does. More recently we've seen a big stab taken at improving experience by abstracting these with the more familiar idea of "contacts. It's time to get these ideas into one place and woodshed them.
Addresses
Labels
BIP 78
@Kukks has done huge research here already thanks to his deep involvement with BTCPay
Contacts UI
@johnsBeharry has been convincing me all of these problems can be abstracted into a the familiar "contact" we've come to understand since the time of the rolodex with physical addresses, phone numbers, social handles and more identifiers associated with entities. Better have him explain the concept
in this wonderful demo video
Output Descriptors
They're a language that describes a collection of scripts. These could be shared or associated with a contact for future payments to prevent address reuse. If we can somehow handle tracking these at contacts instead of addresses we may not need to share a new address every time we want to send a payment on chain.
Off-chain Data
funds recovery and revocation are issues that remain to be solved. "suppose the receiver loses the funds, but you send them money regularly or something, that could be going down the drain or something".
Change Forwarding?
@nothingmuch has dreampt up some guidance on change forwarding giving a descriptor to a separate wallet tot slowly move funds from non-private to private focused wallet. This is a little of a stretch for this discussion, but because he's helped so much exploring the capabilities of output descriptors and off-chain data it deserves a mention too.
Recovery
Right now the best way to back up Labels for Chaincase users is to manually back up their Wallet.json file. For other wallets, this data is stored "in the cloud" unencrypted. I think we can do better with a simple remote keystore accessible with a key derived from the wallet secret.
Beta Was this translation helpful? Give feedback.
All reactions