From tyzbit at gmail.com Fri Apr 20 09:58:35 2018 From: tyzbit at gmail.com (Tyler H) Date: Fri, 20 Apr 2018 09:58:35 +0000 Subject: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records. In-Reply-To: <2O3hOBoDZgr4F8bzcIP0uKgN1J9EOiN0lFCsiDgzLFh0V8XJ3Gp63xYYShQZh0WpRTLRKemCZFpVihMbEYRAvG9tTJW5GBCmpV1YkO95Nmc=@protonmail.com> References: <2O3hOBoDZgr4F8bzcIP0uKgN1J9EOiN0lFCsiDgzLFh0V8XJ3Gp63xYYShQZh0WpRTLRKemCZFpVihMbEYRAvG9tTJW5GBCmpV1YkO95Nmc=@protonmail.com> Message-ID: 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: