<unnamed>

Public Key

npub1d7e068ud72v0au6xf53qvek44eccfhlgnhzuclf6za6hnxrvx89sc93exj

Profile Code

nprofile1qqsxlvhar7xl9x877dry6gsxvm26uuvyml5fm3wv05apwatenpkrrjcprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hszrthwden5te0dehhxtnvdakqvgjf9h

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-09 15:05:03 CEST

- reply

📅 Original date posted:2022-01-18
📝 Original message:
Hey Christian,
I noticed you are doing RPC stuff... I'm looking to do RPC over
lightning itself. I started a C library called lnsocket[1], scrounged
from clightning parts, so that I can send messages from iOS to control
my lightning node.
I've got to the point with lnsocket where I can send TLVs to my node,
and now I'm starting to think about what format the RPC commands should
be.
I noticed the commando c-lightning plugin just uses the JSON-RPC
payload, but perhaps something more compact and rpc-friendly like grpc
would be better... which is why this cln-grpc PR peaked my curiosity.
I think the end goal of an RPC bolt would be super powerful, so that
lnsocket could talk to any lightning node, but that could be further
down the line. Choosing the right data format seemed like an important
step in that direction. Would love to hear your thoughts on this!
I've cc'd clightning/lightning-dev as well to see if anyone else is
working on this or thinking about this stuff right now.
Cheers,
Will
[1] http://git.jb55.com/lnsocket
On Tue, Jan 18, 2022 at 06:01:46AM -0800, Christian Decker wrote:
>This is the final PR in the cln-* series. It uses all the primitives we
>built in the previous 3 PRs and uses them to expose the JSON-RPC over
>grpc, with mTLS authentication builtin. You can view, comment on, or
>merge this pull request online at:
>
> https://github.com/ElementsProject/lightning/pull/5013
>
>-- Commit Summary --
>
> * cln-grpc-plugin: Add scaffolding for the cln-grpc-plugin
> * make: Add a hook for us to depend on generated files for tests
> * make: Generate grpc bindings if we want to test with rust enabled

2023-06-09 15:04:50 CEST

- reply

📅 Original date posted:2021-12-15
📝 Original message:
On Wed, Dec 15, 2021 at 01:59:49PM -0800, William Casarin wrote:
>Hey Ronan,
>
>On Wed, Dec 15, 2021 at 05:33:51PM +0000, Ronan McGovern wrote:
>>If not, what would be required to develop this?
>>* A protocol change?
>>* Could it be built with the current protocol (I see an app on LN Bits to
>>split but it doesn't seem to work).
>
>This is typically done at the application level. The fountain podcasting
>app works this way and it seems to work okish.
The tricky part is what to do when the payment partially fails. Perhaps
you keep trying with exponential backoff until the payment completes for
all parties. If this was handled at the protocol level, would you fail
the entire transaction if one of the channels failed? This is the kind
of business logic that would be tricky when designing a protocol-level
solution to this.
I think it's reasonable to handle this at the application level for now,
but perhaps some standard protocols might be useful in the future.
Cheers,
Will

2023-06-09 15:04:50 CEST

- reply

📅 Original date posted:2021-12-15
📝 Original message:
Hey Ronan,
On Wed, Dec 15, 2021 at 05:33:51PM +0000, Ronan McGovern wrote:
>Hi folks, I'm Ronan - based in Dublin and building Trelis.com (simple
>payment links to accept Lightning).
>
>I'm wondering if there is a way to create an invoice that splits the
>payment to two lightning addresses?
>
>If not, what would be required to develop this?
>* A protocol change?
>* Could it be built with the current protocol (I see an app on LN Bits to
>split but it doesn't seem to work).
This is typically done at the application level. The fountain podcasting
app works this way and it seems to work okish.

2023-06-09 15:04:50 CEST

- reply

📅 Original date posted:2021-12-16
📝 Original message:
Hey Christian,
On Thu, Dec 16, 2021 at 11:27:33AM +0100, Christian Decker wrote:
>This is quite a common request, and we've used a solution I like to call
>the "Poor man's rendez-vous". It basically routes a payment through all
>the parties that are to be paid, with the last one accepting the payment
>for all participants.
>
>The payment is atomic, once the circuit is set up no participant can
>cheat the others and it's seamless from the payer's perspective.
>
>Let's say user `A` wants to pay `B` and `C` atomically. `B` gets 10ksat
>and `C` gets 90ksat out of a total of 100ksat:
>
> 1) `C` creates an invoice with payment hash `H` for 90ksat and sends it
> to `B`
> 2) `B` creates an invoice with payment hash `H` (same as the first
> invoice, but `B` doesn't know the preimage) for 100ksat (maybe plus
> a tiny bit for routing fees between `B` and `C`).
> 3) `A` receives an invoice which appears to be from `B` for the
> expected total of 100ksat.
> 4) `A` proceeds to pay the invoice to `B` like normal
> 5) `B` receives the incoming payment, but doesn't have the preimage for
> `H`, so they must forward to `C` if they want to receive their
> share. `B` then proceeds to pay the 90ksat invoice from `C`, which
> reveals the preimage to them, and they can turn around and claim
> the incoming `100ksat` (covering both `B` and `C` share)
>
>It's a poor man's version because it requires creating two invoices and
>`B` sees two payments (100ksat incoming, 90ksat outgoing), but the
>overall outcome is the desired one: either both parties get paid or
>noone gets paid. This can trivially be extended to any number of parties
>(with reduced success probability), and will remain atomic. It also
>doesn't require any changes on the sender side, and only minimal setup
>between the payees. The crux here is that we somehow need to ensure `H`
>is always the same along the entire chain of payments, but with a good
>coordination protocol that should be feasible.
This is very cool, at least for a small number of parties. When I was
working at a record label it was very common to split between 1-5 people
on a given track, being able to atomically payout to individual artist's
lightning nodes would have been super useful at the time (assuming a
world where our artists ran lightning nodes). At some point I was
testing 600-output bitcoin transactions as a payout method, but that
looked like it was going to be economically infeasible sometime in the
future.
Has anyone coded up a 'Poor man's rendez-vous' demo yet? How hard would
it be, could it be done with a clightning plugin perhaps?
Cheers,
Will

