@jonas_h
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/
11 comments
I'll read this later. Have an upvote until then.
I think good payment processing software is definitely sorely needed as the existing solutions are often BTC-oriented and the major service providers are being marched into KYC-ridden swamps that will be kept uncompetitive against traditional finance solutions. The high level direction here looks good. I would support such a flipstarter.
I would probably contribute to a flipstarter but would prefer if you could somehow make money to be sustainable
Indeed. Other funding ideas I have: * Offer premium support (this might also include developing an entire website or new advanced features) * Require a subscription for the publicly available REST API over a certain amount (self-hosted should always be completely free)
mullvad vpn has the best self-custodial crypto payment processing that I have seen. It would be worth talking with them about it for anyone who wants to take this seriously. No need to reinvent all parts of the wheel if someone has done a good job on most of it already.
Good idea, I'll reach out to them.
Can you describe what are the problems with btcpay and bitcart? I have not looked into them deeply but I agree that BCH needs a good payment processor.
BTCPayServer seems very anti BCH and repeats the "BCash" mantra: > 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) > https://mobile.twitter.com/BtcpayServer/status/963686582862655488 Bitcart does have Bitcoin Cash support but they focus on Electrum and SPV security, without full node support. I also haven't found any solution that focuses on reliability the way I'd like it to. That said they do offer more features than I was planning on. BTCPayServer offers apps including wallets and Bitcart has a built-in store you can use.
Ver well done, congratulations! And good questions. I too am asking similar questions of how to turn a novel and noble idea into a sustainable business venture (for https://devpost.com/software/purelypeer that I initiated and guided). In your case, I think the best approach would be to plan out a "freemium" approach and describe it in your intended Flipstarter clearly. Then if the Flipstarter succeeds, the community will know what "free" services you had outlined. Or if the Flipstarter does not succeed, you will have a path to generate a sustainable venture yourself at your own pace, knowing that you have a plan in mind. For instance, let users, and especially those in <$2.1/day communities (pun intended, to instill the BCH fixed, inflationary-resistant supply idea into minds of people outside of our ecosystem), use your platform for free, up to a certain amount, e.g. $210 sales. Then charge a small percentage fee that is better than CCs and/or other payment processors, something that people will not mind (e.g. 0.21%). Target volume over the long term and focus on growth early on. And do provide optional extra services on a subscription model that would be hard to say no to (e.g. $2.1/month subscription for custom BCH-to-fiat blockchain explorer receipts and local accounting) in a DB securely hosted by you (or find a way how to do it through BitcoinApps on-chain). Also, over a certain amount (and to avoid KYL / AML scrutiny, e.g. over $3k individual product prices and/or sales), do require the merchant subscription so that everybody's intentions are clear and compliant, and ask for customer contact information in the form of an email at least (if someone is paying >$3k online, chances are they would like to leave at least a burner / anonymous email in case that something goes wrong with the transaction process). I understand why some compliance is needed at certain thresholds but, as a user, I despise BitPay for asking my email address when simply buying a $10 VoIP credit.
Thank you for your input. I'm opposed to any form of KYC/AML for this project. It might be possible to require an account (like Mullvad does, even without having an email) and make the public API free it up to a certain amount and then require a monthly subscription. If you self-host it will always be free of course.
- Copy of the Reddit reply (in case we ever get deplatformed there): Yeah, that is a suitable path to go for. Note that some merchants might want to have their information recorded and presented for their own internal accounting purposes and integration with the legacy banking (think of what https://devpost.com/software/chainbridge have been developing), and those would be in a way self-KYCed already. With the optional subscription revenue model, those would be the easy customers who could have higher limits unlocked and provide regular revenue stream for you. For everybody else, your code should likely include an upper boundary for a maximum allowed transaction. If someone forks your code and updates it and self-hosts it to avoid the upper threshold, then of course you cannot prevent that...