Re: [Lightning-dev] An Argument For Single-Asset Lightning Network

2019-01-02 Thread CJP
ZmnSCPxj schreef op wo 02-01-2019 om 13:02 [+]: > I wonder however if this is a "small enough" hole that leaving it is > an acknowledged security vulnerability may be better than replacing > it with a trusted third party. > One may compare with the SSH "trust the first pubkey, verify the >

Re: [Lightning-dev] Quick analysis of channel_update data

2019-01-02 Thread Fabrice Drouin
On Wed, 2 Jan 2019 at 18:26, Christian Decker wrote: > > For the ones that flap with a period that is long enough for the > disabling and enabling updates being flushed, we are presented with a > tradeoff. IIRC we (c-lightning) currently hold back disabling > `channel_update`s until someone

Re: [Lightning-dev] Quick analysis of channel_update data

2019-01-02 Thread Christian Decker
Hi Fabrice, happy new year to you too :-) Thanks for taking the time to collect that information. It's very much in line with what we were expecting in that most of the updates come from flapping channels. Your second observation that some updates only change the timestamp is likely due to the

Re: [Lightning-dev] An Argument For Single-Asset Lightning Network

2019-01-02 Thread CJP
Regarding this subject, I believe I should disclose that my current employer, Bitonic, operates an evil, centralized, trusted exchange, and that the ideas discussed in this thread may be related to concepts that are actually being developed by my employer. So, am I biased? Who knows? Does it

Re: [Lightning-dev] An Argument For Single-Asset Lightning Network

2019-01-02 Thread ZmnSCPxj via Lightning-dev
Good morning CJP, > This, and the rest of your proposal, sounds like a lot of trouble, > while it hardly solves anything. > > RM can have its node surrounded by other nodes also controlled by > itself. So it is possible that RM controls all nodes that can possibly > fulfill the 'G' role, and

Re: [Lightning-dev] visual identification of payee node id

2019-01-02 Thread Maximillian George
Why not a confirmation phrase of a few words? This should be easier to implement and fit into a pre-existing design programme. Given a pool of enough words this would surely be as reliable as an identicon, no? Best regards, Max On 29 Dec 2018, 17:23 +0100, William Casarin , wrote: > Pavol

Re: [Lightning-dev] An Argument For Single-Asset Lightning Network

2019-01-02 Thread ZmnSCPxj via Lightning-dev
Good morning Lloyd, > Therefore, the ideal abstract functionality we want is: > > 1. *Make Offer* Alice makes an offer to Bob to trade `A` for `B` > 2. *Take Offer* Bob can take the offer (if Alice hasn't already cancelled it) > and get `A` in exchange for `B`. > 3. *Cancel Offer* If Bob hasn't

Re: [Lightning-dev] visual identification of payee node id

2019-01-02 Thread ZmnSCPxj via Lightning-dev
Good morning Eugene, > > how about using of Chernoff Faces to identify node’s public key? Since humans > are best fit to recognize small changes in faces and to remember them.  Why do humans have this circuitry? Such strange objects... One could wonder about sentients without such circuitry.

[Lightning-dev] Quick analysis of channel_update data

2019-01-02 Thread Fabrice Drouin
Hello All, and Happy New Year! To understand why there is a steady stream of channel updates, even when fee parameters don't seem to actually change, I made hourly backups of the routing table of one of our nodes, and compared these routing tables to see what exactly was being modified. It turns

Re: [Lightning-dev] visual identification of payee node id

2019-01-02 Thread Eugene via Lightning-dev
Hi, how about using of Chernoff Faces to identify node’s public key? Since humans are best fit to recognize small changes in faces and to remember them. To achieve avalanche effect from changing a private key to produce much different face, one can just plug node’s public key into a

Re: [Lightning-dev] An Argument For Single-Asset Lightning Network

2019-01-02 Thread ZmnSCPxj via Lightning-dev
Good morning CJP, > > - No exchange: unattractive, because there is significant demand for > this. > > - Regular Lightning-based or other HTLC-like atomic swap: unattractive, > because of the exploitable "American Call Option" nature (as we both > described). May only function