2023-06-09 15:00:10 CEST

- reply

📅 Original date posted:2020-05-14
📝 Original message:
Orfeas Stefanos Thyfronitis Litos <o.thyfronitis at ed.ac.uk> writes:
> ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes:
>> If everyone runs such a privately-owned server, on the other hand, this
>> is not so different from having a Lightning node you run at your home
>> that has a fullnode as well and which you access via a remote control
>> mobile device, and it is the inconvenience of having such a server at
>> your home that prevents this in the first place.
>
> Private full nodes serving headers to a handful of weak devices have
> been mentioned many times as a good solution against all sorts of
> problems in a future full of LN + SPV nodes. I agree. It should be
> therefore a top priority to make the UX of connecting my mobile LN
> client to my home full node extremely easy, so that centralised
> services can't improve much on that step. Especially if I already run
> a full node.
>
> Could someone briefly describe how this UX looks currently? And if
> it's not as seamless as it could, what blockers are there?
The UX for this doesn't have to be complicated. All you need is a node
provider like FullyNoded, Casa, etc. My setup at home is a desktop with:
- bitcoind
- clightning
- zerotier (or tailscale) (private vpn for connecting to your node from anywhere)
- sparkwallet (clightning webui) bound to a zerotier interface
So as long as you have a node that runs these bits of software, perhaps
assumeutxo to speed up IBD, and a QR-code automagic setup, then UX
should be pretty smooth. You would still need to deal with lightning
backups and liquidity issues, but we just need to do more work on the
software side to make that experience nicer.
Cheers,
Will
--
https://jb55.com

2023-06-09 14:48:35 CEST

- reply

📅 Original date posted:2018-01-16
📝 Original message:
Benjamin Mord <ben at mord.io> writes:
> [..]
> why not allow negative fees to incent unwinding, in scenarios where nodes
> consider that cheaper than on-chain rebalancing?
This was brought up before here [1]:
Rusty Russell <rusty at rustcorp.com.au> writes:
>> Edward Marynarz <edziumarynarz at gmail.com> writes:
>> Another trivial question: can the fee be negative? It might help with some
>> channel rebalancing.
>In my original implementation, they could be. However, that turns out
>to be a very strange idea, and complicates routing.
[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-December/000827.html
Cheers,
--
https://jb55.com