cessary to enforce
HTLCs with scripts, because their amounts are so small(*). If one
micro-payment fails, that just makes them learn that a certain channel
is unreliable, and they'll send further payments (and even the remaining
part of the same payment) through a different route.
CJP
(*) not
As far as I can see, this is an exceptional (but
important) case, but during normal operation, peers should be free to
choose the fee for their own commit tx.
You'd have to deal with any follow-up transactions as well: changing a
fee changes the txID, so you need to update follow-up transaction
receiving node that this is in fact intended as a payment, and you may
be able to include a small message.
CJP
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
ut simply having nodes on each
network if you need to, and simply move funds on-chain between your
nodes whenever needed. That will require on-chain mixing though.
CJP
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lis
ZmnSCPxj schreef op zo 04-11-2018 om 14:34 [+]:
> Good morning CJP,
>
> I believe this is a desirable feature, although...
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Sunday, November 4, 2018 2:26 PM, CJP
> wrote:
>
yment and a payment channel.
A potential issue is that, theoretically, the "contract update chain"
can fork. The simple solution is "don't do that": either party can stop
it from happening by not signing the forking update.
CJP
__
n two parties. I'm sure
there are complex business arrangements that have a need for this, but
I think we can always develop that later. Let's first tackle this
relatively simple case.
CJP
ZmnSCPxj schreef op ma 05-11-2018 om 01:20 [+]:
> Good morning CJP,
>
> It seems to me,
t if
payer and payee make their part of the route independently, the
combined route can often end up like that. TODO: check if forwarding
nodes are currently cool with such weird forwarding requests.
CJP
Rusty Russell schreef op ma 05-11-2018 om 10:56 [+1030]:
> CJP writes:
> > >
voluntary basis.
CJP
ZmnSCPxj via Lightning-dev schreef op do 27-12-2018 om 05:43 [+]:
> HTLCs as American Call Option, or, How Lightning Currently Cannot
> Work Across Assets, or, An Argument For Single-Asset Lightning
> Network
>
> Introduction
>
>
> In t
n only steal the *exchange
rate change* of funds offered for trade, not the full value.
Now, if an RM can be punished, it would be even better. I was thinking
in the direction of collecting proof of misbehavior, which can then
help make the RM lose its (lucrative!) business, but I doubt this is
pos
the G
nodes, you end up recursively involving every single Lightning node in
trying to solve your problem. Maybe it is possible, but I'd like not to
do that. I like to see the exchange function as a higher layer (layer
3) on top of the Lightning layer, and have each layer solve its own
probl
matter? Can you trust me? Maybe,
but I guess you shouldn't anyway. In my view, words should be
convincing or unconvincing regardless of who speaks them.
CJP
CJP schreef op vr 28-12-2018 om 09:27 [+0100]:
> Hi ZmnSCPxj,
>
> I think we've already addressed this is
ion exists for elliptic curve points;
in that case Bob could calculate SA = PP_b0 - P. Otherwise, Alice could
just tell Bob SA, e.g. as meta-data included in the first bet tx.
Similarly, Alice has to know SB to generate PP_x0; Alice could
calculate SB = PP_b1 - Q, or Bob could tell Alice SB, e.g. as me
13 matches
Mail list logo
