Semaphore.finance now has lightning support \ stacker news ~bitcoin

pull down to refresh

Semaphore.finance now has lightning support

1885 sats \ 3 comments \ @supertestnet 17 Jan bitcoin freebie

I just added lightning network support to Semaphore. Semaphore fundraisers now have feature parity with Geyser fundraisers, except Semaphore doesn't have any fees. (Geyser charges a 2% fee on all lightning contributions.)

Try it out! https://semaphore.finance/

Note that making lightning payments reversible would require additional trust assumptions, which I don't want to introduce. Consequently, contributors only see the "pay with lightning" option if they choose to do an irreversible pledge.

Also, I don't know how to automatically & reliably detect lightning payments without running some sort of middleman server, so I have the contributor just "tell the site" they made the payment by pasting their preimage. Semaphore then verifies that the preimage matches what the recipient's invoice expects and only counts the contribution toward the goal if the preimage matches.

(Technically I guess that means Semaphore doesn't quite have feature parity with Geyser. Geyser does automatically detect lightning payments, so you don't have to copy/paste a preimage to prove you did it. They are able to autodetect them because they are running a middleman server, which they do in order to take their cut.)

view all related items

110 sats \ 2 replies \ @k00b 17 Jan

Also, I don't know how to automatically detect lightning payments without running some sort of middleman server, so I have the contributor just "tell the site" they made the payment by pasting their preimage.

I know Super knows this because we've talked about it before, but the only way to do this is to be on the payment route. One of my biggest pie in the sky wishes in service of Lightning apps is atomic payments to multiple recipients that somehow doesn't rely on recipients being along the route.

Naively, recipients would have to coordinate and possibly even have a contract between each other, which eventually begins to look like a lightning channel (surprise), but maybe there's some other clever way.

1010 sats \ 1 reply \ @supertestnet OP 17 Jan freebie

the only way to do this is to be on the payment route

I'm not willing to say certainly that it is the "only" way. But it is one way, and I think it's pretty neat, and possibly good enough, if some elbow grease is put into making it work well

[I want] atomic payments to multiple recipients that somehow [don't] rely on recipients being along the route

Correct me if I'm wrong but I don't think you are inherently opposed to each recipient being on the route, I suspect you just see that as bringing additional challenges that you don't know how to overcome. Some of those challenges include:

cell phone users are probably not along the route because they are probably not running routing nodes
I think you could solve that by having each cell phone user "temporarily" act as a routing node but then you face the following two additional problems
a cell phone user probably doesn't have enough inbound and outbound liquidity to forward the payment to the next guy
if a cell phone is part of the route, it would be just awful if they were offline when you're trying to do the payment

I think with some elbow grease those challenges are overcome-able. Just-in-time-routing is pretty magical if someone is online, and if they are definitely offline, zaplocker demonstrates that an intermediary can atomically hold a payment for someone til they get online to collect it, without taking custody.

Someday I'd like to see how close LN can get to "one sender, many recipients" using those tools. The sender's device could figure out which parties are online and construct a route "though" them using just-in-time routing tools, if necesary, to ensure everyone has enough inbound and outbound capacity to do their part, and if someone is definitely offline, it could send their payment to a zaplocker server as a kind of docking station, knowing that the server won't be able to keep the funds, but they'll either return to the sender or go to the recipient when they next get online.

0 sats \ 0 replies \ @k00b 17 Jan

I don't think you are inherently opposed

Correct, it's just inconvenient.

I suspect you just see that as bringing additional challenges that you don't know how to overcome.

At least for the challenges I'm immediately concerned with, I know how to overcome them.¹ However atomic splits done this way require each intermediate recipient have:

incoming liquidity equivalent to
- their share of the payment
- the shares of recipients later in the route
outgoing liquidity equivalent to
- the payment shares of recipients later in the route

In addition to being reliably online.

I think about this problem in the context of taking an SN-like sybil fee, ie a third party verifying a payment happened and taking a fee without additional interaction from the sender and receiver. The third party can do this by "wrapping" a bolt11 from the destination in a hold invoice paid to itself. This would work for multiple third parties too with each wrapping the bolt11 of one of the other third parties. ↩

Footnotes