Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Good morning Tyler, > Great points. IsStandard() is something I hadn't considered yet, but I think > miners are incentivized to want Numerifides transactions as a registration > will need a solid miners fee, and "revoked" names will cause escalating fee > wars that the miners can just soak

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Great points. IsStandard() is something I hadn't considered yet, but I think miners are incentivized to want Numerifides transactions as a registration will need a solid miners fee, and "revoked" names will cause escalating fee wars that the miners can just soak up. I think a standard that uses

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Good morning Tyler, > I like the efficiency your method brings and I'm also not that enthused about > bloating the blockchain with "non-financial data", however I do think there's > value in having the data live in the base chain, both from accessibility and > censorship resistance of the data

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Good morning, CLTV < unix epoch is for absolute lock time measured sanely in blocks, while > unix epoch is for absolute lock time measured in that arbitrary human-preferred unit called "seconds". I believe you mean CSV, as that is for relative lock time measured in blocks (but note that it

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

"[]" are placeholders for the appropriate data. I believed that CLTV less than the Unix epoch would be for a relative time lock but admittedly I've never written Bitcoin script so CSV definitely could be the appropriate opcode to be use here for a relative time lock. 52560 was meant to be a year

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Good morning Tyler, Offhand, I am uncertain the first script given in "Technical Proposal" works as a "check proof-of-work" script. Are the "[]" comments? Or are they pushes of actual data embedded in the SCRIPT? It seems to be comments...? OP_CheckLockTimeVerify is absolute time, not

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

I'm working on a proposal called Numerifides. Full working document here: https://github.com/tyzbit/numerifides Highlights: - Committed directly to Bitcoin blockchain - Seems to solve Zooko's triangle (Decentralized, secure and human meaningful) - Can use already existing SPV infrastructure for

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Op 10-04-18 om 20:34 schreef Tyler H: > > I will continue to approach the problem of securely advertising > human-understandable node names, and I hope someday soon I will have a > solution Lightning can use that retains the open, decentralized > properties of the technology and the underlying

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

ZmnSCPxj writes: >> This also allows domain operators to have one or more public nodes, >> but many private ones with channels open to their public nodes to >> better manage their risk. For example, the private nodes could be >> behind a firewall. > > I am not sure how

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Good morning Tyler, > I will continue to approach the problem of securely advertising > human-understandable node names, and I hope someday soon I will have a > solution Lightning can use that retains the open, decentralized properties of > the technology and the underlying blockchains. I

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Christian, ZmnSCPxj et al, Your concerns have been taken seriously, and while this might provide some useful features with regard to opening appropriate channels (and I guess can be implemented outside of spec, if an implementation so wishes), after consideration and some very useful feedback

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Good morning Tyler, > The external party idea is interesting, but I'm fearful that it can't be done > in a way that retains a bare minimum of privacy. No, of course not. "Private" channels are privacy sieves and should not be used by privacy-conscious entities. Since the channel is never

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Good morning Tyler, > This is not the intention. This BOLT _does not_ replace bootstrapping seed > functionality, now or ever. A client can supplement her view of the network > by getting the graph from well-known nodes if she wishes, but no more. To do > otherwise _would_ centralize the

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

> Connect is not the same as make a channel with. Connect simply lets you access gossip information. So the hard-coded node is not privileged: it simply relays gossip information to the wallet, equivalent to getting an entire map of the network as visible from that node. The plan is that you

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Christian, I hope the additional clarification in the RFC makes clear that BOLT 10 takes precedence for bootstrapping and autopilot functionality. To summarize the intention of this BOLT: Lightning is authoritative, but DNS can be used to assist in on-boarding (with all of its usefulness AND

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Tyler, thanks for the detailed feedback, I'll try to address some of the issues inline: Tyler H writes: > --Regarding looking up nodes at the time of payments: > > In the future, nodes could negotiate a channel open with a push amount and > provide the TXID or payment hash as

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Christian, I think your points are all valid. I believe the challenge with something like this will be in it's general use and implementation, which is why the RFC doesn't make mention of intended usage past mentioning different nodes for "clothing" or "ebooks" a domain could advertise.

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Hi Tyler, Hi Robert, first of all, welcome to the mailing list, always good to have more people looking and improving the spec. I quickly read through the spec and it is very well written, and it looks good. On a conceptual level, I do however have some issues with the proposal. I don't think

[Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Greetings, A challenge end-users face is connecting to nodes with enough liquidity to pay every merchant, and failing that, finding the merchant node in a reasonably sane way to open a channel to them for payments. As it is now, people find nodes in other people's visualizers, and pass node