📅 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
Joseph Poon [ARCHIVE] /
npub1ej…p9cq8
2023-06-09 12:43:59
in reply to nevent1q…mnhd
Author Public Key
npub1ej6vep7y2km5l6awukffelg8yeppkth2vjkjk9jypd5w336rxggs3p9cq8Published at
2023-06-09 12:43:59Event JSON
{
"id": "b91a2f909ebd27cf84fd9d3eea8e55f8cb57a0203f1bcccffec9e4ed540d1db6",
"pubkey": "ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211",
"created_at": 1686314639,
"kind": 1,
"tags": [
[
"e",
"66681ffe7bd947a6d8c9a87dbb7582790b0efc37d305797619761486e2dc1149",
"",
"root"
],
[
"e",
"c37dee6be3ef74fb95444d460fdf53044846bc81c37849957af9e6072f090662",
"",
"reply"
],
[
"p",
"b8a27d18150405cdfcd44c0dd8db860f5270312300248389bf57ce555c784528"
]
],
"content": "📅 Original date posted:2015-08-11\n📝 Original message:\nHi Mats,\n\nOn Tue, Aug 11, 2015 at 10:44:27PM +0200, Mats Jerratsch wrote:\n\u003e Do you mind if I start calling it a Lightning Network Implementation\n\u003e then? ;)\n\nI can't stop you from calling it whatever you want, however, I'm just\nconcerned with any system which has some implicit level of trust,\nespecially with long-term systemic risks (e.g. implications for\nfungibility, and other social accessibility costs). The goal of LN is to\nallow you to connect to anyone without the risk of the counterparty\noutright stealing or encumbering funds. \n\nSo if the purpose is to get it working today with some trust\ncompromises, then any potential design trust issues may be associated\nwith LN. I don't want to encourage the use of systems which lets you\nmaliciously encumber HTLC funds in transit and funding on main-net. As\nmuch as I would absolutely appreciate how a semi-trusted implementation\nwould help counter the \"Lightning doesn't exist\" meme, it seems simpler\nto test with the new opcodes using dummy opcodes on testnet. I think we\nneed not only the opcodes, but also long-term I see some kind of\nmalleability fix and timestop as ideal if not necessary.\n\n\u003e Also note that both these problems can be eliminated with OP_CLTV,\n\u003e which will be implemented at least somewhat soon.\n\nYes, if it uses the new opcodes similar to Rusty's construction, then\nit's a LN implementation for sure (it will especially help with HTLCs in\ntransit). Do you expect any significant differences (beyond a balance\nreserve for just OP_CLTV)? I think a bitcoinj implementation of\nLightning is sorely needed, for sure, and greatly appreciate any\nimplementation, as it's a huge positive step for the bitcoin ecosystem!\nI feel like we might have gotten off on the wrong foot here (partially\ndue to me misunderstanding the design), I think we both agree that\nscalability of bitcoin micropayments is something that is very important\nto the wider ecosystem and I'm looking forward to continuing developing\nthese techonlogies with you!\n\n-- \nJoseph Poon",
"sig": "177c394888fccd0f55665b30594022af65494f7904528e2914c3562b8e1c2707bb267cee0689aa6e08b932caabe0195a3e3768256bb58c89c3b73cd1e6d80ba4"
}