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

[ZmnSCPxj via Lightning-dev]

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 up.  I think a standard that uses mappings 
> in a sane way (and maybe pushdata2/4 won't be allowed if 255 bytes are 
> enough) would be allowable given the benefit it brings of truly 
> decentralized, human-readable trust.

Granted, but using scriptpubkey will require changes to miner software, and 
would require large number of mining pools to support it.  And large numbers of 
mining pools will not support it significantly unless you have already 
demonstrated its usefulness, so you may find bootstrapping less easy.

One thing that can be done would be to publish the command in the witness 
vector and use an intermediate transaction.  This at least lets you use the 
cheaper witness space.

1.  First pay to a P2WSH OP_HASH160  
OP_EQUALVERIFY  OP_CHECKSIG
2.  Spend the above P2WSH, which requires you to provide the witness data 
 
3.  The spend should pay out a value to the P2WSH  
OP_CHECKSEQUENCEVERIFY OP_DROP  OP_CHECKSIG

This puts the extra data into the witness area, which is cheaper, and also 
utilizes P2WSH so that you do not have to convince miners to use Numerifides.  
bitcoin-dev will still cry because it puts non-financial data onchain, but at 
least fewer tears will be shed since it is the witness area.

> I also wonder what the economic incentive might be for every node to store 
> and gossip the Numerifides mappings - sure they want everyone to find them, 
> but who cares about other people? It could be a situation like the current 
> Bitcoin mempool where it's saved on a best-effort basis and is 
> semi-transient, but that makes troubleshooting lookups problematic.

You have an economic incentive to *store* all the Numerifides mappings -- if 
you do not, somebody could fool you with a revoked mapping, or you might not be 
able to locate a mapping you need to use.

Incentive to then *share* mappings could be that peers would try a "tit for 
tat" strategy: they will give you one (or a few) mappings "for free", but if 
you do not give any back, they will stop sharing with you.  So you are 
incentivized to contact multiple peers and try to trade information from one 
with information from another.  But that requires a durable identity from you, 
which may be undesirable.

One could also wonder what economic incentive might be to *seed* torrents as 
opposed to leech them only, other than a "high-level" consideration that if 
nobody seeds, nobody can leech.

> Also, I know this is only tangentially related to Lightning so if this is a 
> discussion best left off the mailing list, just let me know.

bitcoin-dev will probably have more ideas and might be able to point you at 
some prior art for similar systems.

Regards,
ZmnSCPxj___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Tyler H]

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 mappings in a sane way (and maybe pushdata2/4 won't be allowed if
255 bytes are enough) would be allowable given the benefit it brings of
truly decentralized, human-readable trust.

I also wonder what the economic incentive might be for every node to store
and gossip the Numerifides mappings - sure they want everyone to find them,
but who cares about other people? It could be a situation like the current
Bitcoin mempool where it's saved on a best-effort basis and is
semi-transient, but that makes troubleshooting lookups problematic.

Also, I know this is only tangentially related to Lightning so if this is a
discussion best left off the mailing list, just let me know.

Thanks,
Tyler

On Fri, Apr 20, 2018 at 1:46 AM ZmnSCPxj  wrote:

> 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 to less additional
> "networks".
>
>
> Gossiped data is almost impossible to censor (ask Streisand how well that
> works to censor her Malibu home).  However, mere gossip is often
> unverifiable.
>
> What we do here is twofold:
>
> 1.  We use the blockchain layer for verification.  Commands 
> "google.com=127.0.0.1"
> are backed by actual Bitcoin satoshi being locked, sacrificing opportunity
> costs, making them costly and verifiably costly, unlike gossip which is
> unverifiable.
> 2.  We use the gossip overlay for censorship resistance.  Once a command
> has been confirmed on the Bitcoin blockchain, we can share that command to
> our peers on the gossip overlay, and unless all our peers are colluding, it
> is likely that a command gets out somehow.
>
> This design also uses P2WSH, so 51% miners, at least, cannot censor
> Numerifides commands: all they see is a hash of something which could be a
> LN fundchannel or a M-of-N SegWit or etc etc. We wait for the transaction
> to confirm (which starts the CSV relative-locktime countdown anyway), after
> which the miner cannot "take back" its confirmation of your Numerifide
> command without losing costly work, and only THEN reveal the P2WSH preimage
> on the Numerifides gossip overlay network.
>
> The gossip overlay then provides censorship resistance on top of that,
> revealing the preimage of the P2WSH (AFTER it has been confirmed onchain)
> and revealing your Numerifide command.  It is unlikely that anyone can stop
> the gossip overlay unless they control your entire Internet connection, in
> which case you have more serious problems and might not even be able to
> have a current view of the Bitcoin blockchain anyway.
>
> Already today any user that includes a commensurate miner's fee can use
> the pushdata opcodes and add whatever data they want to the blockchain.
>
>
> Granted.  It still makes bitcoin-dev cry when this is done.  And in any
> case, reducing the blockchain footprint has real benefits of reducing the
> amount that gets given to miners and increasing what can be put into
> command bids anyway.
>
>
> One thing that the design requires is a separate method of communicating
> bindings and not being censored - if it were onchain, a DNS lookup could
> simply be no more than a light client requesting the relevant block.
>
>
> Possibly.  Note however that the "publish everything onchain" design
> requires cooperation of a Bitcoin miner, since it seems you are using
> scriptpubkey rather than P2WSH.  In particular the IsStandard() check will
> mean your transaction will not get transmitted on the normal Bitcoin peer
> network and you will need direct connection and cooperation of a Bitcoin
> miner, to get your non-standard script in a scriptpubkey.
>
> If you intend to use P2SH or P2WSH, then you will need a gossip layer to
> reveal the script preimage anyway, so you might as well use the more
> efficient P2WSH-based construction I showed.
>
> I think anything that gets seriously far along will need to have some data
> crunched and if only 100 users per day would fill up blocks then of course
> constraints would necessitate other avenues.
>
>
> Yes.  Knowing that, we might as well start efficient.
>
> Regards,
> ZmnSCPxj
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[ZmnSCPxj via Lightning-dev]

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 to less additional "networks".

