[Lightning-dev] How to use LN

[v e]

Hi,

I am building merchant app and consumer wallet app using
https://bitcoinj.github.io APIs for wallet creation. Now I want to use LN
built by your team. I am looking at this API
https://github.com/ElementsProject/lightning-charge

and have few questions:

* Do i need to run bitcoin core node?
* I see invoice apis, I assume that the invoice is generated at the
merchant wallet app. How do i tie the merchant wallet to the invoice?

* similarly how do i send coins from consumer wallet to the created invoice?

Sorry I am very new to this and apologize my assumptions.

Any help is highly appreciated.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] negative fees for HTLC relay

[Benjamin Mord]

Although lightning and cryptocurrency is new, the idea of a distribution
network created from links with negotiated fees and with limited
unidirectional capacity that can be corrected via rebalancing, is not new.
In fact there are several very large and mature markets around the world
that we can study which illustrate what people have found to work well in
such contexts, and one class of such markets is wholesale electricity
distribution, such as PJM:
http://www.pjm.com/about-pjm/who-we-are.aspx

When Will Yager mentioned FTRs, he was referring to a specific financial
instrument traded on the PJM, for the purpose of managing load on
transmission lines. Much as with lightning payment channels, power flows in
one direction on a line can be canceled with power flows in the opposite
direction, and so FTR prices are therefore allowed to go negative on the
PJM exchanges for the same reasons as discussed in this thread. If this has
worked for them for some decades, I'm not sure why it wouldn't work for us
also.

In full disclosure, I should point out that this is not the same thing as
electricity transmission. Although they do have counterflow cancellation in
common, payment channel balance is still more analogous to energy than
power, whereas transmission capacity limits are in power and not energy.
Time scales are long enough for manual intervention in PJM negotiations,
whereas timescales necessitate a high degree of automation in lightning
negotiation, as another difference. And there are other differences, and
some might matter.

At at a technical level, I see no complexity at all in allowing fees to go
negative. What is hard about allowing signed versus unsigned integers in
the protocol, and even passing them along? Perhaps there is complexity in a
routing algorithm which attempts to take full advantage of negative fees,
and so perhaps implementations will prefer in the near term to pretend
negative fees are actually zero - but such implementations can easily pass
along info about negative fees even when they themselves choose not to
fully avail themselves of the resulting opportunities. (At worst, some
recipients might receive an unexpected tip! There are worse fates in life.)

As relates to lightning's design goals, I applaud simplifying assumptions
in the early implementations, as a matter of triage - but I would still
discourage premature neutering of underlying protocol expressiveness, since
the resulting limitations can then linger or even come to motivate harmful
or risky forks down the road. Passingly along signed instead of unsigned
ints is easy enough, and we can just cast to unsigned internally, wherever
that may be our local preference.

Incidentally, if anyone is interested in exploring specific application of
lightning to the electricity markets, please contact me offline at
b...@mord.io, as it happens I am attempting to organize such an effort.
While I see opportunity here for collaborative and complimentary work that
could in turn boost lightning adoption, I want to be careful also not to
distract the lightning project from its already ambitious and laudable
mission. Lightning must beware scope creep of a harmful sort, and I'll try
to be disciplined in not encouraging it. We should still walk before we run.


On Thu, Jan 18, 2018 at 12:17 PM, Christian Decker <
decker.christ...@gmail.com> wrote:

