Cashapp has to be the easiest way to get a normie to pay an invoice which is great for onboarding, but...
I've heard from other lightning folks that cashapp won't pay their node and now it' won't pay mine. Just a small development node, that I've been making repeated 10-50 sat payments to over the past two weeks, and now I'm just getting a 'Payment failed' message.
Anyone know what the criteria to get blacklisted or whitelisted, is it a fraud detection algo? I noticed SN invoices are payable with cashapp.
Did you try using lnproxy? This is one of the reasons it exists
reply
Funny enough I have that tab open, and just reading about when I came back here to check for replies. Thanks for the advice! I'll report back here with what I find.
reply
Hmm, cashapp gets a different error when paying an lnbits or thunderhub generated invoice wrapped with lnproxy, error code: "Invoice missing valid amount...Please create or requests a new invoice with an amount of at least 1 satoshi". For reference, phoenix and strike do pay proxy wrapped invoice.
reply
I have no idea what's going on in CashApp's case, but it definitely reminds me of Bottlepay's behaviour. The app used to require users to "validate the node is theirs by signing a message" when trying to withdraw to one's own node. It would let you pay invoices to services without any problem.
I don't know exactly how it worked, but an easy way to trick this system was to use a BTCPay Server linked to one's node. Bottlepay would pay the invoice without batting an eye, even if it was paying the exact same node.
Re CashApp, could it just be that liquidity is exhausted between them and you?
reply
Interesting,...And yes the inbound capacity seems fine, especially for these small 10-50 sat payments. I can pay other wallets with cashapp, and I can pay my node with other wallets.
I was going to ask about workarounds, and sounds like BTCPay Server is a good one. I was also wondering about lightning addresses, and whether you could create arbitrarily many of them to always generate a new recipient for each invoice or something like that?
reply
I was also wondering about lightning addresses, and whether you could create arbitrarily many of them to always generate a new recipient for each invoice or something like that?
I'm considering making a service that does exactly this. You could make unlimited lightning addresses that all pointed to a single address. The invoices generated by any of the aliases, or the main address, would be identical.
Not sure if this would help in your case though, if they are blacklisting something in the invoice like your nodes public key (since you aren't using a custodial service where all the public keys are the same), it wouldn't help.
More here #223185
reply
Love this, I'm going to look into it more, and feel this is definitely needed.
reply
I would be surprised if Cash app was black listing nodes. There are many reasons why a lightning payment might fail. Have you opened a support ticket? I would.
If it were me I would use something like Phoenix to accept payments from cash app and then move to your node.
reply
Yes, I have phoenix and use it as my primary.
One reason I sometimes use CashApp is sometimes phoenix gets stuck "Connecting to Electrum" and can't make payments for several minutes.
But the larger point is I'd love regular old folks to pay me via CashApp instead of instructing them to take an extra step with a secondary wallet. Beyond the friction of extra steps, if the user wants only like $5 worth of services, Phoenix is also going to take a good chuck of say that for channel opening fee, which will seem predatory to a first time lightning user.
reply
I think people are aware but if not there is a risk for lightning that only blessed nodes can be paid which could create a fracture between let's say KYCd services and non. Not saying that's happened here because it would be pretty obvious and crippling for CashApp but it's something to be aware of.
reply
Agree, lightning looks like it could have the "Mastadon problem" where it is decentralized (like Mastodon the app) but that just makes interop across all the users more difficult because every federation is putting different outbound/inbound restrictions on nodes they deem baddd, m'kay?
reply
why using cashapp to test your node when you can use other wallets?
reply
For a.) reliability and b.) QA 'ing the potential to onboard non-lightning people to my app, see reply below to kepford.
reply
I think cash app is having node operation failures
reply
Nice.. god job
reply