Gossiped data is almost impossible to censor (ask Streisand how well that works 
to censor her Malibu home).  However, mere gossip is often unverifiable.

What we do here is twofold:

1.  We use the blockchain layer for verification.  Commands 
"google.com=127.0.0.1" are backed by actual Bitcoin satoshi being locked, 
sacrificing opportunity costs, making them costly and verifiably costly, unlike 
gossip which is unverifiable.
2.  We use the gossip overlay for censorship resistance.  Once a command has 
been confirmed on the Bitcoin blockchain, we can share that command to our 
peers on the gossip overlay, and unless all our peers are colluding, it is 
likely that a command gets out somehow.

This design also uses P2WSH, so 51% miners, at least, cannot censor Numerifides 
commands: all they see is a hash of something which could be a LN fundchannel 
or a M-of-N SegWit or etc etc. We wait for the transaction to confirm (which 
starts the CSV relative-locktime countdown anyway), after which the miner 
cannot "take back" its confirmation of your Numerifide command without losing 
costly work, and only THEN reveal the P2WSH preimage on the Numerifides gossip 
overlay network.

The gossip overlay then provides censorship resistance on top of that, 
revealing the preimage of the P2WSH (AFTER it has been confirmed onchain) and 
revealing your Numerifide command.  It is unlikely that anyone can stop the 
gossip overlay unless they control your entire Internet connection, in which 
case you have more serious problems and might not even be able to have a 
current view of the Bitcoin blockchain anyway.

> Already today any user that includes a commensurate miner's fee can use the 
> pushdata opcodes and add whatever data they want to the blockchain.

Granted.  It still makes bitcoin-dev cry when this is done.  And in any case, 
reducing the blockchain footprint has real benefits of reducing the amount that 
gets given to miners and increasing what can be put into command bids anyway.

> One thing that the design requires is a separate method of communicating 
> bindings and not being censored - if it were onchain, a DNS lookup could 
> simply be no more than a light client requesting the relevant block.

Possibly.  Note however that the "publish everything onchain" design requires 
cooperation of a Bitcoin miner, since it seems you are using scriptpubkey 
rather than P2WSH.  In particular the IsStandard() check will mean your 
transaction will not get transmitted on the normal Bitcoin peer network and you 
will need direct connection and cooperation of a Bitcoin miner, to get your 
non-standard script in a scriptpubkey.

If you intend to use P2SH or P2WSH, then you will need a gossip layer to reveal 
the script preimage anyway, so you might as well use the more efficient 
P2WSH-based construction I showed.

> I think anything that gets seriously far along will need to have some data 
> crunched and if only 100 users per day would fill up blocks then of course 
> constraints would necessitate other avenues.

Yes.  Knowing that, we might as well start efficient.

Regards,
ZmnSCPxj___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[ZmnSCPxj via Lightning-dev]

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 has a special encoding, so you might 
be able to get 52560 precisely).

The scheme as-is puts a lot of non-financial data onchain, which will make our 
bitcoin-dev colleagues cry.  We can consider something similar to 
pay-to-contract instead, which is similar to Taproot (indeed pay-to-contract is 
the basis of Taproot)

To create a Numerifides command, a user does the below:

1.  Generates a secret private key p = random() and the public key P = p * G.
2.  Encodes the Numerifides command (it could simply be a mapping "google.com = 
127.0.0.1") as "command".
3.  Computes the pay-to-contract public key: C = P + h(P || command) * G.  This 
has corresponding private key c = p + h(P || command) that only the user knows.
4.  Generates a P2WSH to the script: <52560 blocks> OP_CHECKSEQUENCEVERIFY 
OP_DROP  OP_CHECKSIG
5.  Pays to that P2WSH on the Bitcoin network.
6.  Broadcasts command, P, and the txid+outnum of the UTXO that pays to the 
P2WSH above, to the Numerifides network (not the Bitcoin network, Bitcoin 
cannot understand it).

Numerifides network nodes, on receiving a command+P+outpoint, then verifies it 
by confirming that it can get C = P + h(P || command) * G, and that the 
outpoint is unspent, and pays to a P2WSH matching the above script template 
with the  replaced with the computed C.

When the command expires (i.e. the lock time is completed) then the user can 
reclaim its locked coins from c = p + h(P || command), meaning it only has to 
memorize p and command.

UTXOs that pay to the above construction that have expired the CSV will have 
the corresponding command deleted from your Numerifides database.

If two commands conflict, then we simply prefer the one with higher locked 
amount (if equal, I do not know, your choice, maybe prefer the earlier one).  
And so on.  What those commands are can be specified as you wish in your 
Numerifides proposal.

If you insist on bringing in proof-of-work, the proof-of-work can be embedded 
in the "command" rather than on the Bitcoin blockchain.  All that is published 
on the Bitcoin blockchain will be the point  (33 bytes) and a signature 
using c (64 bytes) plus a relatively small script, keeping bitcoin-dev happy.

The same scheme can be used for practically any kind of asset I believe, not 
just names.

Regards,
ZmnSCPxj___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Tyler H]

