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 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.
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.
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.
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". 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. 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. 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. Thanks, Tyler On Fri, Apr 20, 2018, 00:30 ZmnSCPxj wrote: > 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.
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.
"[]" 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.
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.
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.
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.
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, Yes, I understand I essentially I'd have to solve that trilemma in order to implement something suitable for Lightning. That is why I have pulled my support for my proposal, and I do insist that the proposal AT MOST be a convention, but not a standard, and nodes SHOULD NOT trust DNS. Thanks, Tyler On Wed, Apr 11, 2018 at 3:28 AM ZmnSCPxj wrote: > 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.
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.
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.
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.
I understand now, I hadn't fully considered the necessary channels for such a configuration, though there is still the value of domain owners being able to advertise preferred nodes to connect to in order to pay them efficiently. 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. Thanks, Tyler On Mon, Apr 9, 2018 at 8:58 PM ZmnSCPxj wrote: > 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.
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.
> 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* risk here, since I > need t
Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.
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* 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. Alternatively, perhaps I am a large conglomerate and I have multiple subsidiaries. I might create a single public access node and several private nodes for each of my subsidiaries, giving one larger-than-normal (>16777215 satoshi) channel for each subsidiary. I take actual earnings from my single public node, and then each of my subsidiaries implicitly gives a report of how much they earned (I simply look up how much of each private channel belongs belongs to the subsidiary private node; this is equivalent to what the subsidiary earned). But I do not think it is possible for a single entity to use this to manage its own risk. Perhaps indeed "hubs" will arise who take on the risk of being a public node with possibly large amounts of money in their channels, and create private channels to their clients, which at least are trustless since the client can drop the channel onchain if they lose trust in the hub (i.e. it is still a better situation than current "merchant accounts" offered by exchanges, where you cannot get your money out if the exchange decides you are unworthy). 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.
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, but your example with Starblocks > where connect
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 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 looking up common stores
Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.
Christian et al, I've added additional wording to the PR to explicitly state BOLT 12 MUST NOT be used for node bootstrapping. I will squash the commits should this proposal become a standard. 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. Criticism and feedback is enthusiastically invited. Thanks, Tyler On Sun, Apr 8, 2018 at 5:48 PM Tyler H wrote: > 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 app
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. --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 furthe
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 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