# Bitcoin Design / Payments / Patterns ## Why are these patterns important? 1. Monopolies control the user experieence 2. Need for Interoperability 3. Open Source is a far superior model, and is at the core of what we do as it provides a permissionless model for anyone to create bitcoin experiences. 4. Design/Feature Foundations 5. Bitcoin becomming the monopoly 6. Users and the community control its user epxeirnece 7. Guided by 8. How do we bring consistency of experiences to users across the globe? 9. Provides an upgrade path ```mermaid graph LR 1(onchain wallet) --> 2(privacy wallet) --> 3(lightning wallet) ``` ## Patterns ### Contacts - Address reuse, using output descriptors/xpubs would allow you to generate addresses on demand for someone (onchain) - Lightning, can store a friends nodeid / pub key which can be used to push payments to them, or even chat (see whatsats / sphinx.chat) - If the output descriptor for a contact is a xpriv then it means that you can sign transactions, maybe some apps would separate contacts by those you can sign and those you can only send (maybe then such contacts are named “Devices” or “Wallets”). - (onchain) Each contact is able to show a balance, so it would appear that a contact could be seen as a fake payment channel of sorts, as it would allow you to do automatic coin selection and swap funds back and forth without needing to do any manual coin selection - Lightning, a contact could also represent a real payment channel - A contact can have a url to another users Tor hidden service (server) which can allow both parties to message each other ### When to use? ### When not to use? #### Design Challenges - What happens if you need to send a payment to a contact which hasnt sent you any coins prior? Coinjoin some other coins before sending to them? Select form a coin join balance? Wallet can Suggest a more private means of payment instead of onchain (lightning)?