"[]" 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 in block time, coinciding with the duration of
the name registration.

I'll look into your proof of mainstake as that does sound similar to what
I'm working on here.

Thanks,
Tyler
On Thu, Apr 19, 2018, 23:43 ZmnSCPxj  wrote:

> 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 relative time.  Why
> blockheight 52560 in particular?  I believe this was in 2010?  Or are you
> thinking OP_CHECKSEQUENCEVERIFY which imposes a relative timelock?
>
> Locking funds for a time may be enough without pulling in proof-of-work,
> especially since the Bitcoin blockchain itself is already proof-of-work.
> See my half-baked ideas for proof-of-mainstake, where locking funds in the
> mainchain is used as voting rights for correctness of the sidechain,
> avoiding normal proof-of-stake problems since the stake that backs the
> chain is on a separate proof-of-work chain.
>
> Regards,
> ZmnSCPxj
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[ZmnSCPxj via Lightning-dev]

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 relative time.  Why blockheight 
52560 in particular?  I believe this was in 2010?  Or are you thinking 
OP_CHECKSEQUENCEVERIFY which imposes a relative timelock?

Locking funds for a time may be enough without pulling in proof-of-work, 
especially since the Bitcoin blockchain itself is already proof-of-work.  See 
my half-baked ideas for proof-of-mainstake, where locking funds in the 
mainchain is used as voting rights for correctness of the sidechain, avoiding 
normal proof-of-stake problems since the stake that backs the chain is on a 
separate proof-of-work chain.

Regards,
ZmnSCPxj___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Tyler H]

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 lookups (like DNS
requests).
- Doesn't have the squatting problems of Namecoin (squatting a name costs
you locked up Bitcoin funds)
- Consensus revocation of names (Someone squatting google.com but the
community knows that's a lie? It's possible to "unseat" that registration)
- If you registered a name no one cares about (oeJFwlkS) no one will care
to try to unseat your name, except to steal your funds you locked up (which
need to just be high enough so as to not be dust)
- Usable for any name->data association such as Lightning nodes, DNS,
Certificate Authorities, decentralized identities etc

Already I know some concerns are in the details of implementation like the
hash function used for the transaction puzzle, censorship resistance
(though the market effect does play itself well here) and privacy concerns
(though the committed data can be encrypted or hashed before being stored
as I do envision a "catchall" unadvertised datatype where anyone can commit
anything for any purpose such as for document existence or even committing
an encrypted key to some piece of data).  I also don't like the idea of
people committing IP addresses of their websites to the blockchain for all
time, but perhaps a 2nd-layer "nameserver"-like configuration can be found
for less permanent, more ephemeral data like DNS.

I'd love any feedback the list has to offer.

On Mon, Apr 16, 2018 at 6:19 AM Corné Plooy via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:

>
> 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 blockchains.
> >
> Two of my favorite approaches:
> * Namecoin-style: Register your name first-come-first-serve on a block
> chain.
>   -> Provides no protection against name squatting and attackers
> registering similarly-looking names.
> * Web of Trust: I tell you I believe this pubkey really corresponds to
> this name; someone else might tell you something else. DNS is
> essentially a special case of this, where the WoT has a centralized star
> shape. TLS is another case, where there is dozens of signing parties
> (CAs), and everyone typically gets their keys signed by only one of
> them, so anyone verifying keys has to trust all these CAs. More
> generally, a WoT can have any shape though.
>   -> Provides little to no protection against trusted parties lying to you.
>
> CJP
>
>
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Corné Plooy via Lightning-dev]

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 blockchains.
>
Two of my favorite approaches:
* Namecoin-style: Register your name first-come-first-serve on a block
chain.
  -> Provides no protection against name squatting and attackers
registering similarly-looking names.
* Web of Trust: I tell you I believe this pubkey really corresponds to
this name; someone else might tell you something else. DNS is
essentially a special case of this, where the WoT has a centralized star
shape. TLS is another case, where there is dozens of signing parties
(CAs), and everyone typically gets their keys signed by only one of
them, so anyone verifying keys has to trust all these CAs. More
generally, a WoT can have any shape though.
  -> Provides little to no protection against trusted parties lying to you.

CJP


