Re: [Lightning-dev] BOLT11 In the World of Scriptless Scripts

2018-11-04 Thread ZmnSCPxj via Lightning-dev
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

Re: [Lightning-dev] BOLT11 In the World of Scriptless Scripts

2018-11-04 Thread Rusty Russell
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

Re: [Lightning-dev] Proposal for rendez-vous routing

2018-11-04 Thread ZmnSCPxj via Lightning-dev
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

Re: [Lightning-dev] BOLT11 In the World of Scriptless Scripts

2018-11-04 Thread Anthony Towns
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

Re: [Lightning-dev] BOLT11 In the World of Scriptless Scripts

2018-11-04 Thread Anthony Towns
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

Re: [Lightning-dev] BOLT11 In the World of Scriptless Scripts

2018-11-04 Thread Rusty Russell
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

Re: [Lightning-dev] Proposal for rendez-vous routing

2018-11-04 Thread Rusty Russell
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

Re: [Lightning-dev] Proposal for updateable / revokable proofs of payment

2018-11-04 Thread ZmnSCPxj via Lightning-dev
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",

Re: [Lightning-dev] BOLT11 In the World of Scriptless Scripts

2018-11-04 Thread ZmnSCPxj via Lightning-dev
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

[Lightning-dev] Proposal for updateable / revokable proofs of payment

2018-11-04 Thread CJP
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

Re: [Lightning-dev] Proposal for rendez-vous routing

2018-11-04 Thread CJP
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

Re: [Lightning-dev] Proposal for "local" channel announcements.

2018-11-04 Thread ZmnSCPxj via Lightning-dev
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

Re: [Lightning-dev] Proposal for rendez-vous routing

2018-11-04 Thread ZmnSCPxj via Lightning-dev
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 powerful participant in the Lightning > network starts enforcing KyC

Re: [Lightning-dev] BOLT11 In the World of Scriptless Scripts

2018-11-04 Thread ZmnSCPxj via Lightning-dev
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? > > > > > > >

[Lightning-dev] Proposal for rendez-vous routing

2018-11-04 Thread CJP
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