Question for those who claim LN payments are not private if you use an LSP
Why not? What changes?
- The invoice still doesn't tell you or the LSP the recipient's address
- The LSP still doesn't know if you're the sender or just another routing node
Why isn't that private?
wait, no, it breaks a rule:
LOAD → LODE
that changes A to D and D to E
One letter at a time, friend!
You can bring it down to seven by changing bone to lone -> line -> live
Lind is a variant of the word lend, at least according to the Oxford dictionary. And lene is a variant of lean according to the same.
So you could do:
lead
lend
lind OR lene
line
live
I'm just waiting for a plane
deal
dell
fell
fill
file
tile
tike
like
live
nostr:npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s Your excellent "NWC Tester" should probably at some point support the new "Notifications" in the spec ( https://github.com/nostr-protocol/nips/blob/master/47.md#notifications ).... I have hacked together a pull request to add this .. https://github.com/supertestnet/nwc_tester/pull/1 .. but obviously if you see a better or more elegant way to do this, please feel free to reject this pull request and do it your own way when you are ready.... thanks...
Reviewed and merged. Thanks!
Really excited about this: https://bitcoinweek.dev
We rented all needed venues yesterday and have a great lineup of speakers:
- Ronny from The Bitcoin Hardware Store (https://tbhs.sv)
- Chris Guida, the lightning maxi (nprofile1qqsz39wrxrpr7wp3jmqwlxydumdg8wpmgkp76huurmds54vuangljqqpzamhxue69uhkummnw3ezuendwsh8w6t69e3xj7spz3mhxue69uhhyetvv9ujuerpd46hxtnfduq36amnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46q97ed2z)
- Dulce from Libreria de Satoshi (https://libreriadesatoshi.com)
& more!
I don't think the bond affects the trust model. You still trust the custodian with your funds, the bond just helps robosats filter out spam because the spammers lose money by spamming the platform with fake offers or fakely accepting an offer.
(1) Here is a partial list of p2p bitcoin exchanges and their friends:
- Robosats (custodial escrow)
- Hodlhodl (2-of-3 escrow)
- Peach (2-of-3 escrow)
- Binance P2P (2-of-3 escrow)
- Bisq v1 (either user can send the funds to a custodial escrow, but if neither one does that, the escrow never touches user funds)
- Bisq v2 (no escrow)
(2) In my opinion, bisq2 is the only "true" p2p exchange on the above list. In a true p2p system, the only people who \*can\* touch the money are the buyer and the seller. Whenever there's an escrow, even one that has to be "triggered" (like in bisq v1), it's not "really" p2p because the escrow serves as a middleman: he can collude with one party or the other to steal user funds, and in some models (e.g. robosats) he can just straight up run off with user funds without needing to collude at all.
(3) In bisq2 (the One True P2P exchange), buyers select sellers solely based on their reputation, and they just directly send them the bitcoin \*hoping\* they are as honest as their reputation says they are. What I like about this model is that bisq is not involved in bisq2 at all except as a platform to help buyers discover reputable sellers and communicate with them. There are two things I don't like about this "reputation" model: it's hard to get a good reputation, and it's hard to debug payment failures in this context. I've tried to do about 5 trades on bisq2 (as someone with no reputation) and not a single one went through. Four times, everyone ignored my offers or someone accepted it but then abandoned it immediately. Once, someone accepted my offer, but I could not pay their lightning invoice for some reason, so we mutually canceled the trade.
(4) Just because I opined that an exchange with an escrow "doesn't count" as peer-to-peer doesn't mean that's a bad thing. Of the list of exchanges in number 1, I most frequently use robosats, which, per my analysis, sounds like the "worst" one if considered solely on the metric of "which one is the most p2p." But I use it because there are \*advantages\* to its model: the btc seller doesn't need a reputation to use it (because the escrow is there to ensure he can't cheat, and so the escrow is the trusted third party, not the btc seller) and payment failures are easier to debug because you're always paying one of the coordinators, who tend to be responsive and knowledgeable and can help you figure out how to fix it (it's how they make money, after all).
(5) There are at least two ways to do escrow without a 3rd party. Satoshi Nakamoto outlines one way to do it here: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/169/ Make a 2 of 2 multisig between the btc buyer and the btc seller, and have the btc seller put his btc in that multisig. Then have the btc buyer send the product (fiat money) to the btc seller. When the btc seller receives it, he sends his privkey to the btc buyer, who can now withdraw the money. The advantage of this system is that the buyer has no incentive to "stiff" the seller (by not sending the fiat), because if he does that, he won't get paid. The downside is, if the btc buyer is a troll who just aborts the protocol halfway through the trade, the seller loses his btc and cannot recover it.
(6) There is another way: start out with a 2 of 2 multisig just like above, but instead of having the btc seller fund it by himself, have the buyer and the seller \*both\* put in the \*same amount\* in the \*same transaction\* (i.e. via a coinjoin), and have the btc seller put in a bit "extra" -- like 20% extra. For example, if the btc seller wants $100 in fiat, the multisig would have $220 in it in total -- $120 from the seller and $100 from the buyer. Using this model, the disadvantage mentioned in paragraph number 5 is fixed: the buyer has an incentive now to send the fiat, otherwise he loses the $100 he put in. He only gets his $100 back if the btc seller cosigns to give it to him, which he'll only do once he receives the product. Meanwhile, the seller is \*also\* incentivized properly: he only gets his \*extra\* $20 back if the btc buyer cosigns to give it to him, which he'll only do if the transaction he's signing \*also\* gives him back \*his\* $100 deposit.
(7) The model described in number 6 exists: https://scrow.exchange/ is a website that implements it as an option, though as far as I'm aware, no one uses it. The downsides of this model are: it's capital intensive, e.g. a trade for $100 involves $220 or more. Also, the btc buyer needs to already \*have\* btc to post as a bond, so this cannot be his first time acquiring btc (unless someone helps him make his first deposit). Also, a very rich person who does not care about money can still be a troll; they deposit funds into the multisig alongside their counterparty, then abandon the trade, because they have so much money they don't care if they get it back as long as they cause suffering to their counterparty.
(8) I'd like to see more p2p exchanges, and more exchanges like robosats. I want to continue to spread awareness of ways they can improve -- like the protocols mentioned in numbers 5 and 6 -- and help them implement these protocols. If you run an exchange on the list in number 1 or want to start one, reach out to me, I'd love to help.
it depends on your security parameters. I think bitcoin has about 1 block get orphaned per day; so if you wait for just 1 confirmation, you have a 1/144 chance of it getting orphaned, which is probably fine for many use cases.
Moreover, even if it *does* get orphaned, the *replacement block* is likely to include almost an identical set of transactions as the orphaned block, because most miners use the same template and so they include the same transactions in their blocks.
So even if you're very unlucky and hit the 1 in 144 chance of getting orphaned, you'd have to be in the "unlucky jackpot" to *ALSO* get in a situation where the replacement block doesn't contain your transaction.
(1) Not all p2p trading apps *need* escrow. For example, bisq1 uses an escrow but bisq2 does not. In bisq2, buyers select sellers solely based on their reputation, and they just directly send them the bitcoin *hoping* they are as honest as their reputation says they are. Bisq is not involved in bisq2 at all except as a platform to help buyers discover reputable sellers.
(2) There are at least two ways to do escrow without a 3rd party. Satoshi Nakamoto outlines one way to do it here: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/169/ Make a 2 of 2 multisig between the btc buyer and the btc seller, and have the btc seller put his btc in that multisig. Then have the btc buyer send the product (fiat money) to the btc seller. When the btc seller receives it, he sends his privkey to the btc buyer, who can now withdraw the money. The advantage of this system is that the buyer has no incentive to "stiff" the seller (by not sending the fiat), because if he does that, he won't get paid. The downside is, if the btc buyer is a troll who just aborts the protocol halfway through the trade, the seller loses his btc and cannot recover it.
(3) There is another way: start out with a 2 of 2 multisig just like above, but instead of having the btc seller fund it by himself, have the buyer and the seller *both* put in the amount *in the same transaction* (i.e. via a coinjoin), and have the btc seller put in a bit "extra" (like 20% extra). This fixes the disadvantage of number 2: the buyer has an incentive now to send the fiat, otherwise he loses the amount he put in. He only gets that amount back if the btc seller cosigns to give it to him, which he'll only do once he receives the fiat. Meanwhile, the seller is *also* incentivized properly: he only gets his "extra" deposit back if the btc buyer cosigns to give it to him, which he'll only do if the transaction he's signing *also* gives him back *his* deposit. The downside of this model is, the btc buyer needs to already *have* btc to post as a bond. Another downside is: a very rich person who does not care about money can still be a troll; they deposit funds into the multisig alongside their counterparty, then abandon the trade, because they have so much money they don't care if they get their back as long as they cause suffering to their counterparty.
that's definitely not p2p
in a true p2p system, the only people involved are the buyer and the seller
since peach has a key, it's not p2p
also, it sounds like peach can rug the buyer by *pretending* to be a seller or by *colluding* with a seller
Cool chart:
h/t x.com/TristanBietsch
Oops, I'm doing it again! By saying "It's just not a default behavior" I implicitly denied the very thing I'm trying to clarify: Robosats' model *is* custodial by default. It's just that they try to custody your funds *as briefly as they can* while still offering a decent UX. So if you're using robosats, you're definitely using a custodian, no two ways about it. It's just that if you use it the *intended* way, they only custody your funds for a few hours. Sometimes less.
> At least there is no way to store funds for a prolonged time
There is, and it's pretty easy: the buyer can just give the coordinator an invoice that cannot be paid (e.g. because the node has no channels). I haven't tried this, but as I understand it, if the coordinator cannot pay your invoice, he just credits your robot's account an IOU representing the amount due to you. Then you can try withdrawing again later. So users *can* easily use Robosats as a custodian. It's just not a default behavior.
I suspect it will be easy to do if:
- you don't do rounds frequently (rounds cost money, which means it's harder/costlier to run Ark if you do rounds frequently, and unless you're very generous you have to pass on those costs to your users as fees, which makes it annoying to use)
- your friends and family trust you to prevent doublespends (if they *don't* trust you, they have to settle each payment before considering it "received," and settling costs the operator money, which, again, means more fees for users)
Ark's big tradeoff seems to be this: costs rise if you do rounds often, and if you don't do rounds often, it has the same trust assumptions as a statechain -- i.e. the operator can doublespend payments
ark is awesome
you can just send money
Someone else running ark posted a screenshot of their ark wallet, so I grabbed their pubkey and sent them some sats
https://x.com/matthewvuk2/status/1902450286989373568
then I gave him *my* pubkey so he can return the favor at his leisure
https://x.com/SuperTestnet/status/1902482044371820703
and it's asynchronous!
This is sad
I suspect NostrPix is dead 
> Go on, both of you
Ok :)
The node found by "Bitcoin Anonymous" on the lightning explorer might not even be the recipient's -- it might be a routing node. Some routing nodes (like lnproxy, and some of my software) let users create invoices that use the routing node's pubkey instead of the user's. This helps prevent users from finding out your node's location on the p2p network.