<div dir="ltr">Great points.  IsStandard() is something I hadn&#39;t considered yet, but I think miners are incentivized to want Numerifides transactions as a registration will need a solid miners fee, and &quot;revoked&quot; 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&#39;t be allowed if 255 bytes are enough) would be allowable given the benefit it brings of truly decentralized, human-readable trust.<div><br></div><div>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&#39;s saved on a best-effort basis and is semi-transient, but that makes troubleshooting lookups problematic.</div><div><br></div><div>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.<br><div><br></div><div>Thanks,</div><div>Tyler</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Apr 20, 2018 at 1:46 AM ZmnSCPxj &lt;<a href="mailto:ZmnSCPxj@protonmail.com" target="_blank">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Good morning Tyler,<br></div><div><br></div><blockquote class="m_-3261346463175304006m_1508288296471861922protonmail_quote" type="cite"><div>I like the efficiency your method brings and I&#39;m also not that enthused about bloating the blockchain with &quot;non-financial data&quot;, however I do think there&#39;s value in having the data live in the base chain, both from accessibility and censorship resistance of the data to less additional &quot;networks&quot;.<br></div></blockquote><div><br></div><div>Gossiped data is almost impossible to censor (ask Streisand how well that works to censor her Malibu home).  However, mere gossip is often unverifiable.<br></div><div><br></div><div>What we do here is twofold:<br></div><div><br></div><div>1.  We use the blockchain layer for verification.  Commands &quot;<a href="http://google.com" target="_blank">google.com</a>=127.0.0.1&quot; are backed by actual Bitcoin satoshi being locked, sacrificing opportunity costs, making them costly and verifiably costly, unlike gossip which is unverifiable.<br></div><div>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.<br></div><div><br></div><div>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 &quot;take back&quot; its confirmation of your Numerifide command without losing costly work, and only THEN reveal the P2WSH preimage on the Numerifides gossip overlay network.<br></div><div><br></div><div>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.<br></div><div><br></div><blockquote class="m_-3261346463175304006m_1508288296471861922protonmail_quote" type="cite"><div> Already today any user that includes a commensurate miner&#39;s fee can use the pushdata opcodes and add whatever data they want to the blockchain.<br></div></blockquote><div><br></div><div>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.<br></div><div><br></div><blockquote class="m_-3261346463175304006m_1508288296471861922protonmail_quote" type="cite"><div><br></div><div>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.<br></div></blockquote><div><br></div><div>Possibly.  Note however that the &quot;publish everything onchain&quot; 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.<br></div><div><br></div><div>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.<br></div><div><br></div><blockquote class="m_-3261346463175304006m_1508288296471861922protonmail_quote" type="cite"><div>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.<br></div></blockquote><div><br></div><div>Yes.  Knowing that, we might as well start efficient.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div></blockquote></div></div></div>