Proposal (draft): A simple donations app.

[nochiel]

Feel free to point out where my thinking is wrong/erroneous. Also feel free to add suggestions to any section.

Rationale

• @ChristopherA mentioned that BTCPay is not ideal for the use-case of receiving Bitcoin donations in the simplest way possible.
• A user friendly opensource implementation of would have a lot of utility.

---

From the meeting on 2021-06-24

• Activists are not Bitcoin power users. Therefore, privacy enhancing tools have to be easy to use.
• On-chain is expensive. Ability to use Lightning⚡ would be a huge win.
  • An activist receiving donations on-chain would have to either open channels (not feasible and expensive for the non-technical) or submarine-swap to LN to facilitate their payments.
• Privacy is not the emphasis right now because governments in developing countries appear to have not yet invested in tracking Bitcoin usage.
• Ease of use is the priority.
• Ease of maintenance is important. If the service goes down it should ideally restart itself or be trivial to restart.
• Muun is working on a donation tool. HexaWallet, and http://sphinx.chat have donation implementations. However:
  • Hexa's is not opensource.
  • Does Sphinx [https://sphinx.chat/donate](donation widget) require you to have a node?

Goal

The simplest possible app that anyone (especially non-technical activists) can set-up within a few minutes and use to receive on-chain/lightning bitcoin donations.

What are the pain points?

• Difficulty of installation for a non-technical activist?
• Funds are sometimes lost? (what exactly happens here? Are there reported bugs we can reference/fix?)
• Accounting?
• What else?

What features are wanted?

• Ability to pay to an on-chain address without address reuse.
• Ability to pay to a Lighting ⚡ invoice using LNURL-pay.
• Copy http://hexawallet.io's donation account functionality?
• Privacy by default. In particular:
  • No address reuse.
  • Tor-gapped so that hosting can't be targeted.
  • Only the user, Alice, should be able to control the addresses generated by the app.
• Identify tradeoffs related to ensuring a donation app can be deployed quickly, securely and with a low cost of maintenance.
• We need specific case studies (user stories) of activists who might use this app. Human Rights Foundation (HRF) should be consulted so that we can talk to activists and organisations who can inform the direction of the design for their use-cases.

User story : Alice using app

• Alice is a women's rights activist who wants to receive Bitcoin ₿ donations non-custodially.
• Alice does not have a server. She is not a technical person or power user. She does not have capacity for complicated accounting.
• On app, she creates an account with her public key and a signature of her public key as input.
• She is directed to a donation widget that she can customise.
• She can then share a link to this widget or embed it in a blog.
• The widget gives Alice a real-time listed of her addresses and donations to those addresses.
• The widget allows her to export all her keys whenever she wants.

User story: Charlie using btcgive.app to donate to Alice.

• Charlie uses a link from Alice to go to her donation page.
• He can choose a currency and amount he'd like to donate.
• He is presented with a unique url (qr code) that contains both the address and the amount in sats to donate.
• He scans the qr with his wallet (or taps the url which opens his wallet) and makes a donation.
• The widget tells him that his donation has been successfully received.

TODO User story: BlockChainCommons Donor.

TODO User story: BlockChainCommons.

Implementation: Backend.

• How does Alice authenticate her account for creation/log-in?

  • Use LNURL-auth?

• How do we generate addresses? Is it possible/reasonable to:

  • Generate a HD wallet (BIP32) in-browser.
  • Tell the user to import the xprv into their wallet app?
    • Do we need the derivation path for their mobile wallet so we can generate a compatible wallet?
  • Generate a new child pub key for each new donation to use?

References

• https://docs.btcpayserver.org/UseCase/
• https://hexawallet.medium.com/bitcoin-donations-for-everyone-3f55d2a79b8
• https://blog.blockonomics.co/how-to-create-a-bitcoin-tip-jar-6e4815f73d0
• https://github.com/ElementsProject/nanotip
• https://github.com/ElementsProject/lightning-charge
• https://blog.voltage.cloud/how-voltage-works/
• https://www.opennode.com/

Milestones

• 2021-07-30 Simple donation app has been added to Torgap Demo.

  • 2021-07-15 - 25 Evaluate https://cypherpunkpay.org/ and any other apps/tools that are simple and suitable for receiving donations.

    • User stories: Identify the most common use cases and document how suitable the app is for these purposes.
      • Security modelling
        • Consult with Christopher to see specifically how this should be done. (ref. The Smart Custody Book, Part 1)
      • Code review: security.
      • Code review: how is it to modify the code or contribute changes upstream?
        • POC: Identify a feature BlockchainCommons needs and submit a small change upstream.
      • Evaluate install/setup process.
      • Evaluate maintenance process.
      • Evaluate backup and restore requirements/effectiveness.
        • Identify any potential problems with gap limits i.e. will the user always be able to retrieve their entire balance when restoring their wallet.
    • 2021-07-18 - 25 Prepare report for HRF.
    • 2021-07-20 - 25 If CypherPunkPay is suitable, scope work required to integrate it as a TorGap service.
    • 2021-07-25 - 08-13 Build a user-friendly installation tool (ref. Spectre Wallet, Umbrell.
      • Such a tool might serve as a front-end for the Bitcoin Standup Scripts allowing a user to install/update/maintain/monitor tools using a web app.

  • If CypherPunkPay is not suitable, fork or submit changes upstream?

  • 2021-07-20 - 25 Spec for backend functionality.

    • i.e. what is the minimal viable set of functionality that is needed.

  • 2021-07-25 - 27 App has hot-wallet from which addresses are generated.

  • Generate Lightning Invoices.

  • 2021-07-27 - 30 App can show unique donation address to each (unique?) visitor.

  • 2021-07-27 - 08-02 App can import user child xpub which app uses to generate addresses.

    • Figure out the best way to do this. Ref. HexaWallet.

  • 2021-08-02 Automated tests.

    • Identify and document (preferably in code) priorities for testing.

    ---

  • 2021-07-30 TorGap demo apt package for Tails OS.

  • Use TorGap Demo code https://github.com/BlockchainCommons/torgap-demo (led by @gorazdko), that makes available the users Tor donation service while it is running.

  • Privacy

    • Give a torgap server a private key to create the torgap onion address,
    • Give app an xpub or descriptor, and it does all the rest for collecting donations securely and without correlation.

  • Deployment

    • simple linode install script,
    • docker file.

[ChristopherA]

I'd really like to see a simple TailsOS persistent apt-get app leveraging our TorGap Demo code https://github.com/BlockchainCommons/torgap-demo (led by @gorazdko), that makes available the users Tor donation service while it is running. Like you give a torgap server a private key to create the torgap onion address, maybe you also give it an xpub or descriptor, and it does all the rest for collecting donations securely and without correlation?

[gorazdko]

Also, spruceID has integrated did:onion spruceid/didkit#125

Currently our torgap-demo site only shows examples of did-onion signed credentials by Blockchain Commons, but we should also give option to sign and verify those by the onion service.

[ChristopherA]

I'd also like to just see a super-simple donation tool added to the TorGap Demo and its simple linode install script, then maybe port it more portably for other VMs using docker.

-- Christopher Allen

[ghost]

Use LNURL-auth

Don't think this is required or maybe I am missing something. Can you please explain implementation of this for donations?

How do we generate addresses?

I think generating addresses using descriptors or XPUBs is easy and we can get privacy by using a new address for each request. Difficult part is managing a wallet with a huge gap limit.

Context: https://bitcoin.stackexchange.com/questions/106971/how-to-accept-donation-correctly

Best possible way right now is using Paynyms IMO or other wallets adopt BIP 47

[nochiel]

Difficult part is managing a wallet with a huge gap limit.

Adding this for future reference: https://blog.lopp.net/mind-the-bitcoin-address-gap/

Use LNURL-auth

Don't think this is required or maybe I am missing something. Can you please explain implementation of this for donations?

The idea is that if Alice is using a hosted service, she should have a secure way to log in without exposing emails or other contact information. But yes, it may not be necessary.

[ChristopherA]

Maybe the server app has a QuickConnect link to an Esplora server (Blockstream's or our own), where it can evaluate if a gap is becoming too large?

[nochiel]

@ChristopherA If CypherPunkPay is suitable, would the next step be integrating it as a TorGap service?

[nochiel]

@ChristopherA You mentioned that the patrons who use BTCPay have complaints about its usability. What specific complaints do they have?

[nochiel]

RE UX. @ChristopherA described one of the problems with BTCPay is that it doesn't provide price information to donors.

@icculp Is this configurable? If not maybe we can add SpotBit price information to the widget?

[ChristopherA]

@shannona also posted a number of other issues in the interns signal channel.

[nochiel]

@ChristopherA @namcios

CypherPunkPay looks promising. I think it can be modified for more ease of use for non-technical activists.

I think non-technical users need a hosted non-custodial service so they don't have to worry about installing anything or staring at a command line. The hosted service should be a Tor service.

---

In #45 (comment), you suggested a persistent Tails-OS app:

[t]hat makes available the users Tor donation service while it is running.

The usability tradeoff there is that the user is responsible for uptime.