BitPal July update
Hey everyone. This is the July update for BitPal, the friendly self-hosted cryptocurrency payment processor. https://bitpal.dev
Things I've been working on this month
Finalized the REST and websocket API.
Converted the demo to communicate over the API instead of via the old Elixir library. The plan is to extract the code into a library, for easy inclusion in any Elixir project. https://github.com/bitpal/bitpal_demo/pull/4
Started working on the documentation. I have big plans here, but I haven't anything good to show just yet. https://github.com/bitpal/bitpal/pull/92 https://github.com/bitpal/bitpal/issues/97
A bunch of smaller refactoring, fixes and polish.
This marks the end of the Flipstarter push
We're now past the hours that we commited to in the Flipstarter. While I overestimated the amount of work this project would require, we've come a long way and we have a solid base to continue from. There are some rough edges, and the project is sorely missing documentation, but those can easily be fixed going forward. https://read.cash/@jonas_h/the-bitpal-flipstarter-has-been-funded-57c7239f
Things that needs to be done
These are the big things that needs to be prioritized:
Documentation!
A web interface. While it's possible to setup the server via the commandline and examine invoices via the API, that's really not user-friendly. So we need a web interface that will help you configure the server (xpub, exchange rates, number of confirmations or 0-conf etc) and that lets you view invoices and the server status in an easy manner.
After that it might be time for a first alpha release and to get other people to test it and see what's missing and what needs improvements.
What happens now?
First, I need to take a vacation.
Then, I will continue working on BitPal when I have spare time during the Autumn. I'd like to be able to focus on this project more, but I don't know how best to do that yet.
If you want to keep up-to-date with BitPal, the GitHub repo is still the best way to do so. See the issues and pull requests to get some sort of overview of how the project is coming along. I've been planning to make these updates available on the BitPal homepage, but I haven't gotten to creating a landing page yet. https://github.com/bitpal/bitpal https://github.com/bitpal/bitpal/issues https://github.com/bitpal/bitpal/pulls?q=is%3Apr https://bitpal.dev
BitPal June update
Hey! Here's a slightly delayed update for the last month of development of BitPal.
Things we've worked on:
Firstly we reworked our GitHub repositories (again). We started with a general Elixir library, which would allow you to program against BitPal, but only from Elixir. This wasn't too beneficial, and it complicated the development while making it harder to follow the project, so now there's a single main repo for the BitPal server. See the issues and pull requests to get some sort of overview of how the project is coming along. https://github.com/bitpal https://github.com/bitpal/bitpal https://github.com/bitpal/bitpal/issues https://github.com/bitpal/bitpal/pulls?q=is%3Apr
I just merged a larger pull request with a basic API for the server. Apart from a basic REST API it also contains a websocket (or longpoll) API, where you'll get instant notification of invoice updates. For example an invoice tracks the status of a transaction when it's first seen, verified (a short timeout to check for any fast double spend attempts) and confirmed. (The support for websockets in Phoenix is great, and gives us a fast and modern API.) https://github.com/bitpal/bitpal/pull/77 https://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections
As usual, a bunch of low-level improvements and testing. Most of these concerns have been addressed and we have a pretty solid test suite covering everything from parsing Flowee's messages to endpoint API requests.
Going forward I plan to focus on:
Fill out the API so we can write usable clients. I've rewritten the demo to use the API already, but there are some nice things that are missing (such as proper error messages and authentication). https://github.com/bitpal/bitpal_demo/pull/4
Make as many things as possible configurable (such as number of confirmations, xpub etc). Ideally this should be possible via a web interface, but as a start we'll retrieve it from a text based config file.
Documentation.
And some words about the Flipstarter funding. There's about a month left until our promised hours run out, and after that I have other work commitments I need to focus on. I'll still work on this project after that, but the pace will be slower come August.
BitPal May update
Hey there! Another short status update on BitPal.
These are the main things we worked on:
Multiple address and transaction tracking was merged. (But not live on our demo site just yet.) https://github.com/bitpal/bitpal/pull/43
Large refactoring of our internal invoice handling in the same merge request. The focus can now shift towards more features, although some things will still change in the core.
We split out the demo code to a separate repo and setup a repo for the server, which will be the thing you'll actually run. Most of the work will still be in the BitPal elixir library for the foreseeable future. https://github.com/bitpal/bitpal_demo https://github.com/bitpal/bitpal_server
I've also thinking of how best to design our REST API. We could copy an existing API (like how BTCPayServer copied BitPay) or we could go our own way completely.
The benefit of copying an existing API is that it would be easier to adapt various integrations (just copy and do minor modifications). The drawback is that they might not do exactly what we want, and they might come with lots of technical debt. For instance, BitPay doesn't expose overpaying or underpaying in their API, as they handle that centrally.
Going our own way is enticing, as it's much quicker to get everything going. But lose out on the ease of integration and we risk designing a bad API (it's easy to make something crappy).
So I think the way forward is to follow Stripe's API where it makes sense (as it seems to be the most well regarded payment API out there), and in the future we can adding adapters/stubs to make it easier to reuse existing Stripe integrations. (Of course, it's also possible to add a BitPay compatible layer on top if we want to.)
Things are moving forward. If you want to follow the development, GitHub is the way to go. https://github.com/bitpal
BitPal April update
Hey! Here's a short progress update on our progress on BitPal and the Flipstarter. https://flipstarter.bitpal.dev/
Focus has been on internal improvements, such as:
The elixir library has been separated into it's own GitHub repo, and that's where we track most of the issues we're working on. In the future we'll add more repos under the bitpal organization. https://github.com/bitpal/bitpal https://github.com/bitpal/bitpal/issues
Generate an unique address per invoice. The algorithm is done, but it's not live yet. https://github.com/bitpal/bitpal/issues/9
Exchange rate plugin system, makes it very easy to fetch price data from exchanges or other sources.
A bunch more refactoring, code cleanup, small improvements and more tests.
As a bonus, I've spent some hours outside of the Flipstarter hours to look at Monero support, and it should be easy to finish that.
There's still some loose ends to tie up here, and after that we'll look at the api and server we need to make BitPal actually useful.
If you want to follow the development, GitHub is the best way to do that, and I'll try to give regular updates like this. https://github.com/bitpal
BitPal March update
Hey everyone! Here's a short progress update on BitPal and the successful Flipstarter. https://flipstarter.bitpal.dev/
I started putting in some hours in the middle of March and have been focusing on:
Tracking issues on GitHub to get a high-level overview of where the project is at and where it's headed. This is partly for my sake but also for anyone wanting to follow along. https://github.com/bitpal/bitpal_umbrella/issues
Pluggable backends. This ties in to the "Plugins & adapters" goal of the Flipstarter, where it should be easy to add support for other BCH nodes, SPV or other cryptos. This also allows us to swap out the backend during testing (so we can use mock testing). https://devopedia.org/mock-testing
Refactoring. This means cleaning up the code, making it understandable, testable and debuggable. I've also tried to ensure that we properly setup supervision trees, which is very important for the robustness in Erlang/Elixir. https://learnyousomeerlang.com/supervisors
Testing. During the hackathon we almost ignored tests, but it's super important to have a good test suite that gives confidence that everything works as it should.
These aren't quite at the level I'm satisfied with yet, and they'll continue to be the focus going forward.
I haven't put a ton of time on the project yet, and I expect speed to pick up more during April/May. I'll try to be as transparent as possible and you can expect an update like this roughly once a month, and you can always follow the development on GitHub. https://github.com/bitpal
The BitPal Flipstarter has been funded!
Thanks to the amazing supporters in the Bitcoin Cash community the BitPal Flipstarter has been successfully funded! https://flipstarter.bitpal.dev/
It was funded in less than a week and we’ve received a lot of encouragement and positive sentiment, so it seems people liked the project idea. Now it’s up to us to deliver on the trust we’ve received.
The project has grown
As mentioned in the update in the short time since we wrote the Flipstarter the Bitcoin Cash price has gone up quite a bit, so we’ve committed to spend more time than originally specified. https://read.cash/@jonas_h/bitpal-flipstarter-updates-and-faq-55987ab5
The BCH price was originally $440 and it’s currently $570, which is an increase of 30%. Therefore we’ll also increase the amount of hours we’ll commit with 30%, from 280 to 365 hours.
What happens next?
The initial plan was to slowly get the project rolling with 5–10 hours/week late Mars, and then ramp up to +20 hours/week in May until the project is done. We’ll still try to hold this schedule, but with the extra amount of hours we might not finish before summer so the project will continue after the summer.
I’ll try to keep you updated on our progress via reddit and read.cash, and we’ll develop BitPal in the open via GitHub. https://github.com/bitpal
BitPal Flipstarter updates and FAQ
We’ve gotten some good questions on the Flipstarter for BitPal and I figured it’s a good idea to collect them in a single place. I would’ve wanted to add it as an update to the Flipstarter itself, but this will have to do. https://www.reddit.com/r/Bitcoincash/comments/lip829/announcing_the_bitpal_flipstarter_a_selfhosted/ https://www.reddit.com/r/btc/comments/lip7z8/announcing_the_bitpal_flipstarter_a_selfhosted/ https://flipstarter.bitpal.dev/
BCH’s increase in price
With a price rise of +60% the last week it’s been a good time to be a BCH holder, but it does put our Flipstarter in a bit of a weird position. We set our price to 0.3 BCH/hour, but with the rise in price that’s now too much.
Therefore to compensate we’ll put in more hours. As the volatility may continue it’s difficult to commit to the exact amount right now, but we’ll be able to decide on something if/when the Flipstarter completes.
We set our price at 0.3 BCH when it was at $440 (to $130/hour) and BCH is currently around $700, which is a 1.6x increase. So if this price holds then I expect us to commit to 280*1.6 = 448 hours (or 450 because it’s round and pretty).
This does mean that we won’t finish in July like we first estimated, and we’ll continue the work in the Autumn (after our Summer vacation).
With more time we might also do more things. In addition to the items in the Flipstarter we’ll prioritizing these things: https://flipstarter.bitpal.dev/
Integrations & guides
The next big thing after having a working API is to make it easy to integrate into your website, no matter what it’s created in. Therefore we should prioritize integrations and guides for popular languages (PHP/Ruby/Python/JavaScript/…), frameworks (Laravel/Rails/Django/Node/…) and e-commerce stores (WooCommerce/Shopify/OpenCart/…). We won’t be able to do them all, but we can start working towards that goal.
An admin interface
A place to to view the server status and to list and manage payments. This way the server can store the payments, without requiring the client to implement the payment tracking themselves.
SPV backend
There is no one-size fits all when it comes to requirements for a payment processor. Some (most?) will be comfortable with relying on a third-party REST api, some want to go all the way to a full node and others wants to sit in the middle. By providing an SPV configuration we can provide an alternative for everyone and it would be easy to transition between them.
Again we might not be able to do everything we’ve outlined here and in the Flipstarter, but this is what we’ll be working on and we should be able to make some very good progress.
Comparison to other alternatives
There are of course alternatives to BitPal, so why should be build on BitPal instead of using or improving existing solutions?
BTCPayServer
The big competitor is BTCPayServer that’s a self-hosted solution that verifies payments using your own full node. Unfortunately they’re extremely anti-BCH and won’t support BCH. https://btcpayserver.org/ https://mobile.twitter.com/BtcpayServer/status/963686582862655488 https://mobile.twitter.com/BtcpayServer/status/1031388746531332096
**Benefits of forking BTCPayServer**
What we could do is fork BTCPayServer, or create a Bitcoin Cash plugin that users can manually install. There are some nice benefits to this:
Can leverage the many features of BTCPayServer
Can easily convert existing BTCPayServer users to BCH
Would be cheaper and faster to fork it than to create something from scratch
**Benefits of continuing with BitPal**
Despite the advantages, there are benefits to keep working on BitPal:
We can design the system with reliability as the core focus
By keeping reliability in mind from the very start and by leveraging the battle-tested tools of Elixir/Erlang I think we can reach a level of fault-tolerance that’s unmatched by other solutions. https://dockyard.com/blog/2018/07/18/all-for-reliability-reflections-on-the-erlang-thesis
We can expect no support from BTCPayServer
This means we would have to rebuild our knowledge of the system from scratch without help, offsetting some of the benefit from forking it.
Official BCH support
While it’s possible to maintain a BTCPayServer fork or plugin due to the BCH hostility it’ll always be a second-class citizen. With BitPal BCH support will be front and center.
I’m not impressed by the code quality of BTCPayServer
This is of course subjective and you may disagree.
Competition is good
Multiple options forces everyone to improve, benefiting everyone in the crypto community.
This trade-off of funding BitPal vs a BTCPayServer plugin/fork is in my mind the biggest reason to withhold supporting our Flipstarter, so consider the pros and cons before you pledge.
(Of course I personally think BitPal is the way to go, otherwise why bother?)
BitcartCC
BitcartCC is a solution that uses SPV security to accept payments in Bitcoin Cash and some other cryptos. While SPV security is very good, BitPal allows you to verify payments using your own full node giving you increased privacy and security. https://bitcartcc.com/
Other solutions
There are many other solutions such as BitPay, PayButton, CryptoWoo, prompt.cash, NOWPayments, rocketr, etc. The difference is that they all have some sort of third-party reliance, which creates some problems:
They’re not self-hosted, meaning we have to trust a third-party
Not open-source
There are fees
There’s KYC
They might only support a single cryptocurrency
Even if the only crypto you personally support is BCH, merchants will vastly prefer a solution that supports multiple cryptos.
(They don’t all have all of the problems, I bundled them together to save time. The only real competitor I could find is BTCPayServer.)
How to make BitPal sustainable?
To make BitPal truly great, long-term maintenance would be needed and the project should therefore be sustainable (have enough funding to pay for maintenance and new development). Here are some options we’ve considered:
Donation driven
Flipstarter is great and some projects are wholly donation driven (like BTCPayServer).
Pay for our hosted server
Like many other solutions we could extract a fee if you want to use our hosted solution, and if you want to avoid the fee you can host it yourself.
I’m not a big fan of requiring a fee, as it goes against the “zero fees” vision of BitPal, but it *might* be easier to digest if you pay for extra features of some sort.
Fund the development via premium support (aka consulting)
Create a “shifting plugin” that extracts a fee
Meaning we could setup a third-party that exchanges cryptos for you, so you can for instance accept BTC/LTC/XMR/BCH/DGC but they’re all converted to BCH. This could even exchange fiat for you, making it a complete replacement for BitPay. (And of course it should be optional.)
But this is a much larger commitment and it’s not something we’re interested to pursue at this moment.
We don’t have a good answer at this moment and our plan is to hopefully flipstart BitPal with donations, and then see where we’re at and reassess.
Will BitPal support other cryptos?
Yes the vision is to support most/all cryptos that people want to pay with. Monero is next in line after Bitcoin Cash, and after that we’ll see.
While we’ll use Flipstarter funds to setup the core plugin architecture, we won’t use any funds to create a plugin for other cryptos. That will have to be done outside the Flipstarter commitment.
What if the Flipstarter fails?
There’s always a possibility that the Flipstarter fails, and what would happen to BitPal then?
I’ll probably work on BitPal enough to use it to sell the digital version of my book (which was the original motivation for starting this project) and then leave it at that. Even though it’s a good project, I simply don’t have enough time to be able to push it forward without being able to take a break from other commitments. https://whycryptocurrencies.com/
As BitPal is open source it’s always possible for someone else to continue it forward.
The BitPal vision
The Coinparty hackathon is over and our submission BitPal was well received, getting a bunch of votes by the community and even earning an honorable mention in the allstars section (sadly missing out on the $8,000 first price!) https://coinparty.org/ https://devpost.com/software/bitpal
Even though we did make something during the hackathon, that was only the first shaky steps towards what I think a cryptocurrency payment processor should be. And that’s what I want to describe with this post. https://bitpal.dev/
You should be in control
The big thing with cryptocurrencies is that *you* should be in full control over your payments and your money. Therefore a payment processor should have these properties:
Open-source
No fees
No KYC/AML
Full control over payment verifications
Non-custodial (private keys never touch the server)
Configurable
It’s also important that a payment processor can be configured to suit your needs.
When accepting a cryptocurrency payment you as the merchant can choose how much security you want to have before the payment should be accepted. For smaller payments you might be fine with 0-conf, for larger you might want to wait for one confirmation and for very large payments you might want to wait for 6 or more confirmations.
There are also different privacy and security levels for how you verify payments:
**Depend on a third-party API**
This might be fine if you process smaller payments and use a relatively trusted source.
**Rely on SPV security**
With SPV security to cheat you the cheater must produce valid proof-of-work, which is a very expensive ordeal.
**Use a full node to verify everything yourself**
Using a full node gives you the maximum level of privacy and security possible.
I think a payment processor should be able to provide all the different levels.
The processor could provide a public REST api that you could connect to. When you outgrow it you can easily spin up a server of your own and use that access point instead. You could start with SPV security in order to save on server resources and then upgrade to a full node when you feel the need to.
Reliable
Reliability and high uptime should be a core focus for a payment processor as downtime means payments don’t go through and you’ll lose customers (and money!).
This is an area that Erlang (and therefore Elixir) shines in. Some of the features that Erlang/OTP provides are: https://stackoverflow.com/questions/8426897/erlangs-99-9999999-nine-nines-reliability
**Hot code reloading**
You can upgrade a system without stopping anything, vastly cutting down the “down for maintenance” interruptions.
**Compartmentalization**
Erlang processes (lightweight threads) are isolated from each other and if one part of the system crashes, the rest lives on. Combined with message passing that allows for reliable concurrency and the OTP framework this gives Erlang a very solid base for creating fault-tolerant systems.
**Clustering**
Message passing between processes works transparently between separate servers, as if they were all running on the same machine. This makes it very easy to split up the service into multiple servers. For example you could run your full node on one server and the payment processor on another or you could mirror the servers and use one as a backup if the other goes down or you could run several different full node clients (like Flowee and BCHD) and combine their results.
Extendible
I think it should be easy to extend the payment processor with the functionality you need.
With a plugin-focused architecture it should support different cryptocurrencies. The popular ones should be supported by default, and it should be easy to add new ones. This also includes adding things like SLP-tokens, shifting services or maybe Detoken for volatility control.
Note that there’s a big risk with officially supporting plugins that rely on third-parties, as they can suddenly add KYC requirements or decide to exit-scam, but it should be possible for third-parties to create them.
Advanced payment protocols
A payment isn’t always just sending coins from A to B, as they can include more complex interactions. For instance a Flipstarter pledge or recurring payments.
If it’s something that a merchant would like to accept, then I think a payment processor should support it.
Documentation & integrations
What sets a software library or service apart isn’t always it’s features, but how well documented it is and how easy it is to get started.
That’s why it’s absolutely essential that a cryptocurrency payment processor is well documented and is easy to start with—no matter the language or framework or server setup you use. You shouldn’t have to be an expert programmer to infer the right command-line arguments to use or have an intimate understanding of cryptocurrencies to get started. It should be approachable and simple.
Examples of how to get started in popular languages (PHP/Ruby/Python/JavaScript/…), frameworks (Laravel/Rails/Django/Node/…) and e-commerce stores (WooCommerce/Shopify/OpenCart/…) is essential and it should be as easy as including some libs or copy-pasting a small code snippet.
How do we get there?
The problem with this model is there’s no built-in funding mechanism. It would for instance be easy to add a 1% fee for every purchase (which is what a lot of the existing cryptocurrency processors do), but we should be able to make something better.
So maybe Flipstarter would be the way forward? Do you think this is valuable enough for you to support a BitPal Flipstarter? I’d love your feedback here, even if you think it’s a stupid idea and that we’re fine with alternatives such as BitcartCC or BTCPayServer. https://bitcartcc.com/ https://btcpayserver.org/
Why Cryptocurrencies?: Cryptocurrencies are antifragile
It’s common to separate things into two categories: those that are fragile and those that are robust. Regular glass is for example fragile as it breaks easily, often by accident, and bullet-proof glass is robust as it can withstand a significant amount of force before it breaks.
But there’s a third category that we often don’t think about. It’s called antifragile and it goes beyond robustness as it grows even stronger when stressed. I think the phrase “what doesn’t kill you makes you stronger” explains antifragility quite well.
In this chapter I'll motivate why I think cryptocurrencies are antifragile, and will only grow stronger as time goes on. Even in face of serious issues like: https://whycryptocurrencies.com/antifragile.html
If developers disagree on the way forward, and want to move the project in two incompatible directions.
If the reference client abandons core values, and want to steal miner rewards for themselves.
If marketplaces starts freezing your assets or if governments declare cryptocurrencies illegal.
If a cryptocurrency experiences 51% attacks.
Do I think cryptocurrencies will come out stronger in the end. Please read the chapter if you want to see my reasoning. https://whycryptocurrencies.com/antifragile.html
This chapter is part of my book 'Why Cryptocurrencies?', which is completely free to read online. If you want an ebook or a printed book, rest assured that I'm working on it... https://whycryptocurrencies.com/
An Elixir based payment processor for the Coinparty 2020 hackathon
Bitcoin Unlimited is hosting a Bitcoin Cash hackathon this December and it seemed like a good opportunity for me to explore how to program against Bitcoin Cash, and it gives me an excuse to build something real with Phoenix and Elixir. (While an event like this might help combat my procrastination, I should really work on finishing my book, so this in itself is also procrastination.) https://coinparty.org/ https://www.phoenixframework.org/
Therefore I’d like to integrate BCH payments into a simple website made with the Phoenix Framework, with the possibility of extending it to a generalized cryptocurrency payment processor (if it’s sufficiently useful). https://www.phoenixframework.org/
I’m also doing it myself because after entertaining my two kids, my girlfriend and spending time at work there’s not that much time for the hackathon, so I figured it’s best if I focus on something small and do it in my own pace.
My use-case
Ever since I started working on my book about cryptocurrencies I’ve been planning to sell the digital version on my site, payable with cryptocurrencies of course. https://whycryptocurrencies.com/
To make it as accessible as possible I want to support different cryptocurrencies and sell it in a pay-what-you-want scheme (but more than 0). As you can send really small amounts of money this would allow people in poor countries to buy the e-book, people who otherwise would’ve been priced out.
It would also act as a good introduction for people who have received small amounts of cryptocurrency tips. For instance it’s common on Reddit to tip < $1 of Bitcon Cash via chaintip, but it’s harder to find anything useful to do with that amount of money. https://www.chaintip.org/
When looking for a payment processor or a library to help me out, I have a few requirements:
Easily integrated to a site made with the Phoenix Framework https://www.phoenixframework.org/
Supports multiple cryptocurrencies
Open-source
Free
No minimum payment limit
No KYC/AML
Receive payments directly to my own crypto wallet(s)
I should be able to verify payments via full nodes on my own hardware
If you handle higher value payments or have high privacy requirements this is a must, but for my simple use-case I don’t really have to. I just *want to*.
I couldn’t find an existing solution that fits all my needs
Turns out this is surprisingly hard. While it’s possible my DuckDuckGo and Google skills have failed me, I couldn’t find anything that fit my needs and they all require me to compromise on something. For instance:
BitPay https://bitpay.com/
If I was a normal merchant I might prefer to get my payments in fiat, but it doesn’t work with my requirements at all.
PayButton https://paybutton.org/
Makes it very easy to accept Bitcoin Cash. Just add a few lines of JavaScript and you’re done. But it doesn’t allow you to run your own node.
bchwallet https://github.com/gcash/bchwallet
Does nearly everything technical I want to support, I’d just have to integrate it into my site in some way. Unfortunately it only supports Bitcoin Cash.
(I might use this under the hood, but I haven’t done enough research to know if I need to or if I can just interface with a node directly.)
BTCPayServer https://btcpayserver.org/
Many say this is the gold standard of accepting cryptocurrency payments. It does everything I want (and more!). Writing a custom integration shouldn’t be too hard either.
Although “BTC” in the name might lead you to believe that it only supports Bitcoin, it does support a number of other cryptocurrencies, such as Litecoin, Monero and even Bitcoin Gold…
But it doesn’t support Bitcoin Cash.
Why? It seems the maintainer has bought into the “BCash” propaganda: https://mobile.twitter.com/BtcpayServer/status/963686582862655488
I have my response. no support for it. And I will not accept PRs until all BCash wallets stop considering Bitcoin addresses as valid. (Not an help desk) Then finally I will accept PRs on the condition that the name “Bitcoin Cash” never appear. (BCH or BCash only)
Note the double standard of supporting Bitcoin Gold and Bitcoin Plus even though they both consider Bitcoin addresses as valid and they both have “Bitcoin” in their name, which is also used in their documentation.
https://docs.btcpayserver.org/Altcoins/
And then there’s professional comments like these: https://mobile.twitter.com/BtcpayServer/status/1031388746531332096
Sigh.
CryptoWoo https://www.cryptowoo.com/
This is a nice plugin that supports a variety of different cryptocurrencies, and it would fit except it’s not open-source, it’s not free as I want to support XMR and it only works in WooCommerce.
NOWPayments https://nowpayments.io/
Easy integration and supports lots of coins, but they have a minimum payment amount of $3-5, they have KYC/AML and I can’t use my own nodes.
Why is this important?
Now my little use-case isn’t important in the grand scheme of things, but at the same time it is. So let’s take a step back for a sec to see why.
People are currently gushing over Bitcoin’s price again and are asking the question *when will cryptocuriencies win?* At $50,000 per coin? At $100,000? Or perhaps at *gasp* $1 million?
I think this misses the mark, and it’s not ambitious enough.
*The end goal isn’t a fiat price, it’s not having to care about the fiat price.*
I want to be able to receive my salary, pay my bills and buy the stuff I need using crypto, without having to go back to fiat. In short I think cryptocurrencies win when they’re as widely accepted as PayPal or VISA.
And to get there we need as many merchants as possible to accept crypto. Which means it must be as easy as possible to accept them for your business; regardless if it’s in-person or online, what tech is used to build your website or whatever requirements you might have.
That’s why it’s so important to remove friction of any kind from the process of accepting payments. And that’s why even my little project is important.
A simple plan for the hackathon
Given that I don’t have a lot of time, and I haven’t programmed against cryptocurrencies before and I’ll also use a language and framework I have little experience with, it makes sense to have a modest goal.
My goal is simply to accept BCH payments in a small demo website, and verify them using my own full node.
Growing to a fully fledged project
If it makes sense to do so I might develop the project further after the hackathon, and I do have a tentative plan on how to do that:
Refactor it out into an Elixir library
To make it easy to include it into a new Elixir/Phoenix website. It would be great if I could do this during the hackathon as well.
REST API
On top of the library we can build a REST API so that we can integrate payments into other frameworks or e-commerce stores that don’t use Elixir.
Documentation
A boring—but very important—part of any API or service is documentation. People think that features is what differentiates the good from the bad, but frequently I find quality documentation is the decider.
More integrations
I’ll start with an integration for Phoenix, because that’s what I prefer. But there are tons of general frameworks such as Ruby on Rails, Django and Laravel, or e-commerce stores like OpenCart and WooCommerce. The goal must be to support the popular ones to make it as easy as possible to start accepting payments.
And it should be easy to write your own custom integration if native support is missing or include a small JavaScript snippet à la PayButton or Stripe.
Self-hosted and public servers
It should be easy to spin up a server of your own, so you have full control of the payment processing. But everyone don’t want or need to do this, and for them we should have public servers they can connect to.
Support more cryptocurrencies
This is important as merchants would otherwise be forced to integrate multiple payment processors for the different cryptocurrencies they’d like to support. This is very cumbersome and they might instead opt to use BTCPayServer—that lacks Bitcoin Cash—or skip cryptocurrency support entirely.
The fight for adoption isn’t a zero-sum game between competing cryptocurrencies—it’s a fight to convince the rest of the world that they should start using cryptocurrencies.
Under these larger goals there are many details missing. Enhancing 0-conf security using double-spend proofs is one example, supporting different payment protocols is another.
While this project could grow massively in size, I will start small and expand if it’s valuable to do so. But the plan for the future is here.
Shoot for the moon. Even if you miss, you’ll land among the stars.
— Norman Vincent Peale
An update on my book 'Why Cryptocurrencies?'
Five months ago I gloriously declared that "my book was done". Since then I've been working hard to finish the book. https://read.cash/@jonas_h/ive-finished-my-book-why-cryptocurrencies-that-describes-why-cryptocurrencies-are-useful-764655d7 https://whycryptocurrencies.com/
Sorry that's a bit of a lie, I've had a nice long vacation where I didn't work on the book and I'm also on part-time parental leave. And believe me there's not a lot of time left over with two kids pulling for your attention.
Although they won't be finished this year, I've made some good progress on the e-book and on formating the physical book and the goal is to have them ready some time next year. The plan is to release the e-book (PDF and epub) as pay-what-you-want for BCH (and some others) on my site while releasing it as normal on Amazon and similar.
I've also done a re-read of the book to make a bunch of fixes, so if you haven't read the book yet now might be a good time. It's completely free to read online. https://whycryptocurrencies.com/
Because I started the book almost two years ago (yikes!) there are some new events that I've added:
As a response to COVID-19, the FED has printed an extreme amount of money in a very short time, displaying the problem with unsound money for all to see. https://whycryptocurrencies.com/a_defective_system.html#the-stock-market-magic-trick
Lebanon became to second country to experience hyperinflation in 2020 (Venezuela didn't escape theirs). https://www.nationalreview.com/2020/07/life-in-lebanon-under-hyperinflation/
The U.S. court declared that the mass surveillance program exposed by Snowden was illegal. https://www.reuters.com/article/us-usa-nsa-spying-idUSKBN25T3CK
The extradition hearing against Assange, where the U.K. will decide if they should deport him to the U.S., is a complete farce. For example the U.S. managed to convince the judge that any reference to the torture in Guantánamo couldn't be mentioned, so key witnesses were blocked from testifying and evidence were censored. https://www.craigmurray.org.uk/archives/2020/10/your-man-in-the-public-gallery-assange-hearing-day-21/
Yet I feel that nothing has really changed. The argument for cryptocurrencies are the same as two years ago, and they're only growing stronger.
I've finished my book 'Why cryptocurrencies?' that describes why cryptocurrencies are useful
My book, which I've been working on-and-off for more than a year, is now completed. You can read it online for free. https://whycryptocurrencies.com/
I began this project after I got tired of the news, my friends, my coworkers and people in online communities continuously claiming that cryptocurrencies have no use case and are just digital beanie babies. With this book I hope to put these ideas to rest in an approachable manner.
The focus isn't on any single cryptocurrency, but on the potential of the cryptocurrency idea. Some of the topics we'll cover are:
What money is and how cryptocurrencies have excellent money properties
The usefulness of cheap and irreversible digital payments
Why uncensorable donations are important
How cryptocurrencies allow you to reclaim some of your financial privacy
The moral hazard and warped incentives behind the 2008 financial crisis
Provably fair gambling
If you want another summary check out the introductory chapter Why cryptocurrencies in five minutes or head over to About the book or the list of chapters. https://whycryptocurrencies.com/eli5.html https://whycryptocurrencies.com/about_the_book.html
The online part of the book is finished (or as finished as it'll ever be). Next I'll work on creating an e-book and a paperback, but I don't know how long that might take.
If you enjoyed the book please help spread the word or consider donating. https://whycryptocurrencies.com/free.html#donations-is-a-perfect-use-for-cryptocurrencies
@jonas_h