Mats Jerratsch [ARCHIVE] on Nostr: š
Original date posted:2015-07-20 š Original message: Hey everybody, I'm ...
š
Original date posted:2015-07-20
š Original message:
Hey everybody,
I'm currently working on a Lightning Implementation Client/Server in
Java, building on bitcoinj (just as a basic framework, I wrote my own
classes to realize LN). Will push it into GitHub within a few weeks I
guess.
I had an implementation ready, that would not need any further changes
for bitcoin (works today already), but I just threw it all off the
ship, reading through your paper. It was based on some trust
dependencies and channel transactions were highly asynchronous,
meaning that a LN-Network would not be possible (since one party will
always be assumed lower trust and therefore has a disadvantage in
enforcing the ruleset). I can share further details if there is any
interest (it further needed to exchange 3 transactions for each
payment in the channel, building up huge amount of data within a few
hundred payments....)
First I wanted to write up my solution for the anchor problem, but
then I realized, your solution makes it possible to have channels open
indefinitely, while mine doesn't. And while it really looks fishy,
indefinite channels are really worth it. However, it is important to
wait for the anchor tx of the other party. Otherwise the server has to
pay transaction fees for releasing his funds again and again (which
can really add up..).
While implementing the new redeemscripts, I noticed there is no delay
for the 'HTLC Receiver Redeemscript', when redeeming the contract
using R. Doesn't this mean that revoked or not, if the receiver has R,
he can instantly claim these outputs. Let's assume a channel with 4
states:
t=t0 - client has no funds in the channel (or very little, he wants to
receive money)
t=t1 - client has received funds and has lots of unsettled payments in
his channel
t=t2 - client settled with the server (revealed R)
t=t3 - client has spent all funds again
At t=t3, the client has no incentive anymore to play with the rules,
since there's nothing he can lose (his balance is zero after all..).
So he can broadcast the channel transaction from t1 and instantly
claim all outputs using R. While the server can technically claim the
funds aswell, using the COMMIT-REVOCATION-HASH, it boils down to a
race. I'm not really sure if this will solve the issue completely, but
I think OP_CSV after OP_DROP will mitigate this by ensuring some
delay. This is especially important other way round, as clients won't
be online all the time and the delay here really determines how often
the client has to check back.
Really good work though, although I just had to delete and rewrite a
good share of my work. ;)
Published at
2023-06-09 12:43:42Event JSON
{
"id": "5df19186be73915fc3b39279b370cc06e6865ce400fba9dd847669101b28a06a",
"pubkey": "b8a27d18150405cdfcd44c0dd8db860f5270312300248389bf57ce555c784528",
"created_at": 1686314622,
"kind": 1,
"tags": [
[
"e",
"84a26c949026f6572e0a37454722650bd1142f2fced38eef6c55935d3b1ffdc3",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "š
Original date posted:2015-07-20\nš Original message:\nHey everybody,\n\nI'm currently working on a Lightning Implementation Client/Server in\nJava, building on bitcoinj (just as a basic framework, I wrote my own\nclasses to realize LN). Will push it into GitHub within a few weeks I\nguess.\n\nI had an implementation ready, that would not need any further changes\nfor bitcoin (works today already), but I just threw it all off the\nship, reading through your paper. It was based on some trust\ndependencies and channel transactions were highly asynchronous,\nmeaning that a LN-Network would not be possible (since one party will\nalways be assumed lower trust and therefore has a disadvantage in\nenforcing the ruleset). I can share further details if there is any\ninterest (it further needed to exchange 3 transactions for each\npayment in the channel, building up huge amount of data within a few\nhundred payments....)\n\nFirst I wanted to write up my solution for the anchor problem, but\nthen I realized, your solution makes it possible to have channels open\nindefinitely, while mine doesn't. And while it really looks fishy,\nindefinite channels are really worth it. However, it is important to\nwait for the anchor tx of the other party. Otherwise the server has to\npay transaction fees for releasing his funds again and again (which\ncan really add up..).\n\nWhile implementing the new redeemscripts, I noticed there is no delay\nfor the 'HTLC Receiver Redeemscript', when redeeming the contract\nusing R. Doesn't this mean that revoked or not, if the receiver has R,\nhe can instantly claim these outputs. Let's assume a channel with 4\nstates:\n\nt=t0 - client has no funds in the channel (or very little, he wants to\nreceive money)\nt=t1 - client has received funds and has lots of unsettled payments in\nhis channel\nt=t2 - client settled with the server (revealed R)\nt=t3 - client has spent all funds again\n\nAt t=t3, the client has no incentive anymore to play with the rules,\nsince there's nothing he can lose (his balance is zero after all..).\nSo he can broadcast the channel transaction from t1 and instantly\nclaim all outputs using R. While the server can technically claim the\nfunds aswell, using the COMMIT-REVOCATION-HASH, it boils down to a\nrace. I'm not really sure if this will solve the issue completely, but\nI think OP_CSV after OP_DROP will mitigate this by ensuring some\ndelay. This is especially important other way round, as clients won't\nbe online all the time and the delay here really determines how often\nthe client has to check back.\n\nReally good work though, although I just had to delete and rewrite a\ngood share of my work. ;)",
"sig": "2ddf40e7ec59d6385b7c030ef7016d702df772888bf3d16786396566ca14334f4e39dd7a098f1ef4ceebb2f33910001f93f76b7eb6342f5242849b5283aab5b8"
}