@Read.Cash
edited
Why read.cash doesn't work in Tor Browser **UPDATE2:** read.cash now works in Tor Browser! **UPDATE:** We have removed the dependency on api.coingecko.com (though, we still use their data). One step closer to supporting Tor browser. https://www.coingecko.com/en/api Some people using Tor Browser asked us the reasons why read.cash didn't work in Tor Browser. It's not our decision. We are using an external API rest.bitcoin.com for connectivity to the Bitcoin Cash network. https://rest.bitcoin.com/ To reach this service, your browser need to issue a so-called "CORS" request, basically: "This site (read.cash) wants to use your services, is it allowed?" Unfortunately, for some reason, it answers with `403 Forbidden` response to this Tor browser's request.
Due to this, our script fails to generate a wallet (*possibly*, a fixable bug), but anyway, even if we would fix it - we won't be able to show the balance or send the coins (these two are harder to fix). We'll do our best to fix what we can and update this article with the current state of things. Tor logo [CC BY 3.0 US] from https://www.torproject.org/static/images/tor-logo/
6 comments
"connectivity to the Bitcoin Cash network" just install the abc software on the server, and then you can spend from address, receive, view balances, simply from the commandline interface, which you can call from your portal engine. much more sane and secure than using a glorified snowflakeservice for offering something that you already have out of the box.
The problem is deeper than that. First of all, that means additional strain on our team to keep this service alive (we don't have any free time to do that), so **rest.bitcoin.com (even if you hate them for some reason) does us a major favor by doing that**. Second, we would need to install not only ABC node, we'll need to install a bunch of other stuff (bitcore proxy, rest.bitcoin.com service) and keep these alive too. Or alternatively, we'll have to rewrite the payment code from scratch. We don't have time for any of those things. Third, it's much easier to explain legally to anyone conducting a research on us that "we don't handle any payments", when we're using a 3rd party service, well known for being non-custodial. We are a very small team and we don't want to add any additional system administration strain to us. Anyway, at some point we'll probably migrate to BCHD, they have a pretty cool GRPC API, which does a bunch of things we need, but again, there's totally no time to do it now. For now, this article is a quick first step to explain what's happening to the users of Tor browser
okay. i dont hate them for any reason, but using a service like that, i think, was a strategic mistake, as such services are a burden - just as you can see in this practicular situation, it refuses to load for tor browsers. you do control the funds of users - which is worse, the portal also allows a third party service to control those funds, and you control the user funds through these services, as the portal engine itself is the object that issues these transactions. even as an user, i dont trust in exchanges or online services and wallets to begin with. i always withdraw my money from everywhere if it exceeds just 1 dollar or so. and i send it back when i want to send money to the people through a practicular service. i personally would not trust anything else than a full wallet on my own server... there could be a hack that affects them, there could be a malfunction and the whole api breaks, there could be a suprise api update, there could be a theft on the third party side. i understand that a migration like that needs time, but i think you should do it aniway. kill it with fire while you can.
Wait-wait-wait, you're mixing a bunch of stuff together. We DON'T control user funds at all. The private key is generated in browser, we don't have access to the private key or funds at any time, nor does rest.bitcoin.com control your funds. rest.bitcoin.com also doesn't have any access to your private key. Your browser does the signing. rest.bitcoin.com provides unspent transaction outputs (basically, an index to find them) and allows broadcasting of a signed transaction to the network. If you are to lose your seed phrase - nobody would be able to help you to recover the funds - not we, not bitcoin.com. It will be lost forever on the blockchain. So read.cash IS a full wallet, implemented in JavaScript, working right in your browser. rest.bitcoin.com only supplies raw data to it (what previous outputs could potentially be spent using your private key). ABC node vs rest.bitcoin.com doesn't change anything security-wise. > i understand that a migration like that needs time, but i think you should do it aniway. kill it with fire while you can. > as such services are a burden You aren't considering a burden of keeping services alive, working and upgraded. It's a burden MUCH HIGHER than somehow supporting Tor browser. It's not a one-time investment, it's an ongoing time and money investement that will keep costing us money FOREVER. So, thanks to rest.bitcoin.com for footing this bill for us.
hmm interesting. althrough the node can relay the transactions you compute in the browser. i am not sure but maybe there is a command that allows you to create unsigned transaction templates with the node for any address and input, and then you can sign it with the browser, send it back to the server, and issue the transaction.
The nodes don't expose HTTP/s protocols, your browser can't really talk to it - you need some special programs for that, like what rest.bitcoin.com does. It's open source, so you can install and support it along the node, but again, it's a strain on our sysadmins.