___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Christian Decker]

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 the risk gets managed if the public and private
> nodes are owned by the same economic entity.
>
> Suppose I am a single economic entity, and I have a public node B and
> a private node C.  You are the customer A who pays me.
>
> A -> B -> C
>
> Now the channel B->C contains money I own.  Any transfers between B
> and C are simply money juggling around between two accounts I own.
> Thus my earnings are never in the B->C channel, but in the (public!)
> A->B channel.  So attacking B will still allow hackers to take my
> earnings, because B->C only contains savings.  Indeed I probably take
> *more* risk here, since I need to fund B->C rather than, say, keep
> that money in a cold storage paper in a locked vault buried beneath
> concrete somewhere in the jungles of Africa (I would like to take the
> time to note that this is not where I actually keep my cold storage).
>
> Which is not to say this is completely worthless.  Perhaps B and C are
> owned by different entities: B takes on risk, and in exchange charges
> a larger-than-usual feerate for the B->C channel transfers.

Excellent point, but I think there are more advantages to having a node
separate from the gateway as source of truth. Let's assume the gateway
node, exposed directly to the open network is compromised, that still
means that an eventual store independently verifies incoming payments,
i.e., it is not possible for the compromised node to escalate to the
store, without also compromising the hidden nodes. If however the
gateway node provides the ground truth for the store, then the attacker
could just mark all of the attacker's invoices as complete and thus
steal goods from the shop. The attacker is limited to drain the B -> C
channel, to steal goods from the store, until it gets rebalanced.

Cheers,
Christian
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[ZmnSCPxj via Lightning-dev]

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 believe this faces the issue of Zooko's Triangle?  Decentralized, Secure, 
Human-meaningful: pick any two.

Node pubkeys are Decentralized and Secure (good luck memorizing 
store.blockstream.com node pubkey if you are merely human).

Node aliases are Decentralized and Human-meaningful (nothing prevents me from 
naming my node SLEEPYARK, though).

DNS is Secure and Human-meaningful (DNS registration is centralized around 
ICANN).

Maybe a DNS la

Regards,
ZmnSCPxj___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Tyler H]

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 from Olaoluwa Osuntokun on the
LND slack, I've decided to pull my support for implementing this specific
proposal as part of this spec.

To summarize the primary issue with this proposed BOLT:
DNS in its current form cannot be trusted as part of the Lightning spec,
plain and simple.

While I've rescinded my support, I don't discourage thoughtful
implementation of functionality like this, but I do caution any
implementation to properly inform the user as to the inherent risk in
trusting DNS, and only use DNS records as a way to increase confidence, not
make guarantees, that a node is associated to the domain it says it is.

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 leave this proposal in Robert's hands to further defend if he wishes, and
I would discourage future proposals largely similar to this but on other
authenticated technologies (for example, advertising node information via
forum posts).  Any information that doesn't come from the network itself
cannot be backed by cryptographic guarantees.

Other discussions regarding public vs private nodes and channel structures
are encouraged.

Best regards,
Tyler

On Tue, Apr 10, 2018 at 5:23 AM ZmnSCPxj  wrote:

> 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
> published the "public" side knows that any economic activity going through
> the "private" channel must terminate on the other side.
>
> Perhaps better terms would be "published" and "unpublished" channels.  We
> should really warn people that use of unpublished channels leaks your
> economic information, whereas use of published channels give the plausible
> deniability that it could be somebody else using that channel, not you.
>
> You could try contracting out to multiple external parties, so that at
> least no single entity knows *all* your economic activity.  You still leak
> all your economic activity, you are simply hoping that those external
> parties do not pool their information together to get a complete profile of
> you.  Seems like a quixotic endeavor.  You may be better off using your own
> public node.
>
> Multiple public nodes may be useful for load distribution.  You could also
> try implementation diversity, using different secure operating system,
> hardware, and LN node software for each node, in the hope that 0days have
> lower probability of affecting them all simultaneously.
>
> You could have multiple public nodes A <-> B with a published channel
> between them that is larger than normally allowed; many of the issues with
> large channels disappear when you know that you can trust each other. and
> if you really own both A and B, then you know A can trust B and vice
> versa.  The purpose is load distribution: you could source half your
> invoices with one and half your invoices with the other, and the channel
> between them allows customers to use e.g. a channel to A to pay an invoice
> made by B when all other published channels to B are depleted.  But in
> terms of hackability, you should really not make A trust B and vice versa,
> though.
>
> Regards,
> ZmnSCPxj
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[ZmnSCPxj via Lightning-dev]

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 published the 
"public" side knows that any economic activity going through the "private" 
channel must terminate on the other side.

Perhaps better terms would be "published" and "unpublished" channels.  We 
should really warn people that use of unpublished channels leaks your economic 
information, whereas use of published channels give the plausible deniability 
that it could be somebody else using that channel, not you.

You could try contracting out to multiple external parties, so that at least no 
single entity knows *all* your economic activity.  You still leak all your 
economic activity, you are simply hoping that those external parties do not 
pool their information together to get a complete profile of you.  Seems like a 
quixotic endeavor.  You may be better off using your own public node.

