<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div>Hi everyone,</div><div><br></div><div>I think LN is a great idea and would like to add it to my Bitcoin wallet. I've been thinking for some time now about how LN could work for an end users (ideally dealing with it should be less frustrating than dealing with Bitcoin itself).</div><div><br></div><div>As far as I understand a payment sender needs to obtain at least three "core" pieces of data before he can start interacting with LN (plus maybe some metadata):</div><div><br></div><div>1. Required hash of R-value.</div><div>2. Required list of "full node" URL's where receiver currently has open channels.</div><div>3. Required list of receiver ID's for each "full node" (so "full node" will know whom to ask for R-value).</div><div>4. Optional but sometimes desirable metadata like name, picture, address etc.</div><div><br></div><div>And further requirements:</div><div><br></div><div>- "Lightning address" and QR-code approach won't work as R-value should be unique. Ideally no piece of "core" data should be easily accessible as text or QR to avoid confusion.</div><div><br></div><div>- "core" data sould come directly from receiver's device, either via internet or locally wia bluetooth, WiFiP2P, NFC, etc.</div><div><br></div><div>- Sender needs a way to verify that receiver is who he says he is which means resistance to MITM and identity theft plus some kind of "name authority" to validate metadata.</div><div><br></div><div>Taking all the above into account it seems to me that:</div><div><br></div><div>1. LN users should be able to generate stable identites on their devices. EC25519 keys seem a good fit to me because of their small size and applicability for both encryption and signing.</div><div><br></div><div>2. There has to be a service parallel to LN that can transfer "core" data in encrypted form (easy because identities are pubKeys), perhaps store requests for some time if receiver's device is offline, optionally act as third-party watcher for broadcasted commitment transactions and, finally, act as "name authority" for users who supplied some metadata along with their public keys.</div><div><br></div><div>Does all this make any sense or am I way off somewhere for some reason?</div><div>Please let me know.</div> </div></body>
</html>