Everyone saying filters "don't work" because spammers are just using op_return_bot to get around them? Yeah, op_return_bot has to charges double the regular fee rate or its bypass doesn't work reliably. This is a huge deterrent. The filters work.
Source: https://github.com/benthecarman/OP-RETURN-Bot/blob/master/app/controllers/InvoiceMonitor.scala
nostr:nprofile1qqszrqlfgavys8g0zf8mmy79dn92ghn723wwawx49py0nqjn7jtmjagpz4mhxue69uhkummnw3ezummcw3ezuer9wchszyrhwden5te0dehhxarj9ekk7mf0qy88wumn8ghj7mn0wvhxcmmv9uynmh4h your efforts are appreciated.
I'm still waiting for hedgehog based wallet, any progress on that?
Lete know when you plan your next bitcoin script session, I'd love to join.
I got tired of working on hedgehog and moved on to other things
Maybe some day I'll get back to it
I do not currently plan to do any more workshops
There are four ways to create an invoice with a "decoy" node id:
- I used lnproxy.org to "wrap" my invoice so that instead of "my" node id appearing there, lnproxy's appeared there
- you can also toggle the "blinded paths" option in LND or Zeus Wallet. Among other things, that option replaces your node id with a dummy key
- you can also use TransLND or Valet Wallet, which have an optional feature where they will create a decoy pubkey for all of your invoices by pretending that your node is a routing node and the "real" recipient is a node it just made up
- you can also use Voltage or my Zaplocker software, which have an option to wrap all invoices so that all inbound payments to your wallet appear to go to Voltage's node or the Zaplocker server, even though they really get forwarded to the recipient
Also, it is worth pointing out that even without doing any of this, the public key in an LN invoice does not actually receive money, it is only used to sign communication messages.
As a result, it does not reveal which node it belongs to unless that node's network address and channels are gossipped via the LN gossip protocol, and that only happens if it is a routing node. A simple wallet with ungossipped channels does not reveal the network address of the node that controls it, so the pubkey in an LN invoice cannot be used by itself to find your node.
I like monero, I think competition is good
Turns out it was dumb, because I forgot that you have to commit to data to the control block in a prior tx, so in that sense it's just as bad as an inscription. You could get around this by putting the data in the taproot annex, but that is non standard so it would also require relaxing the anti-spam rules, which I don't want to do.
Apparently, Citrea decided not to put their spam in inscriptions because inscriptions have to be "unwrapped" in a second transaction. When the data is less than ~150 bytes, it's cheaper to put it in unspendable outputs, despite getting no witness discount.
I think they could get the witness discount and still avoid a second transaction by putting the spam in the control block. It lets you add up to ~520 bytes of spam by encoding your data as merkle leaves, each of which can be 32 bytes. No extra tx required, AND you get the witness discount.
I checked the Core Lightning github and multipath payments are "on" by default there too. See, for example, this issue: https://github.com/ElementsProject/lightning/issues/3926
It involved an error report where a user encountered this entry too many times in their error logs:
"Detected large payment, splitting into 100 sub-payments"
I checked the Eclair github too and multipath payments are "on" by default whenever trampoline routing is used (which is the case in Phoenix, which always uses Acinq as a trampoline node)
> Multi path payments is optional for every wallet I've tried that even has it available
Which wallets have you tried? It's built into LND and turned on by default. So any wallets based on LND should just do it.
E.g. most custodial wallets as well as most nodes-in-a-box (Umbrel, Start9, etc.), plus many mobile phones like Breez, Zeus, Blixt, Bitkit, and ShockWallet.
Multipath payments are also turned on in electrum by default and I suspect they are turned on in the other implementations by default too
My hope is that people would mostly use it for legal stuff but I'd also like to see bibles on there wherever that's banned
"more resilient" sounds like an upside in itself
Nate says:
"I don't understand why it matters how blocks get filled. Use lightning for basic spending if you want to use bitcoin as money. If you can't afford to, use ecash until you can. As for ease of running a node, a 4tb drive gets cheaper everyday. should be good for a decade or two."
Everything after the first sentence seems spot on. Also, I like the idea of reducing the cost of using lightning so that poor people can acquire self custody faster. Creating multiple channels in a single utxo seems like a promising way to do that.
Let's suppose Dave wants to pay John, and passes through these nodes: Edna, Filbert, Gena, Harry, Isabella, John
Harry decides he wants to collude with the other routing nodes to find out who sent the payment. So he walks backward: he contacts Gena, and says, "Did you initiate the payment?" Gena says, "No, I forwarded it from Filbert." So they both go to Filbert, who says, "Wasn't me, I forwarded it from Edna." So they both go to Edna, who says, "Wasn't me, I forwarded it from Dave." So they both go to Dave, and ask him, "Did you initiate the payment?"
Dave has a few options. He can, for example, say nothing. Silence doesn't prove he initiated the payment; it only proves he doesn't want to answer. Maybe Dave is a routing node with a good privacy policy.
Here's another option I just thought of: it would be fun to write some software that makes it easy for Dave to spin up a perfectly valid node for Carol, who is a fake person who Dave invented out of thin air, and make it look like she forwarded the payment to Dave. Then Dave could say, "Wasn't me, I forwarded it from Carol." Then, if they go to "Carol" (who is really Dave, but they don't know that), he can spin up a node for Bob and just keep doing that, leading them on a neverending goose chase.
Suppose that the bad guys give on on trying to find the source (Dave) and seek the destination (John) instead. Harry can ask Isabella if she forwarded it to anyone, and she might say, "Yes, I forwarded it to John." Then he and Isabella might ask John and he lie and might say, "Yes, I forwarded it to Kelly," and spin up a node for her so Kelly (who is really John) can "prove" it, or he might just not answer. Either way, the colluding routing nodes have no idea who the sender or the recipient is: they just know that at some point people stop answering, and that might be for a variety of reasons. Refusing to answer a cabal of routing nodes does not prove you are the sender or the recipient.
By the way, since routing nodes are run by a variety of people and most of them do not have contact forms or any sort of formal policy about how to contact them if you want to collude with them, I think it's very unlikely that Harry would get an answer in the first place from Edna, Filbert, Gena, Harry, or Isabella. But even if he somehow did and every routing node colluded, they still can't identify the sender or the recipient.
> He's wrong about unencrypted receiver (or meant something else)
I meant what I said: monero does not encrypt the receiver. If it did, monero devs could tell me what encryption standard they use (in lightning, we use the Sphinx encryption standard specified in bolt4) and they could point me to the code where the recipient's key gets encrypted (in lightning, that code is here: https://github.com/lightningnetwork/lnd/blob/b068d79dfbd2f583d890fd605953d0d4fb897a27/htlcswitch/hop/iterator.go#L114)
Monero does not encrypt the recipient's public key -- it gets published in plaintext on the blockchain -- so the protocol does not specify any encryption standard for that and there is nothing in the codebase where it gets encrypted.
I like that I can point out how lightning fixes a privacy attack vector and the response is "ok but it doesn't fix ALL attack vectors -- there's probably some other one it's vulnerable to."
Yeah, probably. But even if other attack vectors exist, that's no reason not to fix this one. I think monero should fix it too, and I am glad FCMP is being worked on to hopefully do that.
> You sure it's final? So is it still there?
I am not sure anymore, but I don't think that matters. By "final destination" I don't mean" it never moved again." When I "arrive at my final destination" via Google Maps, it does not imply that I will never leave that place. It just means I am done moving for purposes of that trip. When I sent my money to you, the "trip" was getting the money into your address. I know I did that, so the trip was finished -- it got to its final destination. If you moved it out again afterwards, that is a separate trip and is unrelated to mine.
> How are you sure the address on my profile is mine either?
I don't. But I know it's the one you told me, so that's good enough for me.
> I trying to understand lightning privacy more.
Great! I hope I can help.
> When I provide someone with a lightning invoice do I not reveal to them my lightning node?
No. Lightning invoices only contain a pubkey, they do not tell them which node is yours, for which they also need an ip address, and lightning invoices do not expose ip addresses. If, however, you run a routing node on clearnet, then they can look up your ip address, because routing nodes gossip that information along with their pubkey and their channels.
Also worth pointing out: if you opt to use blinded paths in your lightning invoice, the pubkey in that invoice does not belong to you. And the use of blinded paths is undetectable, so there's no way to know if a particular invoice is using it, meaning there is no way to know if the pubkey in any lightning invoice belongs to the real recipient -- it may just belong to one of the routing nodes and there is no way to find out.
> if I have even been sent sats from a KYC exchange or have otherwise linked my lightning node to myself for example through displaying a LNURL am I not doxed?
No, for the reasons pointed out above: there is no way for the service you used to know if the pubkey in your lightning invoice belongs to you, and even if they did know that, it is not linked to your node, because to link it to your node they also need to know your node's ip address, which is not shared when creating an invoice or when making a payment. Though if you are running a routing node on clearnet, then they do know it.
> Not just the current transaction but all future invoices can be linked to me?
No, because they don't know if the pubkey in your lightning invoices belongs to you, and moreover, you can use blinded paths to make it a different pubkey every time. If your wallet does not support blinded paths, you can use lnproxy.org to do it manually.
> From a node ID I can see all channels as well as a list of any closed channels and see all of the on chain BTC associated with that and follow their flows on the base chain
No. Only routing nodes gossip their channels. If you're running a regular node, your channels are not gossipped, and your node is also not gossipped, so someone with that invoice cannot map your node to your channels. They cannot find your node, and although there are techniques to find ungossiped channels, I am not aware of any techniques for finding ungossipped nodes or mapping ungossipped channels to them.
> Is my understanding correct and if so that makes lightning seem problematic to me for privacy.
I hope this clarification has helped.
> Is the point I am missing that the node ID in the invoice could be set up to just forward the payment to someone else? Is there a special way to create an invoice that does this?
Yes, many wallets do this by default:
- if you use Voltage LSP, it does this by default
- if you use Zeus wallet, you can enable it in two ways: either toggle the Zaplocker option, or toggle the Blinded Paths option
- if you use Coinos, you can enable it via the bolt12 option
- if you use Phoenix, you can enable it via the bolt12 option
- if you use any other wallet and it doesn't support bolt12 or Blinded Paths, you can use lnproxy.org to do it
> doesn't mean law enforcement couldn't subpoena large node operators (?)
They could *try* to subpoena large node operators, but thankfully, routing nodes do not know the destination either. This is because the onion protocol lightning uses is designed so that routing nodes don't know their position in the route. Consequently, they do not know which node is the last hop, and cannot identify the recipient, who is the node after that.
I answer most of these criticisms in the attached post.
One that I don't go over there is this one: "he slips in 'total balance' (he can't do the equivalent of this with Monero either)"
I can. The total balance of a "one time pubkey" on monero is never higher than its initial balance. It can get lower, but only if that address has shown up in a ring sig later. When I made that post, it hadn't shown up in a ring sig yet, and I know this because it didn't have 10 confirmations yet when I made the post, and monero doesn't let you spend an output til it has 10 confirmations. I have not checked to see if it has been used in a ring sig yet, but if it hasn't, then I know its balance is still the amount I put in it.
nostr:note1pjsqetvr45nklmz9el4a4fk0excg2hv63cp4m9le6fzksqdg3zlsemzvem