Multiple public nodes may be useful for load distribution.  You could also try 
implementation diversity, using different secure operating system, hardware, 
and LN node software for each node, in the hope that 0days have lower 
probability of affecting them all simultaneously.

You could have multiple public nodes A <-> B with a published channel between 
them that is larger than normally allowed; many of the issues with large 
channels disappear when you know that you can trust each other. and if you 
really own both A and B, then you know A can trust B and vice versa.  The 
purpose is load distribution: you could source half your invoices with one and 
half your invoices with the other, and the channel between them allows 
customers to use e.g. a channel to A to pay an invoice made by B when all other 
published channels to B are depleted.  But in terms of hackability, you should 
really not make A trust B and vice versa, though.

Regards,
ZmnSCPxj___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[ZmnSCPxj via Lightning-dev]

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 network to an uncomfortable degree.  I used 
> "autoconnect" because that's the terminology in the mobile wallet, but it is 
> misleading.

Ah, I see.  Should have been "autochannel" I suppose.

>> I am not sure how the risk gets managed if the public and private nodes are 
>> owned by the same economic entity.
>
> If the public facing node gets hacked, it cannot draw funds from the private 
> node, only send them out to the attacker on the network, or close the 
> channels and send the funds + wallet balance to an on-chain address.  The 
> "warm" funds in your example sit on the C side of the B -> C channel.

Let us break this down.

Suppose we start with this state:

A 2 <-> 0 B 2 <-> 0 C

Now, again, suppose the situation is that B and C are owned by the same 
economic entity, Tyler & Rompert Enterprises.

Suppose A pays 1 BTC to C:

A 1 <-> 1 B 1 <-> 1 C

Now suppose public node B is hacked.  This means B can close the channels and 
move the funds onchain to the hacker onchain address.  In that case, a total of 
2 BTC can be stolen from node B.

Now suppose Tyler & Rompert Enterprises decides not to actually have a private 
node C.  We start with this state:

A 2 <-> 0 B

Suppose A pays 1 BTC to B:

A 1 <-> 1 B

Now suppose public node B is hacked. This means B can close the channels and 
move the funds onchain to the hacker onchain address. In that case, a total of 
1 BTC can be stolen from node B.  Compare this to the previous situation, where 
2 BTC can be stolen from node B, *precisely because of the existence of B<->C*.

So it is strictly better it seems, from a risk perspective, to just use a 
public node directly, than running a public node and one or more private nodes. 
 You lose less this way than also funding a channel from your public to your 
private node.

Either that, or you contract to an external party who takes on the risk of 
running a public node, most likely in exchange for much higher feerates to your 
private node.

Regards,
ZmnSCPxj___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Tyler H]

> 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
connect (but NOT make a channel with) a known fixed node with known high
uptime, then the autopilot downloads the entire network map, then connects
and creates channels to nodes from the map.

This is outside of the spec, isn't it? All implementations should use a
seed service to bootstrap themselves to the network.

> The plan is that you connect (but NOT make a channel with) a known fixed
node with known high uptime, then the autopilot downloads the entire
network map, then connects and creates channels to nodes from the map.

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 network to an uncomfortable
degree.  I used "autoconnect" because that's the terminology in the mobile
wallet, but it is misleading.

I hope the additional text I've added in the RFC makes this clear, and I
regret any confusion.  Most of the functionality enabled by this proposed
BOLT would be in giving users the ability to more easily open channels to
the node they intend to, by giving node operators a way to advertise their
nodes. I do think perhaps the proposed RFC could be further improved by
adding a stipulation that autopilot functionality MUST NOT rely on domains
advertising nodes, and a user MUST choose to open a channel to a node based
on the domain.

> I am not sure how the risk gets managed if the public and private nodes
are owned by the same economic entity.

If the public facing node gets hacked, it cannot draw funds from the
private node, only send them out to the attacker on the network, or close
the channels and send the funds + wallet balance to an on-chain address.
The "warm" funds in your example sit on the C side of the B -> C channel.

Regarding "hubs", I think that while the barrier to entry into running
multiple nodes isn't zero, it's low enough that even singular moderately
technical node operators might operate with their channels in such a
configuration as this to better reduce their external risk.  A user with a
laptop and Docker could run multiple nodes with channels between them, for
instance, and the containers could be insulated from each other except for
Lightning protocol traffic.

Best,
Tyler

On Mon, Apr 9, 2018 at 7:31 PM ZmnSCPxj  wrote:

> Good morning Tyler,
>
> > A side effect of this BOLT would be, as an example, the mobile Eclair
> wallet could be updated to accept a domain parameter to specify an initial
> node to open a user's first channel to rather than only the option to
> "autoconnect" to their hard-coded node, and the wallet could handle
> resolving and picking a node transparently, thus increasing
> decentralization of "fringe" users such as mobile users and SPV nodes.
>
> 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
> connect (but NOT make a channel with) a known fixed node with known high
> uptime, then the autopilot downloads the entire network map, then connects
> and creates channels to nodes from the map.
>
> While certainly getting a node other than the hardcoded one might let you
> avoid censorship of nodes by free software developers of the wallet, I am
> uncertain if getting gossip from a known merchant node is *better* than
> that.  Certainly you can be sure that the free software developers have at
> least some nominal checks and balances (and publicly-visible codebase) to
> prevent censorship, which might not be the case for purely commercial
> enterprises.
>
> > 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 the risk gets managed if the public and private nodes
> are owned by the same economic entity.
>
> Suppose I am a single economic entity, and I have a public node B and a
> private node C.  You are the customer A who pays me.
>
> A -> B -> C
>
> Now the channel B->C contains money I own.  Any transfers between B and C
> are simply money juggling around between two accounts I own.  Thus my
> earnings are never in the B->C channel, but in the (public!) A->B channel.
> So attacking B will still allow hackers to take my earnings, because B->C
> only contains savings.  Indeed I probably take *more* 

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

