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
> 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
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
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
Hi all,
On 9 April 2018 at 11:47, Corné Plooy via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:
>
> Is this really only about reducing the size of QR codes? How many
> percent reduction do you think you can accomplish with your approach? I
> think, when it comes to reducing QR
Why put everything in bech32? It hurts readability. The only possible
advantage is that data inside the bech32 blob can be digitally signed in
a convenient way. If you don't need that, I'd keep your data ourside the
bech32 blob, in a (expert-)human-readable format.
Why not follow a regular URL