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 meta-data
included in the second bet tx.
it 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 issue before
sively 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
problems in a clean and elegant way. I p
d 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
possible.
CJP
(*) not necessarily in latency: the low
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 theory, the
ies. 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, naively, tha
ment 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
___
Lightning-dev mail
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:
>
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://lists.linuxfo
(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 transactions.
regards,
CJP
_
nnecessary 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 worth
11 matches
Mail list logo
