📅 Original date posted:2016-05-30
📝 Original message:
Thats a cool idea! Instead of directed 1-to-1 payment channels, it would rather look like a cloud with multiple parties connected.
Apart from the (*huge*) added complexity and engineering work to make that happen, I see another problem with it though.
In case a participant cheats and broadcasts an old channel transaction - how do you determine the correct payout to the other participants?
Say there are 5 parties, each contributing 1 BTC.
Now after numerous payments, we end up in a state where Alice gets 4 BTC and B-E get 0.25 each. If one of the party now broadcasts an old transaction which held the initial state, how could you possibly make the blockchain cognitive to the correct payout? And what would be a correct payout to begin with?
Is it:
A: 4.0625
B: 0.3125
C: 0.3125
D: 0.3125
E: nothing (cheated)
so splitting up the balance of the cheating party equally, or is it more correct to split it proportionally?
The only way how I see this working right now is returning back to the schema of decreasing nLocktime with each update. It would make broadcasting old states impossible, as the current state has a lower nLocktime. It also means returning to very limited lifetime per channel though (you talked about timeout, is that what you meant?). With so many parties involved, it would lead to drastically increased on-chain activity (or very high refund timeouts where you can’t access your money).
It seems like you have it all thought out already, can you go into a bit more detail on your proposal? :)
I’m also interested in how exactly you would make it work, with only needing the spending party to resign the transaction. (which I cannot think of how to work out combined with the nLocktime-approach)
Cheers!
Mats
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160530/f8dd3cc6/attachment.sig>;
Mats Jerratsch [ARCHIVE] /
npub1hz…q5x8w
2023-06-09 12:46:19
in reply to nevent1q…7jl0
Author Public Key
npub1hz386xq4qszumlx5fsxa3kuxpaf8qvfrqqjg8zdl2l892hrcg55q6q5x8wPublished at
2023-06-09 12:46:19Event JSON
{
"id": "36fff8964872c2ecbca1b7f8b6269e8c7be9ae6298606eba69ac0b5a9f04970b",
"pubkey": "b8a27d18150405cdfcd44c0dd8db860f5270312300248389bf57ce555c784528",
"created_at": 1686314779,
"kind": 1,
"tags": [
[
"e",
"a3e59493874a05fc0285537ca7614253629d9127125e3ab6f5f79b1f30e3481a",
"",
"root"
],
[
"e",
"673ac6928afe62bde689c68cae396849cc65c4c6375e56a87c0f95113d73a122",
"",
"reply"
],
[
"p",
"46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e"
]
],
"content": "📅 Original date posted:2016-05-30\n📝 Original message:\nThats a cool idea! Instead of directed 1-to-1 payment channels, it would rather look like a cloud with multiple parties connected.\n\nApart from the (*huge*) added complexity and engineering work to make that happen, I see another problem with it though.\n\nIn case a participant cheats and broadcasts an old channel transaction - how do you determine the correct payout to the other participants?\n\nSay there are 5 parties, each contributing 1 BTC.\nNow after numerous payments, we end up in a state where Alice gets 4 BTC and B-E get 0.25 each. If one of the party now broadcasts an old transaction which held the initial state, how could you possibly make the blockchain cognitive to the correct payout? And what would be a correct payout to begin with?\n\nIs it:\n\nA: 4.0625\nB: 0.3125\nC: 0.3125\nD: 0.3125\nE: nothing (cheated)\n\nso splitting up the balance of the cheating party equally, or is it more correct to split it proportionally?\n\n\nThe only way how I see this working right now is returning back to the schema of decreasing nLocktime with each update. It would make broadcasting old states impossible, as the current state has a lower nLocktime. It also means returning to very limited lifetime per channel though (you talked about timeout, is that what you meant?). With so many parties involved, it would lead to drastically increased on-chain activity (or very high refund timeouts where you can’t access your money).\n\nIt seems like you have it all thought out already, can you go into a bit more detail on your proposal? :)\nI’m also interested in how exactly you would make it work, with only needing the spending party to resign the transaction. (which I cannot think of how to work out combined with the nLocktime-approach)\n\nCheers!\nMats\n\u003e \n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160530/f8dd3cc6/attachment.sig\u003e",
"sig": "b69c39459fd60ae6180d602c79ae7e67157ba96e61f3aabcda7ccaa29223d31179a3ba0428065a455a75b57041e58d517b2db027b3615016621fcd06302f54dd"
}