Joseph Poon [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-11 📝 Original message: Hi Mats, On Tue, Aug 11, ...
📅 Original date posted:2015-08-11
📝 Original message:
Hi Mats,
On Tue, Aug 11, 2015 at 10:44:27PM +0200, Mats Jerratsch wrote:
> Do you mind if I start calling it a Lightning Network Implementation
> then? ;)
I can't stop you from calling it whatever you want, however, I'm just
concerned with any system which has some implicit level of trust,
especially with long-term systemic risks (e.g. implications for
fungibility, and other social accessibility costs). The goal of LN is to
allow you to connect to anyone without the risk of the counterparty
outright stealing or encumbering funds.
So if the purpose is to get it working today with some trust
compromises, then any potential design trust issues may be associated
with LN. I don't want to encourage the use of systems which lets you
maliciously encumber HTLC funds in transit and funding on main-net. As
much as I would absolutely appreciate how a semi-trusted implementation
would help counter the "Lightning doesn't exist" meme, it seems simpler
to test with the new opcodes using dummy opcodes on testnet. I think we
need not only the opcodes, but also long-term I see some kind of
malleability fix and timestop as ideal if not necessary.
> Also note that both these problems can be eliminated with OP_CLTV,
> which will be implemented at least somewhat soon.
Yes, if it uses the new opcodes similar to Rusty's construction, then
it's a LN implementation for sure (it will especially help with HTLCs in
transit). Do you expect any significant differences (beyond a balance
reserve for just OP_CLTV)? I think a bitcoinj implementation of
Lightning is sorely needed, for sure, and greatly appreciate any
implementation, as it's a huge positive step for the bitcoin ecosystem!
I feel like we might have gotten off on the wrong foot here (partially
due to me misunderstanding the design), I think we both agree that
scalability of bitcoin micropayments is something that is very important
to the wider ecosystem and I'm looking forward to continuing developing
these techonlogies with you!
--
Joseph Poon
📝 Original message:
Hi Mats,
On Tue, Aug 11, 2015 at 10:44:27PM +0200, Mats Jerratsch wrote:
> Do you mind if I start calling it a Lightning Network Implementation
> then? ;)
I can't stop you from calling it whatever you want, however, I'm just
concerned with any system which has some implicit level of trust,
especially with long-term systemic risks (e.g. implications for
fungibility, and other social accessibility costs). The goal of LN is to
allow you to connect to anyone without the risk of the counterparty
outright stealing or encumbering funds.
So if the purpose is to get it working today with some trust
compromises, then any potential design trust issues may be associated
with LN. I don't want to encourage the use of systems which lets you
maliciously encumber HTLC funds in transit and funding on main-net. As
much as I would absolutely appreciate how a semi-trusted implementation
would help counter the "Lightning doesn't exist" meme, it seems simpler
to test with the new opcodes using dummy opcodes on testnet. I think we
need not only the opcodes, but also long-term I see some kind of
malleability fix and timestop as ideal if not necessary.
> Also note that both these problems can be eliminated with OP_CLTV,
> which will be implemented at least somewhat soon.
Yes, if it uses the new opcodes similar to Rusty's construction, then
it's a LN implementation for sure (it will especially help with HTLCs in
transit). Do you expect any significant differences (beyond a balance
reserve for just OP_CLTV)? I think a bitcoinj implementation of
Lightning is sorely needed, for sure, and greatly appreciate any
implementation, as it's a huge positive step for the bitcoin ecosystem!
I feel like we might have gotten off on the wrong foot here (partially
due to me misunderstanding the design), I think we both agree that
scalability of bitcoin micropayments is something that is very important
to the wider ecosystem and I'm looking forward to continuing developing
these techonlogies with you!
--
Joseph Poon