[Tyler H]

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
inherent flaws.)

>we can just do the domain -> nodeid binding without encouraging
> users to actually open a direct connection :-)

Right - the intention is to provide fallback mechanisms and user-friendly
ways of finding the right nodes.  If a user wants to open a channel to
Starbucks before they leave their house, then can and then let the
confirmation process start on the way there.

> The risk is that
> if we spec and implement this right now, it'll become the normal mode of
> operation and we'll end up with a very poor network.

I agree, and I am in no rush to get this BOLT part of the spec before every
implementation has an autopilot function in a state they're comfortable
with.  If we want to kick it out for some months or even longer to allow
time for the network to bootstrap itself in a decentralized way, I'm fine
with that. I do think the pros of being able to associate a given
merchant/user with their incoming node in a way familiar to users will help
to ease the pain of opening channels that are useful to the user.

> Well, the fallback solution is not exactly free either, it takes time to
confirm the channel, so the merchant can indeed force a degraded user
experience

Ah, good point. I would exercise caution against implementing my exact
proposal regarding channel opens as payments as it was an example of
functionality that would be enabled by the BOLT that needs careful thought
and design to address concerns.  I think the ability to find nodes operated
by the owners of domains and subdomains could open up other useful
possibilities as well, including giving mobile users the option of where to
open their first channel to.

With your feedback, perhaps a good idea would be to decide on and
explicitly defined allowable uses for information gleaned from DNS records
such as the line already added about disallowing bootstrapping from a
non-seed domain.

Perhaps the first approved use-case could be invoices that include a domain
in the extra fields, clients can do a lookup on the domain and ensure the
node they're paying is listed, and if not provide a warning notification to
the user, or simply display the domain and the result of the lookup.

This would provide some protection against invoice tampering, as a
malicious actor with the ability to modify the invoice displayed to the
user would have to also display a domain other than the one the one
associated with the website the user intended to pay.

Thanks,
Tyler

On Mon, Apr 9, 2018 at 12:26 PM Christian Decker 
wrote:

> 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 proof of their payment of the
> invoice.
> > This wouldn't even require the channel to be usable, and merchants could
> > decide to accept 1 (or even 0) confirmations of this transaction based on
> > their acceptable level of risk, considering the properties of the channel
> > (capacity, local balance etc).  So in that use case, this would be a
> rough
> > process of the interaction:
>
> There is very little difference between pushing with the channel
> creation and just doing an immediate update even though the channel
> isn't confirmed yet. To be honest I think the `push_msat` feature is the
> classical case of optimizing too early.
>
> But the end result is still that the merchant either takes a hit in the
> trustworthiness of the incoming payment, or the buyer is going to have a
> bad time waiting at the checkout until the channel confirms.
>
> > User tries to pay lightning invoice, and it fails.  The user's wallet
> > offers to pay via channel opening.  The user accepts.  The wallet reads
> the
> > invoice for a "domain" field, or perhaps if the wallet happens to be a
> > browser, it does a SRV lookup against the current domain serving the
> > invoice.  The wallet looks up the domain records, and verifies the
> > destination node is present.  If so, the wallet picks the correct node
> > based on the records present, and opens a channel with a push amount to
> > it.  The destination node sees this and via as some yet undetermined
> > method, associates it to that payment invoice and chooses to mark it as
> > "paid" or "pending X confirmations" according to whatever criteria the
> node
> > operator wishes to use.
>
> I was going to comment that, since we already have an invoice detailing
> the destination, the indirection through the DNS system to find the
> desired connection point was useless, 

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

[Christian Decker]

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 proof of their payment of the invoice.
> This wouldn't even require the channel to be usable, and merchants could
> decide to accept 1 (or even 0) confirmations of this transaction based on
> their acceptable level of risk, considering the properties of the channel
> (capacity, local balance etc).  So in that use case, this would be a rough
> process of the interaction:

There is very little difference between pushing with the channel
creation and just doing an immediate update even though the channel
isn't confirmed yet. To be honest I think the `push_msat` feature is the
classical case of optimizing too early.

But the end result is still that the merchant either takes a hit in the
trustworthiness of the incoming payment, or the buyer is going to have a
bad time waiting at the checkout until the channel confirms. 

