 Karen asks, safest practices for accepting bitcoin at my business? I have two businesses. One is about 150 to 650 per customer transaction. The other one is about two to six thousand dollars per customer transaction. What are the safest practices I should observe while accepting bitcoin for payment? Well, that's a great question, Karen. There are so many angles to this particular question that I'm going to start with the basic and fundamental principles. What is the most fundamental and basic principle in cryptocurrencies? You may have heard me say it one or two, three thousand times, not your keys, not your coins, your keys, your coins. What you should be doing first and foremost is taking and keeping custody and control over your coins by controlling your keys. That means do not use custodial solutions. Many of the merchant processing solutions that facilitate accepting bitcoin payments are custodial solutions. For example, if you use BitPay or if you use Coinbase, the standard Coinbase wallet, those are custodial solutions. The same thing happens if you use any mobile wallet that actually connects to an exchange and where they control the keys. Those are not good solutions. The reason they're not good solutions is because they are surveillance laden and at the same time they can be hacked. You can lose your crypto because they get hacked or through embezzlement or through some kind of exit scam, etc., etc. Finally, they can also confiscate, freeze, seize, and stop your business anytime they want because they're banks. That's what banks do. The first and foremost thing you have to do is control your own keys. Given the size of these transactions, the answer is obvious. You need to be using a hardware wallet. I wouldn't take transactions of this size. Even the smallest one, $150, one transaction pays for your hardware wallet and you're done. But when you're talking about $2,000 to $6,000 per transaction, I would not store that kind of bitcoin on anything but a hardware wallet. Your keys on a hardware wallet. Now let's talk a bit about the software implementation of how you would accept bitcoin. That depends on the frequency and number of clients you have. If you have only a handful of customers and these customers make a handful of these transactions per year, which is the case, for example, if you're a consultant or a freelancer, then you can probably handle this fairly easily without too much software. Meaning that what you can do is you can use a software wallet, either one provided by your hardware wallet provider or something like Electrum, which is also a good choice. While keeping your keys on the hardware wallet, you can do things like generate addresses and payment requests on your software wallet that you can send to your clients and embed in an invoice. Now, what's the other very important criterion when you're using cryptocurrency, especially bitcoin, is only use each address once. So we don't do address reuse. Now, if you want to avoid address reuse, then you have to be able to generate a new address for every invoice you give to every client. Every payment, even if it's the same client, should go to a separate address. Every address should have preferably one incoming payment, one outgoing payment, and never be used again. And that's it. So you should not reuse addresses. You should give a separate address for every single payment to every single user. Finally, there are a number of other things you can do to make that easier. Now, obviously, if you're running a web shop, some kind of e-commerce system, or you have a lot of invoices you're sending to customers, it's going to get very cumbersome very quickly to keep generating new addresses manually, copying the addresses, putting them in the invoice, making sure you didn't make a mistake, making sure your clipboard wasn't compromised, and replacing the address with an attacker's address, making sure that you got paid. And when you got paid being notified when you have enough confirmations, et cetera, et cetera, et cetera, all of these things get too cumbersome. If you're running a web e-commerce shop, of course, you can't do any of this stuff manually, you have to find some kind of solution. Many people then immediately go to a custodial service, and I think that's a very big mistake. There are a number of ways you can integrate non-custodial services. I, at the moment, I'm particularly fond of the BTC Pay server, which is an open-source project for non-custodial use of both Bitcoin as well as lightning payments to e-commerce solutions that has an API-compatible implementation to BitPay's implementation, and therefore, you can use it with a number of plugins for a number of popular e-commerce solutions. Probably the easiest way to set something like that up is to use a hosted BTC Pay server. You don't need to host it yourself because it's a trustless solution. You don't need to trust the organization that is hosting the BTC Pay server too much, just a tiny bit, because they might replace the wallet that's being used in your store. But for the most part, you don't need to trust them because they don't take custody of the money. It goes directly into your hardware wallet. You can use a hosted BTC Pay server that you rent from someone else or, and this is a pretty good solution, you can use a hosting service like Microsoft Azure and use a one-click deployment that deploys a BTC Pay server to Microsoft Azure for a fairly low cost per month. I think it costs anywhere from $20 to $30 to run a server like that on Azure. You can do something similar with Amazon Web Services and other hosting providers, although Microsoft Azure is the easiest kind of one-click installation. Once you have a BTC Pay server, you can then connect that to your web store. Now, if you're running WordPress, this is very easy. You can run WordPress with the WooCommerce e-commerce capability and connect that to BTC Pay server. In fact, we had a great tutorial on how to do that at the recent BTC 2019 Educational Conference in Denver. We're going to be releasing the video for that. There are lots of tutorials online on how to do that, and it's a great solution. Your store will generate addresses automatically and accept payments, lightning payments too if you set that up, and we'll be able to generate invoices as well as accept payments onto the BTC Pay server, where the funds are immediately transmitted to your hardware wallet. What the server is doing is generating addresses from your hardware wallet for Bitcoin. Therefore, there's no custodial intermediary your customers pay directly into your hardware wallet without reusing addresses. If you want to experiment with lightning, while that would be hashtag reckless at the moment because it's still experimental technology, it's a fun experiment and you can also do that for small payments. Looking at the fact that your minimum transaction is about $150, that probably doesn't make much sense. Lightning is usually more suited for transactions under $25, where the fees become a significant proportion of the payment. Whereas for transactions over $25, putting them on chain on Bitcoin is perfectly acceptable and the fees are not that big. That's basically what I would do in terms of safe practices. Maintain custody, don't reuse addresses, use open-source solutions, control your own funds, do not use intermediaries, and all of those things will allow you to be a first-class sovereign citizen. If you really want to take it one step further, run a node so you can validate the payments yourself by authoritatively verifying transactions and syncing the blockchain yourself. BTC pay server includes a Bitcoin node in it. It can be pruned to be a bit smaller, but you can also run that with other devices. One of the popular ones nowadays is the CASA node, which I haven't used, but certainly a lot of people are talking about it. So those are some ideas of what you can use. Again, I am not involved with any of these projects. If I mention certain projects or software systems, I don't have any financial relationship with them. I don't have any software development relationship with them. I found them to be useful in my work and I'm speaking from my experience. You may find them useful too. You might not. You have to do your own research and validate these ideas. Good luck with that. It sounds like you're on the path to doing some interesting stuff with Bitcoin. I noticed that Karen also mentioned that most clients are in person in her store. That was a follow-up on the chat. I'm glad we have the chat, because that's exactly what it's for. It's not for asking new questions that haven't been voted on, but for that kind of clarification and follow-up, it's very, very useful. So let me just add a few things here. You can use a software wallet and move the funds into your hardware wallet on a daily basis if you want, say, on your smartphone. That's probably okay for the short term. However, it's going to be a bit dangerous to do that, because if you're taking payments of $2,000 or more onto a smartphone, that's going to be a bit risky. One of the really interesting things that I found with the software I mentioned before, which is BTC PayServer, is that you can create very, very simple store applications. These applications are really just web frontends. So, for example, you can easily make something that runs on a point of sale. You basically have an iPad that connects to the BTC PayServer web frontend, and it goes directly to a page where you have buttons on the screen, one for coffee, one for tea, one for whatever, and you can set up your products, put pictures and prices against it, and even someone who's not trained can use it as a point of sale. Tap, tap, tap some, check out. Here's a QR code, pay. And again, that goes directly to your hardware wallet through BTC PayServer. And you can also use it to generate one-off invoices and one-off payment requests, where basically you just like a calculator, type in the amount you want to charge, hit submit, it pops up a QR code, and your customer can pay directly to your hardware wallet. And you can do that on a nice iPad. So, there are capabilities to turn this into a fairly effective, I mean, it's not a full point of sale system. It doesn't do inventory, it doesn't do anything else. It's just a simple mechanism for summing up the bill that you want to charge in a way that's easy for people who aren't trained, and then accepting a payment using the standard BTC PayServer capabilities. And you could possibly also have an expob on your smartphone and have the money go to a hardware wallet. Some wallets do that. I haven't used one that does that recently, so you can have a watch only wallet. I believe Samurai Wallet allows you to build a watch only wallet. Mycelium on Android probably does that as well. There must be a bunch of others that allow you to put a watch only wallet. What is a watch only wallet? That's a wallet where you have your hardware wallet, you generate the seeds on your hardware wallet, and then you export only the public part of a sub-account, and then you put that on your smartphone. Now your smartphone can generate addresses and receive payments, but those payments go directly to the hardware wallet, and only the hardware wallet can sign and spend from those keys. That may be easier to set up. It depends on who's going to be operating this and under what circumstances. If you're the only one operating it, and you just want a quick and easy way to say, pay me this much, boom, and have it go into a hardware wallet, that might be the most straightforward way to do it. Next question comes from Dimitris. Accepting donations via lightning, is it possible? The lightning network provides speed, anonymity, and low fees. If that's the case, why won't you accept donations via lightning? Please correct me if you do. It is unclear to me how to do basic stuff like receiving money without creating invoices. Can you please explain how this might work? What you're talking about is a particular subset of lightning functions, which is not yet specified as an interoperable standard that can be supported by all lightning clients, but one of the interesting things that's happening in lightning is that different lightning clients implement different features at different times, and they don't have to all coordinate or follow the same roadmap. Extensions to the interoperability standards can still be implemented independently. This type of thing is called invoiceless payment, so payment without invoice, because as you rightly said, one of the challenges for accepting lightning payments is that you have to generate an invoice in order to receive a lightning payment under most implementations and under current circumstances, but actually there are ways to do what's known as an invoiceless payment whereby you can send a lightning payment without having first received an invoice, and some implementations of lightning already support this. There's actually a link in the answer to the question that was submitted by Dimitri for a plugin that operates under the Lightning B implementation, so you can see that and see how that might work. I currently don't accept donations via lightning, and part of the reason I don't accept donations via lightning is because my lightning mode is still in an experimental stage, and I don't want to necessarily direct funds, too many funds, there because that would be reckless, and I don't want people to lose their money because they tried to send me a payment via lightning, and then I have some problem with my node that causes me to lose money, so I'm not quite ready yet. However, I do have a technical implementation that I am testing where I would like to accept lightning payments in the near future, and the way I'm doing that is by combining lightning nodes, which I've been running now for just over two years, in fact. I run a version of LND as well as a version of C lightning, which are two different implementations of lightning nodes, and on top of that I also run a BTC pay server, which is an infrastructure component that allows you to manage both Bitcoin, lightning, and many, many other UTXO compatible chains like Litecoin and things like that, and allows you to generate invoice, to generate payments, run point of sale systems, etc. that are completely decentralized in nature, meaning that they're non-custodial. You are not going through a third-party provider, it's a self-hosted solution, it's open source, you run the server yourself, and that allows you to generate both Bitcoin invoices in order to receive incoming payments, as well as lightning invoices to receive incoming payments. This was originally created as a counterpoint to a popular commercial service called BitBay, which is both custodial in nature, and generates invoices that are not compatible with most wallets due to certain political considerations, and BTC pay was designed as an API compatible self-hosted non-custodial alternative, and I really like that project. I'm not endorsing the organization that's behind it, but it's a collaborative project by many developers, and I use it personally, it works well for me. I use BTC pay to invoice my customers, for example, to invoice conferences that want to pay me in Bitcoin. Now, that's not a lightning payment because it makes more sense to do that as an on-chain payment, because conference payments generally are not under $150. The sweet spot for lightning payments is for smaller payments, because for large payments, it's just as easy to do it on-chain. I'm also running the lightning notes and the lightning implementation. In the next few weeks, I will be announcing a simple merchandise store that has some nice meme-worthy t-shirts. Patrons, you've already seen that. That store accepts both Bitcoin and Lightning using that BTC pay server and the underlying Lightning node infrastructure that I've been building for the last two years. It allows me to further experiment with this technology, but also to show it to both my patrons and the public at large. There's a good chance that I will be adding a lightning donation capability to my website for people who want to donate money with lightning in the near future. That will require generating an invoice on my end. I'm not yet ready to experiment with invoiceless lightning payments, but that's certainly possible in the future. Lightning can operate in such a way that you can send payments without an invoice. It has been demonstrated repeatedly at lightning conferences and other places. These are still experimental features. We're still in the process of experimentation on some of these features where they will probably be standardized and introduced in a way that can be implemented by all lightning clients in a future version of the Bolt standards, the Bolt specifications, if you like. Bolt stands for basis of lightning technology, and it's a set of standards that allow lightning clients to interoperate with each other in a fairly consistent way. We're currently in the first version of those standards, and a new version is expected in the next year or so to add more interoperability capabilities across new features like invoiceless payments. David asks about lightning network auditing. For unchanging transactions, an auditor can use a block explorer. How can an auditor best check the state of a ledger where coins are held on the lightning network? Also, given the potential number of micro transactions that a user could enter into, how best can a user manage their records for tax purposes? Great question, David. David, an auditor can only check the state of the transactions that are terminating or originating from a node if that node provides the records. So each node holds logs, and those logs keep track of transactions that are originating about network node and transactions that are paying that network node. Some nodes may also keep logs of transactions that are simply routed through. My node does not keep those logs. As a result, if you want to audit the lightning network, you can only audit a node, and only if that node volunteers that information, and this is privacy. This is one of the fundamental differences between the lightning network and the base blockchain of Bitcoin and other blockchains that might participate in the lightning network, is that you can't just go to public explorer and see everything that's happening on the network, not even with obfuscated addresses and identities. You can only see the information from a node if that node shares that information voluntarily with an auditor. The same thing for tax purposes. If you want to do your capital gains reporting, for example, and I have a node that I'm running, which is part of an e-commerce store, both the e-commerce store and the node itself for keeping logs of the exact price of Bitcoin in US dollars at the time of every payment that comes into my lightning node. I record that information and I share that with my accountant in order to count capital gains. With micro transactions, this becomes very cumbersome. Part of the problem we have, especially in the US today, is that unlike other currencies where usually there is a minimum of $600 or so, below which you don't do capital gains reporting because it isn't an investment purchase, and it's not capital, but instead it's a retail transaction, that exemption does not exist in crypto. As a result, the IRS has put itself in a situation where it creates an enormous burden on users of micro transactions who have to report every penny and then calculate miniscule capital gains and losses that inundate the tax office with pages and pages and pages and pages of spreadsheets, which amount to very little tax being paid, but a huge administrative and accounting burden, both on the side of the client who has to pay their accountant, but also on the side of the IRS that can't possibly audit hundreds and hundreds and hundreds, perhaps even thousands of pages of tiny micro transactions, for what to get a few hundred dollars in capital gains, so not worth it. So lightning network auditing is not easy because lightning network has superior privacy to the base blockchain and capital gains is done through traditional mechanisms by keeping records primarily at the e-commerce level of every payment that comes in, but it creates a huge burden if you go into the micro transactions area.