> Mark Friedenbach  writes:
>
> > It is not the case that all instances where you might have negative
> > fees would have loops.
>
> If we don't have a cycle we can hardly talk about rebalancing
> channels. At that point you're paying for someone else's payment to go
> through your channel, and I'm unclear what the motivation for that might
> be. Anyway, this is still possible by communicating this out of band
> with the payment creator, and should not be baked into the gossip
> protocol itself, in my opinion. It's obscure enough to not be worth the
> extra effort.
>
> > One instance where you want this feature is when the network becomes
> > too weighted in one side of the graph.
>
> There is little you can do to prevent this: if we have a network with a
> small cut, with a source and sink on opposite sides of that cut, no
> amount of voluntary sacrifice from the nodes along the cut will have a
> lasting effect. The better solution would be to change the topology of
> the network to remove the cut, or balance traffic over it, e.g., moving
> a sink to the other side of the cut.
>
> > Another is when the other side is a non-routable endpoint. In both
> > cases would be useful to signal to others that you were willing to pay
> > to rebalance, and this hand wavy argument about loops doesn’t seem to
> > apply.
>
> I'm not sure I understand what you mean with non-routable endpoint, so
> correct me if I'm wrong. I'm assuming that non-routable endpoint is a
> non-publicly announced node in the network? In that case no fee tricks
> will ever get people to route over it, since they 

Re: [Lightning-dev] negative fees for HTLC relay

[Christian Decker]

Mark Friedenbach  writes:

> It is not the case that all instances where you might have negative
> fees would have loops.

If we don't have a cycle we can hardly talk about rebalancing
channels. At that point you're paying for someone else's payment to go
through your channel, and I'm unclear what the motivation for that might
be. Anyway, this is still possible by communicating this out of band
with the payment creator, and should not be baked into the gossip
protocol itself, in my opinion. It's obscure enough to not be worth the
extra effort.

> One instance where you want this feature is when the network becomes
> too weighted in one side of the graph.

There is little you can do to prevent this: if we have a network with a
small cut, with a source and sink on opposite sides of that cut, no
amount of voluntary sacrifice from the nodes along the cut will have a
lasting effect. The better solution would be to change the topology of
the network to remove the cut, or balance traffic over it, e.g., moving
a sink to the other side of the cut.

> Another is when the other side is a non-routable endpoint. In both
> cases would be useful to signal to others that you were willing to pay
> to rebalance, and this hand wavy argument about loops doesn’t seem to
> apply.

I'm not sure I understand what you mean with non-routable endpoint, so
correct me if I'm wrong. I'm assuming that non-routable endpoint is a
non-publicly announced node in the network? In that case no fee tricks
will ever get people to route over it, since they can't even construct
the onion to talk to it. Notice that the payment requests allow for
recipients of payments to get paid by explicitly including the necessary
information to construct the onion to talk to that node.

Not trying to be dismissive here, and I might be getting this wrong, so
let me know if I did and what use-cases you had in mind :-)

Cheers,
Christian
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] BOLTs and meaning of "MUST" in potentially adversarial contexts

[7riw77]

> benefit. Use of MUST (in RFC 2119 sense) invites lazy thought in the protocol
> design itself, where details need not be sold as beneficial to individuals. We
> should say, there is no RFC
> 2119 MUST - there is only self interest.

I think you are misreading the intent behind RFC2119 a bit... The idea has 
always been that implementations MUST follow MUSTs -- but who is this enforced 
by? Vendors? They've never cared. Neither the IETF nor the Internet Society run 
jails that I'm aware of, nor is there any nation state who offers their jails 
up for folks who don't follow a MUST. The situation in the routing world is the 
same as it is in the cryptocurrency world -- you can make real money by not 
following the rules (there seems to be this general idea that the 'net is 
"free" -- which is wrong), and the only enforcement on the rules is the 
community at large. The correct interpretation of RFC2119 MUST is this:

- If I write an implementation, and you send me something you shouldn't 
(because it's MUST), then I simply refuse to interoperate with your 
implementation. This (hopefully) harms the implementation financially.
- If I run a network, and you produce gear that doesn't follow a MUST, then I 
won't buy your gear.

Note that private implementations are not bound by these rules -- 
implementations that are intentionally not designed to interoperate with other 
implementations. If such implementations become large enough to care, then they 
go through the standardization process so everyone has a look before it becomes 
an issue within the community.

 /r 
 

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev