Feature #12268

Make it so most Bitcoin donations arrive directly on RiseupLabs' Coinbase account

Added by intrigeri 2017-02-27 06:48:26 . Updated 2018-10-11 20:54:33 .

Status:
Resolved
Priority:
Elevated
Assignee:
Category:
Fundraising
Target version:
Tails_3.10.1
Start date:
2017-02-27
Due date:
% Done:

20%

Feature Branch:
web/12268-riseuplab-coinbase
Type of work:
Website
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

This will simplify things both for our accounting team and for our fiscal sponsor (RiseupLabs). Ideally we would point most visitors to RiseupLabs’ Coinbase address, and a small fraction of them to our own Bitcoin address, so that we keep some Bitcoin under our own control and can use them directly without converting to a fiat currency first.

Implementation options:

  • High-tech: a little bit of JavaScript (very similar to the code that picks a random mirror for downloads) should do the job.
    • pros: do the work once and forget it; the ratio can easily be adjusted dynamically
    • cons: some initial dev work (probably 20-40 SLOC, let’s say 2 hours of work including debugging + review & merge)
    • intrigeri could do it (or find someone else to do it) at some point in 2017, if we decide this is the best option
  • Low-tech: point to our own Bitcoin address most of the year, and point to RiseupLabs’ one during our yearly donation campaign.
    • pros: very little work
    • cons: we need to keep track of this forever, to avoid forgetting to switch to the other address when relevant
    • intrigeri is not excited at the idea of tracking all this, but volunteers anyway to create 3 sub-tickets of the 2017 donation campaign: switching to RiseupLabs’ address, switching back, and creating the same tickets for 2018

Subtasks

History

#1 Updated by intrigeri 2017-02-27 06:52:18

  • Status changed from Confirmed to In Progress
  • Assignee changed from intrigeri to sajolida
  • % Done changed from 0 to 10
  • QA Check set to Info Needed

Which one do you prefer? Is the effort to write, debug, review, merge, and maintain a tiny bit of trivial JS worth it in your opinion?

#2 Updated by intrigeri 2017-02-27 06:53:29

  • blocked by #12087 added

#3 Updated by intrigeri 2017-02-27 06:54:26

#4 Updated by anonym 2017-03-09 14:00:31

  • Target version changed from Tails_2.11 to Tails_2.12

#5 Updated by sajolida 2017-04-18 19:11:28

  • Target version changed from Tails_2.12 to Tails_3.0

#6 Updated by sajolida 2017-05-22 17:36:15

My next step would be to explain this to Ulrike and hopefully transfer this to her :)

#7 Updated by sajolida 2017-05-22 17:37:28

  • Target version changed from Tails_3.0 to Tails_3.1

I’ll see her next time around 3.1.

#8 Updated by sajolida 2017-09-05 09:52:47

  • Target version changed from Tails_3.1 to Tails_3.2

#9 Updated by sajolida 2017-09-05 09:56:16

  • Assignee deleted (sajolida)
  • Target version changed from Tails_3.2 to Tails_3.3
  • QA Check deleted (Info Needed)

I’ll let Ulrike handle this as part of this year’s campaign.

Ulrike: is our plan pretty much clear from this ticket?

#10 Updated by Anonymous 2017-10-05 13:15:38

The plan is clear, but I have to say I’m not sure about the usefulness of this.
During the donation campaign we should ideally point everybody to Riseup’s account in order to better track the money we received, no?

#11 Updated by intrigeri 2017-10-05 17:10:03

> The plan is clear,

Good :)

> but I have to say I’m not sure about the usefulness of this.

Any of the two proposed options will avoid repeating (most of) the boring work that I did last year to sell the BTC we’ve received during the donation campaign. I don’t wish anyone to do the same. Last year we had no choice so I did it, but this year we can anticipate and avoid putting ourselves in a painful situation, thanks to this ticket :)

Given the low-tech option described here is super cheap, its cost/benefit seems extremely favorable to me.

The cost/benefit of the high-tech option is less clear-cut. Its main benefit is: it allows us to keep quite some BTC without selling them, which we need for $reasons, and I don’t know if we receive enough during the rest of the year (outside of the donation campaign) to cover our needs. I could do the maths if needed; it may very well be that this (“high-tech”) option saves us quite some money down the road, and makes life simpler for a number of Tails people. I can elaborate (elsewhere) if needed :)

> During the donation campaign we should ideally point everybody to Riseup’s account in order to better track the money we received, no?

I think it doesn’t matter much: the money received by both bitcoin addresses can be retrieved from blockchain explorers, so the difference between “everything in the same place” vs. “cleverly split into two places” is one addition.

#12 Updated by intrigeri 2017-10-12 05:04:48

Ouch: https://bitcoin.org/en/alert/2017-10-09-segwit2x-safety. Now I think this doesn’t change anything here: even if BTC donations sent to RiseupLab’s Coinbase account are converted to whatever altcoin, we don’t care much as the goal is to have RiseupLabs sell them as soon as possible. But we should first check what RiseupLabs’ plans are given these news.

#13 Updated by Anonymous 2017-10-16 13:35:27

  • related to #14557 added

#14 Updated by Anonymous 2017-10-16 15:50:04

Sent email, waiting for reply.

#15 Updated by anonym 2017-11-15 11:30:51

  • Target version changed from Tails_3.3 to Tails_3.5

#16 Updated by anonym 2018-01-23 19:52:37

  • Target version changed from Tails_3.5 to Tails_3.6

#17 Updated by Anonymous 2018-03-12 13:49:28