> User tries to pay lightning invoice, and it fails.  The user's wallet
> offers to pay via channel opening.  The user accepts.  The wallet reads the
> invoice for a "domain" field, or perhaps if the wallet happens to be a
> browser, it does a SRV lookup against the current domain serving the
> invoice.  The wallet looks up the domain records, and verifies the
> destination node is present.  If so, the wallet picks the correct node
> based on the records present, and opens a channel with a push amount to
> it.  The destination node sees this and via as some yet undetermined
> method, associates it to that payment invoice and chooses to mark it as
> "paid" or "pending X confirmations" according to whatever criteria the node
> operator wishes to use.

I was going to comment that, since we already have an invoice detailing
the destination, the indirection through the DNS system to find the
desired connection point was useless, but your example with Starblocks
where connections are accepted by one node, and payments by another
convinced me that this is indeed a useful feature. A feature however
that could be solved just as well by including an `r` tag in the invoice
itself. In this case you can either use the gossip protocol or the BOLT
10 DNS lookup system to locate the entry point into the merchant's
network. I don't think that a direct connection to the merchant in case
of it being unreachable is a good idea, because it creates latent
hubs. But I see the slight advantage of reducing the failure probability
w.r.t. to opening a channel with a random node.

> In a simple example, you could list all of your nodes but prefer clients
> open channels to a single one, similar to ACINQ's setup with "endurance"
> and "starblocks" on testnet.  This example would simply require setting
> "endurance" to have the highest priority. 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.

This is definitely true, if I'm not mistaken, starblocks doesn't even
allow incoming connections, so you have to use endurance as an entry
point.

> The result of this is that the user experience is improved, and a side
> benefit is being able to safely associate a given payment request, and by
> extension node, with a domain.  Another nontrivial benefit is there will be
> more channels opened with value on the other side, allowing for receiving
> funds back from Lightning.
>
> There are some possible open questions regarding ensuring a payment request
> hasn't been spoofed, but if you present the domain to the user, he/she can
> verify that the wallet is about to open a channel to the domain they
> expect.  Other issues with this are with DNS hijacking, which to be frank
> is not an unlikely scenario.  Caution would be necessary, and perhaps
> cryptographic means of associating nodes and their associated domains would
> be a requirement for something like this to exist, but the proposed BOLT
> lays the groundwork for that to happen.

There's some value in this, that's definitely true, however these kinds
of added security through DNS haven't quite worked out in the past. Then
again we can just do the domain -> nodeid binding without encouraging
users to actually open a direct connection :-)

> --Future payments going through the merchant:
>
> This is probably the biggest wrinkle.  The merchant _does_ have the ability
> to know when a payment transits the channel, thus reducing privacy.  I
> think the proposed BOLT should only be used to improve user experience, not
> as a replacement for the decentralized nature of Lightning.  For example,
> node operators will use autopilot-like functionality for opening channels,
> BUT they will be able to augment that with 

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

[Tyler H]

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.

--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 proof of their payment of the invoice.
This wouldn't even require the channel to be usable, and merchants could
decide to accept 1 (or even 0) confirmations of this transaction based on
their acceptable level of risk, considering the properties of the channel
(capacity, local balance etc).  So in that use case, this would be a rough
process of the interaction:

User tries to pay lightning invoice, and it fails.  The user's wallet
offers to pay via channel opening.  The user accepts.  The wallet reads the
invoice for a "domain" field, or perhaps if the wallet happens to be a
browser, it does a SRV lookup against the current domain serving the
invoice.  The wallet looks up the domain records, and verifies the
destination node is present.  If so, the wallet picks the correct node
based on the records present, and opens a channel with a push amount to
it.  The destination node sees this and via as some yet undetermined
method, associates it to that payment invoice and chooses to mark it as
"paid" or "pending X confirmations" according to whatever criteria the node
operator wishes to use.

In a simple example, you could list all of your nodes but prefer clients
open channels to a single one, similar to ACINQ's setup with "endurance"
and "starblocks" on testnet.  This example would simply require setting
"endurance" to have the highest priority. 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.

The result of this is that the user experience is improved, and a side
benefit is being able to safely associate a given payment request, and by
extension node, with a domain.  Another nontrivial benefit is there will be
more channels opened with value on the other side, allowing for receiving
funds back from Lightning.

There are some possible open questions regarding ensuring a payment request
hasn't been spoofed, but if you present the domain to the user, he/she can
verify that the wallet is about to open a channel to the domain they
expect.  Other issues with this are with DNS hijacking, which to be frank
is not an unlikely scenario.  Caution would be necessary, and perhaps
cryptographic means of associating nodes and their associated domains would
be a requirement for something like this to exist, but the proposed BOLT
lays the groundwork for that to happen.

--Future payments going through the merchant:

This is probably the biggest wrinkle.  The merchant _does_ have the ability
to know when a payment transits the channel, thus reducing privacy.  I
think the proposed BOLT should only be used to improve user experience, not
as a replacement for the decentralized nature of Lightning.  For example,
node operators will use autopilot-like functionality for opening channels,
BUT they will be able to augment that with looking up common stores and
merchant's domain records and open their own channels to them to provide
alternate routes to popular anticipated destinations for payments, thus
making their own node more valuable and increasing the decentralization of
the network.  For example, if you know people are going to be paying
Starbucks, you can issue a DNS request of your own, get their current
preferred node and connect, and then any node you have channels with will
be able to pay Starbucks through you, without having to open a channel of
their own.

