Subnostr

A rare bitcoin note.

Thinking through using Lightning for plausible deniability. The essence of tax law is to determine what was paid (in fiat) for an asset (Bitcoin) and then what the asset was sold for (in fiat) to determine some amount of "capital gain" (in fiat).

Let's assume both Strike and River have fee-free lightning send/receive capability. I buy Bitcoin on Strike. Then I send it to a lightning address on River. Yes, I'm KYC'd on both services, but neither is necessarily aware of where the Bitcoin came from. The sender is at least somewhat aware of where it is going, but may not know which user of the service it is going to.

I'm going to keep this simple - I wouldn't actually do this, but let's say I kept the balance on River. Then, one day I needed some fiat dollars, and so I sent some bitcoin (not the same amount as any prior transaction) from River to my Strike account, again using lightning addresses. Strike doesn't know where that came from, but has to assume I own it. River knows that it left River, and may know it went to Strike, but probably doesn't know who it was going to, only that I authorized it.

Then I immediately sell the Bitcoin on Strike, and withdraw the fiat dollars to my US fiat bank account.

Who is to say what capital gain or loss is made on that Bitcoin? I believe the only gain or loss than can be determined is from the Bitcoin price (as determined by a third party) when the Bitcoin arrived at Strike (from River), and the price Strike opted to sell the Bitcoin at. This would be happening minutes, if not seconds, apart, so there would be very little price change, and very little gain or loss.

Any other way of determining gain/loss would have to make assumptions that may or may not be true. It would be prohibitively difficult for me to even determine a past bitcoin exchange rate or point in time to base a capital gain/loss from. Even if I had great accounting that showed the exact time I acquired every sat I have ownership of, so I could follow a FIFO or LIFO method of accounting to determine gains, that would be ridiculous and incorrect, as I receive free sats from reward programs, I earn sats from mining, or exchanging for goods and services, and sats on exchanges might not technically be mine until I possess them in my own custody, depending on the exchange TOS.

This is an example of regulation that simply does not cleanly apply to a different technology. What makes sense for a stock, bond, or even commodity, metal, or foreign currency, does NOT make sense for Bitcoin. This isn't even poking at KYC, just at fiat pricing and capital gain taxation.

Try to poke holes in this and show me where I'm wrong, but I think using lightning in this way to create some plausible deniability and break the ownership chain should be enough to do what many are using coin joins, whirlpools, etc. to accomplish. I have a similar method that would work privately to break KYC by using lightning and a couple privately held lightning nodes, but it is a bit more complicated. What I am describing above takes no technical skill and does not even assume self-custody.

I'm not telling anyone to sell a single sat. I'm also not telling anyone what to declare to their governments. This is a way of looking at things that may influence your behaviour, though. Stay humble.

Beerborn 2y ago

Not sure about the exact tax laws were you are, but were I sit, you have to account for every sat you've bought to calculate your cost basis and then calculate capital gains/losses every time you sell. That means moving the sats around changes nothing.

Sats received through other means need to be accounted for too, at different costbasis depending on why you got them. Gifted sats at a cost basis of 0 (essentially making your purchase sats more expensive to sell), mined sats at spot price basis. Sats you got from goods and services go at spot price at the time of payment and also require you to pay VAT (~25% of the received fiat value). Sats in any account with your name are (even the IOUs from exchanges/mining pools) are considered yours a soon as they land on your balance.

Sats you pay for goods and services are considered as sold for fiat and that fiat used to pay, so you should declare capital wins/losses everytime you spend sats. That includes network fees.

Not complying is almost a given considering how extremely hard it is to follow all the above and keep track of it all. Yet, it's on you if you don't. Flip side, it's too hard for them to check you do all by the book, so they'll mostly believe whatever you say. Once you make peace with the fact that even if you try, you won't comply 100%, it's a short road towards "If even trying I won't comply, why try at all"

Reply to this note

Please Login to reply.

Discussion

Sedj 2y ago

The flip side is what I am optimizing for. I am interested in making it harder for them to check anything by their own rules. And all I can tell them is that I don't know, because I don't. If they want to try to figure it out, they can go right ahead, but at the end of the day, they won't know either, and I have no intent or motivation to help them.

Since they will mostly believe whatever I say, it is to my benefit to say only what can be obviously confirmed. That is, at the time the sats sold went on the exchange (which is likely reporting to them), they were valued at X, and when exchanged for fiat, they were valued at Y. This is my best try at complying, although everyone knows it is not 100%. Any valuation prior to those sats being on the exchange is clouded in assumption.

Beerborn 2y ago

Here are my main concerns.

If you use another KYC place to store from purchase to sell, it's easy to trace from Exchange A to B and back again. With no other inflows cost basis is safely assumed at purchase price on Exchange A.

If flows between A and B don't match, you've either sold somewhere else and are not declaring it, you bought/obtained somewhere else and are not declaring it. You are keeping a stack somewhere that is neither A or B. At that point you'll most likely be asked to provide evidence of the third option in order to discard the other two, or you'll likely face tax evasion charges. Now, in order to prove the third option AND disprove the other two, you'll need to have the mismatching amount somewhere else no more, no less.

You may think, if they can't prove what you have or don't somewhere else, they can't prove there's a mismatch. While true, I think you might be overestimating the presumption of innocence of your country. Once "sufficient proof" has been brought up, the burden of proof will be shifted from them to you and not providing proof of those reserves will be equated to tax evasion and money laundering.

That's why it's called parallel accounting and not multiple-times-intersecting accounting. If you don't want to pay taxes on your non-KYC, your KYC and your non-KYC should never mingle. And if you are going to do that, then what's the point on moving stuff between KYC services/wallets?

That's my two sats, anyway

Sedj 2y ago

I think that it is not that easy to trace the transfers when done via lightning between exchanges. If we were talking on-chain transfers, I completely agree with you.

Beerborn 2y ago

If both exchanges are KYC, you should assume both are sending the information to your tax agency. So neither of the exchanges can trace it, but the outside observer receiving the information from both sides can definitely see it.