Now that you remind me of the wiki: I remember we discussed this before,
so maybe I was just repeating myself (sorry). It is true the wiki should
be more prominent.
CJP
Op 27-08-18 om 15:19 schreef Christian Decker:
> Corné Plooy via Lightning-dev
> writes:
>>> Aside from that, spontaneous
Corné Plooy via Lightning-dev
writes:
>> Aside from that, spontaneous payments is amongst the most request feature
>> request I get from users and developers.
>
> A while ago I realized that spontaneous payments (without proof of
> payment, mostly for donations only) can be realized quite easily
> Aside from that, spontaneous payments is amongst the most request feature
> request I get from users and developers.
A while ago I realized that spontaneous payments (without proof of
payment, mostly for donations only) can be realized quite easily if the
payer generates the preimage and
> #1 lets us leave out double-funded channels. #2 and #3 lets us leave out
> splice.
> For myself, I would rather leave out AMP and double-funding and splicing
> than remove ZKCP.
It isn't one or the other. ZKCPs are compatible with various flavors of AMP.
All of these technologies can be
> Was referring to losing proof-of-payment; that's vital in a system without
> intermediaries. We have to decide what the lesser evil is.
As is now, we don't have a proper proof of payment. We have a "proof that
someone paid". A proper proof of payment would be: "proof that bob paid
carol".
Good morning all,
> > What's the nasty compromise?
> >
> > Let's also not underestimate how big of an update switching to dlog based
> >
> > HTLCs will be.
>
> Was referring to losing proof-of-payment; that's vital in a system
>
> without intermediaries. We have to decide what the lesser evil
Olaoluwa Osuntokun writes:
> What's the nasty compromise?
>
> Let's also not underestimate how big of an update switching to dlog based
> HTLCs will be.
Was referring to losing proof-of-payment; that's vital in a system
without intermediaries. We have to decide what the lesser evil is.
And
What's the nasty compromise?
Let's also not underestimate how big of an update switching to dlog based
HTLCs will be.
On Wed, Jul 4, 2018, 4:21 PM Rusty Russell wrote:
> Christian Decker writes:
>
> > ZmnSCPxj via Lightning-dev
> writes:
> >> For myself, I think splice is less priority than
Christian Decker writes:
> ZmnSCPxj via Lightning-dev writes:
>> For myself, I think splice is less priority than AMP. But I prefer an
>> AMP which retains proper ZKCP (i.e. receipt of preimage at payer
>> implies receipt of payment at payee, to facilitate trustless
>> on-to-offchain and
ZmnSCPxj via Lightning-dev
writes:
> For myself, I think, for old nodes, it should just appear as a
> "normal" close followed by a "normal" open.
That's exactly what they should look like, since the channel is being
closed with the existing protocol and opened (possibly with a slightly
different
I'm delighted someone is fleshing this out!
Splice-out is easy, splice-in is harder.
Note that there are two ways:
1. Broadcast a spend which joins with one or more random outputs and
then maintain both the old and new channels (ie. both sets of
signatures) until it confirms deeply
Good morning Laolu,
>> but even though it seems technically straight forward t
>
> Well the full async implementation may be a bit involved, depending on the
> architecture of the implementation (see the second point below).
>
> In the abstract, I'd say a splicing proposal should include the
12 matches
Mail list logo
