Good morninh list,
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Saturday, November 3, 2018 9:37 AM, ZmnSCPxj wrote:
> Good morning Rusty, aj, and list,
>
> > > - channel announcements: do you support secp256k1 for hashes or just
> > > sha256?
> > >
> >
> >
Imagine a future where some powerful participant in the Lightning
network starts enforcing KyC requirements on Lightning nodes. It
requires its direct neighbors to reveal their identity or else closes
channels to them. Next, it asks its direct neighbors to reveal the
identity of their direct
Good morning Rusty and aj,
On Monday, November 5, 2018 9:38 AM, Rusty Russell
wrote:
> > Technically speaking, all that AJ in Australia needs to show is that he or
> > she knows, the private key behind the public key that is indicated on the
> > invoice.
> > Before payment, only the payee
Anthony Towns writes:
> FWIW, I don't see reddit as a particularly viable "court"; there's
> no way for reddit to tell who's actually right in a dispute, eg if I
> say blockstream didn't send stickers I paid for, and blockstream says
> they did; ie there's no need for a sock puppet in the above
Good morning Rusty and all,
On reflection, it seems to me that non-public channels have the incentives very
wrong.
1. Non-public channels are intended as a way to keep public maps small. So a
node maintaining a non-public channel provides a service to the rest of the
network by increasing
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:
>
> > Imagine a future where some
ZmnSCPxj writes:
> Good morning Rusty and aj and list,
>
>>
>> > > In the payer-supplied data case, I think 'm' should include a signature
>> > > for a key only the payer knows: this lets them prove they made the
>> > > payment.
>> >
>> > I don't object to that, but I think it's unnecessary; as
On Mon, Nov 05, 2018 at 01:05:17AM +, ZmnSCPxj via Lightning-dev wrote:
> > And it just doesn't work unless you give over uniquely identifying
> > information. AJ posts to r/bitcoin demonstrating payment, demanding his
> > goods. Sock puppet says "No, I'm the AJ in Australia" and cut & pastes
On Sun, Nov 04, 2018 at 08:04:20PM +1030, Rusty Russell wrote:
> >> > - just send multiple payments with the same hash:
> >> > works with sha256
> >> > privacy not improved much (some intermediary nodes no longer know
> >> > full invoice value)
> >> > can claim partial payments
Good morning Rusty and aj and list,
>
> > > In the payer-supplied data case, I think 'm' should include a signature
> > > for a key only the payer knows: this lets them prove they made the
> > > payment.
> >
> > I don't object to that, but I think it's unnecessary; as long as there
> > was a
Good morning CJP,
It seems to me, naively, that we can encode the description "the obligation in
the invoice whose hash is is nullified", whose meaning then is promoted to
"if payment happens, payee has an obligation to ensure that the obligation in
the invoice whose hash is is nullified",
CJP writes:
>> Looking through BOLT 4, the text assumes inherently that source
>> routing is done, and even has a shared secret between hop and
>> source. However, it may be possible in rendezvous routing to simply
>> provide the blinding key (while hiding everything beyond the first
>> hop on
Right now, the only defined semantics of the description field in
BOLT11 is that it SHOULD be "a complete description of the purpose of
the payment". I think this is a bit vague; maybe this is deliberate?
Anyway, you may also think of a BOLT11 payment request as an option
contract. If the payment
Good morning Rusty,
On Monday, November 5, 2018 8:26 AM, Rusty Russell
wrote:
> CJP c...@ultimatestunts.nl writes:
>
> > > Looking through BOLT 4, the text assumes inherently that source
> > > routing is done, and even has a shared secret between hop and
> > > source. However, it may be
14 matches
Mail list logo
