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
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
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
>
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
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
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.
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
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
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
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
10 matches
Mail list logo
