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

ZmnSCPxj ZmnSCPxj at protonmail.com
Fri Apr 20 05:46:12 UTC 2018


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180420/4a7db250/attachment.html>


More information about the Lightning-dev mailing list