{"type":"rich","version":"1.0","author_name":"npub1qg5r4lja0e34twn6psh49qlrzj0k28dtxxw0k4fag6sarqprfm2s7nqm4r","author_url":"https://nostr.ae/npub1qg5r4lja0e34twn6psh49qlrzj0k28dtxxw0k4fag6sarqprfm2s7nqm4r","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-05-03\n📝 Original message:\nZman,\n\nI was not arguing for moving things from the edge, nor was I arguing to\nmake Taro a BOLT. Laolu is misinterpreting my message.\n\nI was explaining that the capabilities that would allow Taro to interact\nwith LN have no special relationship to Taro alone and should be designed\nto accommodate any outside layer/network.\n\nI gave specific examples of requirements that LL is portraying as Taro\nLayer design, that are really just new features for LN nodes that do not\nneed to be network/layer-specific:\n\n - Making LN nodes aware of assets on other networks\n - Establishing commitments for (atomic) swapping for payments/routing\n - Supporting the ability to exchange and advertise exchange rates for\nasset pairs\n - Supporting other multi-asset routes when considering routing paths,\nbridging nodes with alternate assets\n\nI don't care whether this is framed as BOLT or BLIP content, as in the end\neach implementation will do what it needs to stay relevant in the market. I\ncare that this is framed and designed correctly, so we aren't locked into\none specific outside layer. You could argue the degree to which the above\nfeatures need to exist in the network, and whether to restrict such\nfeatures to the \"edge,\" but my point is that an LN node that wants to be\naware of an outside network, and extra assets in addition to Bitcoin, will\nneed such features, and such features are not Taro-specific.\n\n\nGood morning John, and Laolu,\n\u003e\n\u003e \u003e \u003e but instead the requirement to add several feature concepts to LN that\n\u003e \u003e \u003e would allow tokens to interact with LN nodes and LN routing:\n\u003e \u003e\n\u003e \u003e From this list of items, I gather that your vision is actually pretty\n\u003e \u003e different from ours. Rather than update the core network to understand\n\u003e the\n\u003e \u003e existence of the various Taro assets, instead we plan on leaving the core\n\u003e \u003e protocol essentially unchanged, with the addition of new TLV extensions\n\u003e to\n\u003e \u003e allow the edges to be aware of and interact w/ the Taro assets. As an\n\u003e \u003e example, we wouldn't need to do anything like advertise exchange rates in\n\u003e \u003e the core network over the existing gossip protocol (which doesn't seem\n\u003e like\n\u003e \u003e the best idea in any case given how quickly they can change and the\n\u003e existing\n\u003e \u003e challenges we have today in ensuring speedy update propagation).\n\u003e\n\u003e Adding on to this, the American Call Option problem that arises when using\n\u003e H/PTLCs:\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html\n\u003e\n\u003e The above objection seems to be one reason for proposing multi-asset \"on\n\u003e the edge\" rather than have it widely deployed in the published Lightning\n\u003e Network.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220503/d3b236c6/attachment-0001.html\u003e"}