--Merchant crippling payments:

With the convention I described above, using channel opens as proof of
payment, if Starbucks wants to deny a customer the ability to pay McDonalds
(or simply doesn't have the appropriate channels to do so), the user's
wallet will simply fall back, look up mcdonalds.com, find the appropriate
node and pay the invoice via channel opening.  This also partly addresses
point 2, as if a merchant wants to spy on its customers, it must provide
routes to its competitors.  It can either spy or deny routes, but not
both.  In addition, the onion-like nature of payments means the merchant
can't be sure a user paid a competitor, or a node behind them, though some
configurations of channels and nodes can definitely reduce privacy quite a
bit (example: a tiny etsy shop only has a couple of connections, Evil
Starbucks being one of them with the largest channel.  A user paying an
amount above the second largest channel to this shop would have to use the
merchant's channel, and the merchant would be sure that the payment didn't
travel any 

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

[Christian Decker]

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 that the kind of selective attachment to the
node of a merchant is beneficial to neither the node that is opening the
channel, nor for the network as a whole:

 - For the node opening a channel at the time of a payment is too late,
   it basically means that for the first payment you'd have to wait for
   an on-chain confirmation, even if we use `push_msat` to perform the
   initial payment. This is bad for the user experience. Channels should
   be opened ahead of time so that, when the customer enters a shop,
   everything is already set up. Special cases are always hard to
   communicate ("you have to wait, but only this time, then in future
   all will be nice and quick")
 - It also causes all future payments to go through that merchant, which
   can now collate your shopping activity with all of your other
   payments, and create a profile. It's basically the hub-and-spoke
   threat with the added problem of the hub also knowing your identity.
 - The merchant can cripple future payments that he might suspect are
   going to a competitor (Starbucks may attempt to block payments for
   amounts that look like coffee payments and go to their
   competitor). Think net neutrality for Lightning.
 - For the network as a whole this creates a network of large hubs that
   are only weakly interconnected, or not connected at all, unless the
   merchants are "generous" enough to maintain connections among each
   other.

But it's not all bad, I really like the possibility to look up a
merchant's node ID through DNS, so that my wallet can check (indirect)
connectivity to that node and try to optimize their connectivity.

I think we should encourage people, and implement the clients, to open
random connections, biased towards strenghtening the overall
connectivity. With the gossip protocol we already disseminate enough
information to allow nodes to identify bottlenecks and provide
additional capacity to bridge them.

Sorry for being so pessimistic, but I think it's important we move away
from people attempting to open targeted channels directly to the
merchants. I still regret publishing the IP address of SLEEPYARK.

Regards,
Christian

Tyler H  writes:
> 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 aliases around via word of mouth which is very prone to inaccuracy and
> MITM attacks. A current alternative is attempting to make a payment,
> decoding the payment request, finding the node on your graph and attempting
> to open a channel to the merchant.  This is only possible if the
> destination is advertising addresses.
>
> We (Robert Olsson and I) propose an additional BOLT, tentatively scheduled
> to be BOLT 12, to allow for operators of domain names to create SRV records
> for their nodes.  This is separate from BOLT 10's seed functionality as the
> desired outcome is to get only the nodes associated with a particular
> domain.  This would allow, as an example, users to say to each other
> "connect to a Blockstream.com node" and the user can independently look up
> that domain, find advertised nodes and connect/open channels.
>
> This also improves security from the perspective of nodes masquerading as
> other nodes, as anyone with a domain can authoritatively list their nodes.
>
> In addition, domain operators could provide subdomains for their node
> addresses to distinguish between nodes intended for a specific purpose,
> from a human perspective.
>
> Robert Olsson (rompert) and I have created
> https://github.com/lightningnetwork/lightning-rfc/pull/406 as a draft of
> what the RFC could look like.
>
> Feedback is much appreciated.
>
> Best regards,
> Tyler (tyzbit)
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Tyler H]

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 aliases around via word of mouth which is very prone to inaccuracy and
MITM attacks. A current alternative is attempting to make a payment,
decoding the payment request, finding the node on your graph and attempting
to open a channel to the merchant.  This is only possible if the
destination is advertising addresses.

We (Robert Olsson and I) propose an additional BOLT, tentatively scheduled
to be BOLT 12, to allow for operators of domain names to create SRV records
for their nodes.  This is separate from BOLT 10's seed functionality as the
desired outcome is to get only the nodes associated with a particular
domain.  This would allow, as an example, users to say to each other
"connect to a Blockstream.com node" and the user can independently look up
that domain, find advertised nodes and connect/open channels.

This also improves security from the perspective of nodes masquerading as
other nodes, as anyone with a domain can authoritatively list their nodes.

In addition, domain operators could provide subdomains for their node
addresses to distinguish between nodes intended for a specific purpose,
from a human perspective.

Robert Olsson (rompert) and I have created
https://github.com/lightningnetwork/lightning-rfc/pull/406 as a draft of
what the RFC could look like.

Feedback is much appreciated.

Best regards,
Tyler (tyzbit)
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev