[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 <ZmnSCPxj at protonmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180420/579e6c65/attachment.html>