René Pickhardt [ARCHIVE] on Nostr: 📅 Original date posted:2018-03-03 📝 Original message: Hey everyone, as ...
📅 Original date posted:2018-03-03
📝 Original message:
Hey everyone,
as mentioned before I am quite new to lightning dev. Should the questions
I'll ask be too basic please drop me a kind note and I will be more quite
or ask my questions on other places.
Today I studied Chrstian Deckers nice work about duplex micropayment
channels (
http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf
<https://www.google.com/url?q=http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf&sa=D&source=hangouts&ust=1520200459037000&usg=AFQjCNG3ZwxZzV6e3VYlLpemzn0ZCUIv-A>;
)
I am wondering what was the rational for the lightning spec (
https://github.com/lightningnetwork/lightning-rfc ) to go with the
revocation key system instead of the solution by Christian Decker to the
problem? I understand that the revocation system was already in the
whitepaper and at the time of writing the whitepaper the work by Christian
Decker wasn't out yet. But I guess this will not be the entire reason.
To me the key revocation system seems pretty complex to handle. In
particular as Rusty also mentioned on his article (c.f.
https://medium.com/@rusty_lightning/lightning-watching-for-cheaters-93d365d0d02f
) that already in the white paper people knew that potentially a third
party observing service to detect a cheater is needed. This seems to me
like a big drawback.
So what have been strong arguments to go with the revocation system?
On a side note I would like to state my respect to you: The lightning
network (in combination with bitcoin) is really the most beautiful piece of
technology I came across since I learnt about TCP/IP. Great work everybody
for creating such an amazing technology and bringing together all those
beautiful ideas. I am very confident that this technology will become
history.
best Rene
--
www.rene-pickhardt.de
<http://www.beijing-china-blog.com/>;
Skype: rene.pickhardt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180304/4359a7b0/attachment-0001.html>;
📝 Original message:
Hey everyone,
as mentioned before I am quite new to lightning dev. Should the questions
I'll ask be too basic please drop me a kind note and I will be more quite
or ask my questions on other places.
Today I studied Chrstian Deckers nice work about duplex micropayment
channels (
http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf
<https://www.google.com/url?q=http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf&sa=D&source=hangouts&ust=1520200459037000&usg=AFQjCNG3ZwxZzV6e3VYlLpemzn0ZCUIv-A>;
)
I am wondering what was the rational for the lightning spec (
https://github.com/lightningnetwork/lightning-rfc ) to go with the
revocation key system instead of the solution by Christian Decker to the
problem? I understand that the revocation system was already in the
whitepaper and at the time of writing the whitepaper the work by Christian
Decker wasn't out yet. But I guess this will not be the entire reason.
To me the key revocation system seems pretty complex to handle. In
particular as Rusty also mentioned on his article (c.f.
https://medium.com/@rusty_lightning/lightning-watching-for-cheaters-93d365d0d02f
) that already in the white paper people knew that potentially a third
party observing service to detect a cheater is needed. This seems to me
like a big drawback.
So what have been strong arguments to go with the revocation system?
On a side note I would like to state my respect to you: The lightning
network (in combination with bitcoin) is really the most beautiful piece of
technology I came across since I learnt about TCP/IP. Great work everybody
for creating such an amazing technology and bringing together all those
beautiful ideas. I am very confident that this technology will become
history.
best Rene
--
www.rene-pickhardt.de
<http://www.beijing-china-blog.com/>;
Skype: rene.pickhardt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180304/4359a7b0/attachment-0001.html>;