#18 Updated by sajolida 2018-08-31 18:29:13

  • Assignee set to sajolida

Next step is to write a commit that switches to the RiseupLabs Coinbase address.

#19 Updated by sajolida 2018-09-18 22:23:36

  • Assignee changed from sajolida to intrigeri
  • QA Check set to Info Needed

Where can I find the address of the Coinbase account of RiseupLab?

#20 Updated by intrigeri 2018-09-19 07:39:26

  • Assignee changed from intrigeri to sajolida
  • QA Check deleted (Info Needed)

sajolida wrote:
> Where can I find the address of the Coinbase account of RiseupLab?

It might have changed so best is to ask them.

#21 Updated by sajolida 2018-09-20 16:05:18

> It might have changed so best is to ask them.

Done!

#22 Updated by sajolida 2018-09-22 01:27:35

  • Assignee changed from sajolida to intrigeri
  • QA Check set to Ready for QA
  • Feature Branch set to web/12268-riseuplab-coinbase

Here is a branch!

I reused some logic from lib/js/mirror-dispatcher.js.

To test it I didn’t find anything better than play with a bunch of weights…

#23 Updated by intrigeri 2018-09-28 09:14:59

  • Assignee changed from intrigeri to sajolida
  • % Done changed from 10 to 20
  • QA Check changed from Ready for QA to Info Needed

Fancy fancy! Code looks good but before I test, to questions:

  • #tails-bitcoind { display: none; } seems to be obsoleted by the new JS mechanism, no? I’d rather have one single place (donate.html) where we determine which Bitcoin address we advertise, this would be less confusing.
  • Regarding the weights, I propose:
    • until we’ve collected enough for our upcoming expected needs (at least 2018Q3 and 2018Q4), we give our own Bitcoin address weight=9 and RiseupLabs’ weight=1 (to at least confirm it works well before we send more BTC that way)
    • once we’ve collected enough for the next few months, we give our own Bitcoin address weight=1 and RiseupLabs’ weight=4, or similar (so that we keep collecting BTC we can use ourselves directly)

#24 Updated by sajolida 2018-10-09 20:20:03

> Fancy fancy!

:)

> * #tails-bitcoind { display: none; } seems to be obsoleted by the new JS mechanism, no? I’d rather have one single place (donate.html) where we determine which Bitcoin address we advertise, this would be less confusing.

I wrote this as a fallback mechanism in case there’s no JS.
Unfortunately, I didn’t find how to test it because Tor Browser seems to
still run JS from local files in the “Safest” security mode and I
couldn’t block JS locally using NoScript either.

I improved the code to be more explicit in 1da00636f4.

> until we’ve collected enough for our upcoming expected needs (at least 2018Q3 and 2018Q4), we give our own Bitcoin address weight=9 and RiseupLabs’ weight=1 (to at least confirm it works well before we send more BTC that way)

Done in 1da00636f4.

> once we’ve collected enough for the next few months, we give our own Bitcoin address weight=1 and RiseupLabs’ weight=4, or similar (so that we keep collecting BTC we can use ourselves directly)

Ok!

#25 Updated by sajolida 2018-10-09 20:22:03

  • Assignee changed from sajolida to intrigeri
  • QA Check changed from Info Needed to Ready for QA

#26 Updated by intrigeri 2018-10-10 14:11:59

  • Assignee changed from intrigeri to sajolida

>> * #tails-bitcoind { display: none; } seems to be obsoleted by the new JS mechanism, no? I’d rather have one single place (donate.html) where we determine which Bitcoin address we advertise, this would be less confusing.

> I wrote this as a fallback mechanism in case there’s no JS.

OK, makes sense!

> Unfortunately, I didn’t find how to test it because Tor Browser seems to still run JS from local files in the “Safest” security mode and I couldn’t block JS locally using NoScript either.

I’ve just tested it with Chromium.

> I improved the code to be more explicit in 1da00636f4.

… and with JS blocked, both Bitcoin addresses are displayed (which can be expected given what your commit does). I guess this is not an intended change in a commit who claims to merely “Add comment for”.

If I change this to:

.bitcoin-address {
display: none;
}

… then everything works as expected.

I see a weird rendering bug though: before the JS selects something, for a brief moment RiseupLab’s address is displayed, and it’s quickly replaced by the selected one. That’s visible when the JS selects our own address. No big deal but I thought it would be good to make you aware of it.

Feel free to merge with the CSS fix suggested above!

#27 Updated by sajolida 2018-10-11 15:42:32

  • Priority changed from Normal to Elevated

#28 Updated by sajolida 2018-10-11 20:52:08

>

> .bitcoin-address {
> display: none;
> }
>

Uhh, thanks for spotting that! It’s the kind of silly bugs that one
introduce when debugging stuff and forgetting to revert trials and errors.

> … then everything works as expected.

Yeap!

> I see a weird rendering bug though: before the JS selects something, for a brief moment RiseupLab’s address is displayed, and it’s quickly replaced by the selected one. That’s visible when the JS selects our own address. No big deal but I thought it would be good to make you aware of it.

It makes sense: the CSS display is faster and RiseupLabs is displayed by
default. Then the JS kicks in a replace it by our own address. I don’t
know how we could do better and support no-JS nicely. So, let’s ignore that.

> Feel free to merge with the CSS fix suggested above!

Merged, wooooo!

#29 Updated by sajolida 2018-10-11 20:54:33

  • Status changed from In Progress to Resolved
  • Assignee deleted (sajolida)
  • QA Check deleted (Ready for QA)