c-lighting-dissector work now: https://github.com/arowser/lightning/tree/dissector https://github.com/arowser/lightning-dissector ./configure --enable-dissector && make -j
On Thu, Nov 8, 2018 at 10:39 AM Christian Decker <decker.christ...@gmail.com> wrote: > Would it be possible to query a command line program or a JSON-RPC call to > get the secret? In that case we could add it to the `listpeers` output. > > On Wed, Nov 7, 2018 at 6:43 AM tock203 <tomokio...@gmail.com> wrote: > >> We implemented the latter scheme. lightning-dissector already supports >> key rotation. >> FYI, here's the key log file format lightning-dissector currently >> implements. >> https://github.com/nayutaco/lightning-dissector/blob/master/CONTRIBUTING.md#by-dumping-key-log-file >> >> Whenever key rotation happens(nonce==0), lightning node software write >> 16byteMAC & key of "first BOLT packet". >> When you read .pcap starts with a message whose nonce is not 0, the >> messages can not be decrypted until the next key rotation. >> >> The current design is as described above. Because it is a provisional >> specification, any opinion is welcome. >> >> 2018年11月6日(火) 16:08 Olaoluwa Osuntokun <laol...@gmail.com>: >> >>> Hi tomokio, >>> >>> This is so dope! We've long discussed creating canned protocol >>> transcripts for >>> other implementations to assert their responses again, and I think this >>> is a >>> great first step towards that. >>> >>> > Our proposal: >>> > Every implementation has compile option which enable output key >>> information >>> > file. >>> >>> So is this request to add an option which will write out the _plaintext_ >>> messages to disk, or an option that writes out the final derived >>> read/write >>> secrets to disk? For the latter path, it the tools that read these >>> transcripts >>> would need to be aware of key rotations, so they'd be able to continue >>> to >>> decrypt the transact pt post rotation. >>> >>> -- Laolu >>> >>> >>> On Sat, Oct 27, 2018 at 2:37 AM <tomokio...@gmail.com> wrote: >>> >>>> Hello lightning network developers. >>>> Nayuta team is developing Wireshark plug-in for Lightning Network(BOLT) >>>> protocol. >>>> https://github.com/nayutaco/lightning-dissector >>>> >>>> It’s alpha version, but it can decode some BOLT message. >>>> Currently, this software works for Nayuta’s implementation(ptarmigan) >>>> and Éclair. >>>> When ptarmigan is compiled with some option, it write out key >>>> information file. This Wireshark plug-in decode packet using that file. >>>> When you use Éclair, this software parse log file. >>>> >>>> Through our development experience, interoperability test is time >>>> consuming task. >>>> If people can see communication log of BOLT message on same format >>>> (.pcap), it will be useful for interoperability test. >>>> >>>> Our proposal: >>>> Every implementation has compile option which enable output key >>>> information file. >>>> >>>> We are glad if this project is useful for lightning network eco-system. >>>> >>> _______________________________________________ >>>> Lightning-dev mailing list >>>> Lightning-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >>>> >>> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
