Topic: Lightning Network where are the transaction records stored? (Read 1198 times)
I predict huge numbers of Lightning channels opening in countries with good-enough internet infrastructure and low adherence to KYC/AML
Would it be the responsibility of the Lightening Hub to do full KYC/AML?
[2] is each transaction stored or is only the final decrement or increment stored or only
[2] Just the last one is useful to you as an honest man. There is a huge risk for anyone trying to get the previous state published, while it is a lot less risky for the honest counterpart in this attempt.Maybe there would be a reason to keep invalid transactions to prove they took place? If a pair of commercial partners has a dispute over whether or not a payment took place, records may be desirable in order to prove what happened (I guess this is highlighting a weakness of Lightning; no such problem can be exploited when transacting on-chain).
Is it a bug or a feature? When you pay your business partner in cash, you also need to ensure that you get a receipt.Now we introduce a technology, where transactions are moved away from the Blockchain into side channels, where they cannot be audited.
You can of course always choose to do a high value transaction on-chain. I see LN as a way to facilitate micropayments again, without high fees. I don't need to keep records of the coffee I bought, and even online orders should be delivered before the channel is closed.You might not want to know this information, but the regulating authorities might differ from you. The way Bitcoin is currently regulated in most countries, third party service providers has to adhere to KYC/AML regulations to track all transactions linked to individuals. If the LN can be used to hide micro transactions, it would not adhere to these regulations and you will find that governments will push for the Ban of these technologies, based on anonymity issues.
They tolerate Bitcoin users now, because they still adhere to the KYC/AML regulations, when they use these services.
[2] is each transaction stored or is only the final decrement or increment stored or only
[2] Just the last one is useful to you as an honest man. There is a huge risk for anyone trying to get the previous state published, while it is a lot less risky for the honest counterpart in this attempt.Interesting point. It seems like you would indeed need to find a way to regularly backup your channel state. However your counterparty doesn't know that you're not able to react to them broadcasting an older transaction, so the attack remains risky. Additionally, pretending to have lost the channel state (in whichever way you would go on about that) could actually be a profitable way to trick would-be attackers.
I fear you both misunderstood that the transaction that defines the current state is the one that secures from the attackers closing the channel with one of the previous states. The actual safety mechanism here is that secret keys are exchanged when the state changes along with the new transaction. These keys have nothing to do with the new state, they are just there to invalidate the old state. How these keys are stored, I don't know, but it makes sense that they are in the wallet. All the keys from all the previous states need to be kept, but not the transactions themselves.
There is an obvious added difficulty in using the Lightning network securely, as you not only need to keep these keys from the past states until the channel is closed, but you also need to be online every now and then to make sure that the other party didn't close the channel without you or was at least asking you to close it. However, in practice this should be fine, wallets need to be safe anyway without the manual backups as the recommended use of Bitcoin is to generate a new address for all the receiving funds for privacy reasons and create a new address where you keep the change whenever you send the funds instead of sending the change back to the same address for the security reasons.
[2] is each transaction stored or is only the final decrement or increment stored or only
[2] Just the last one is useful to you as an honest man. There is a huge risk for anyone trying to get the previous state published, while it is a lot less risky for the honest counterpart in this attempt.Interesting point. It seems like you would indeed need to find a way to regularly backup your channel state. However your counterparty doesn't know that you're not able to react to them broadcasting an older transaction, so the attack remains risky. Additionally, pretending to have lost the channel state (in whichever way you would go on about that) could actually be a profitable way to trick would-be attackers.
[2] is each transaction stored or is only the final decrement or increment stored or only
[2] Just the last one is useful to you as an honest man. There is a huge risk for anyone trying to get the previous state published, while it is a lot less risky for the honest counterpart in this attempt.Maybe there would be a reason to keep invalid transactions to prove they took place? If a pair of commercial partners has a dispute over whether or not a payment took place, records may be desirable in order to prove what happened (I guess this is highlighting a weakness of Lightning; no such problem can be exploited when transacting on-chain).
Is it a bug or a feature? When you pay your business partner in cash, you also need to ensure that you get a receipt.Now we introduce a technology, where transactions are moved away from the Blockchain into side channels, where they cannot be audited.
You can of course always choose to do a high value transaction on-chain. I see LN as a way to facilitate micropayments again, without high fees. I don't need to keep records of the coffee I bought, and even online orders should be delivered before the channel is closed. but how would you prove impartially your books are the correct record, when the other parties books say different?
The "books" would be the commitment transactions and their corresponding revoke_and_ack messages. The commitment transactions are signed by both parties, so you can prove that the balance for each transaction was agreed upon by both parties. The "books" cannot add transactions, only omit them. To prove that no transactions presented were omitted, you can use the per-commitment secrets and next per-commitment points in the revoke_and_ack messages to show which message corresponds to which transaction. If there is a revoke_and_ack message that has a next per-commitment point that is not used in any of the commitment transactions, then you know that at least one transaction was omitted.so ok, and if you wanted to post this book, for all to see, then you could and have some sort of explorer to pull out information. So say a highly connected and liquid channel may choose to publish its book and so provide a means to inspect records much like full node. Also thanks for the info.
[3] Yes. I mean no one can force you to delete them if you want to keep the locally, but they become invalid. Only the transaction for opening a channel and a transaction for closing the channel is stored on the blockchain.
Maybe there would be a reason to keep invalid transactions to prove they took place? If a pair of commercial partners has a dispute over whether or not a payment took place, records may be desirable in order to prove what happened (I guess this is highlighting a weakness of Lightning; no such problem can be exploited when transacting on-chain).
You make a very valid point. We have always said that one of Bitcoin's strongest features was that it promotes transparency. Every transaction made on the Blockchain can be tracked and proof of these transactions cannot be removed. Now we introduce a technology, where transactions are moved away from the Blockchain into side channels, where they cannot be audited.
I assume that this is the same with third party services like Xapo, who makes use of off-chain transactions, so it is nothing new. Only difference is, Xapo can be audited, because they keep logs of all transactions that are being made through their services.
but how would you prove impartially your books are the correct record, when the other parties books say different?
The "books" would be the commitment transactions and their corresponding revoke_and_ack messages. The commitment transactions are signed by both parties, so you can prove that the balance for each transaction was agreed upon by both parties. The "books" cannot add transactions, only omit them. To prove that no transactions presented were omitted, you can use the per-commitment secrets and next per-commitment points in the revoke_and_ack messages to show which message corresponds to which transaction. If there is a revoke_and_ack message that has a next per-commitment point that is not used in any of the commitment transactions, then you know that at least one transaction was omitted. [3] Yes. I mean no one can force you to delete them if you want to keep the locally, but they become invalid. Only the transaction for opening a channel and a transaction for closing the channel is stored on the blockchain.
Maybe there would be a reason to keep invalid transactions to prove they took place? If a pair of commercial partners has a dispute over whether or not a payment took place, records may be desirable in order to prove what happened (I guess this is highlighting a weakness of Lightning; no such problem can be exploited when transacting on-chain).
How can it be exploited if both parties keep track of and agree on each transaction that takes place while the channel is open? The involved parties are able to see whether they received the correct amount each step along the way. Whether the selling party actually delivered the goods or services for the payment received is neither LN's nor the blockchain's responsibility.
Apart from that commercial partners need to keep books either way, regardless of whether they get paid on-chain, off-chain, via traditional banking or in cash.
but how would you prove impartially your books are the correct record, when the other parties books say different?
[3] Yes. I mean no one can force you to delete them if you want to keep the locally, but they become invalid. Only the transaction for opening a channel and a transaction for closing the channel is stored on the blockchain.
Maybe there would be a reason to keep invalid transactions to prove they took place? If a pair of commercial partners has a dispute over whether or not a payment took place, records may be desirable in order to prove what happened (I guess this is highlighting a weakness of Lightning; no such problem can be exploited when transacting on-chain).
The current state proves it all. It takes both parties to agree on it. If you agree that the balance between the two is as said in the current state, then other older transactions aren't important.
[3] Yes. I mean no one can force you to delete them if you want to keep the locally, but they become invalid. Only the transaction for opening a channel and a transaction for closing the channel is stored on the blockchain.
Maybe there would be a reason to keep invalid transactions to prove they took place? If a pair of commercial partners has a dispute over whether or not a payment took place, records may be desirable in order to prove what happened (I guess this is highlighting a weakness of Lightning; no such problem can be exploited when transacting on-chain).
How can it be exploited if both parties keep track of and agree on each transaction that takes place while the channel is open? The involved parties are able to see whether they received the correct amount each step along the way. Whether the selling party actually delivered the goods or services for the payment received is neither LN's nor the blockchain's responsibility.
Apart from that commercial partners need to keep books either way, regardless of whether they get paid on-chain, off-chain, via traditional banking or in cash.
[3] Yes. I mean no one can force you to delete them if you want to keep the locally, but they become invalid. Only the transaction for opening a channel and a transaction for closing the channel is stored on the blockchain.
Maybe there would be a reason to keep invalid transactions to prove they took place? If a pair of commercial partners has a dispute over whether or not a payment took place, records may be desirable in order to prove what happened (I guess this is highlighting a weakness of Lightning; no such problem can be exploited when transacting on-chain).
[1]So when a channel is open where are the records stored?
[2] is each transaction stored or is only the final decrement or increment stored or only
[3] When a channel is closed are all the records gone excepting the final records and do they have to go to the blockchain at that point?
[2] is each transaction stored or is only the final decrement or increment stored or only
[3] When a channel is closed are all the records gone excepting the final records and do they have to go to the blockchain at that point?
Short answer:
[1] Just like any other unconfirmed transactions, that is also a secret to the network. So imagine a hidden mempool. Secret signed unconfirmed transactions.
[2] Just the last one is useful to you as an honest man. There is a huge risk for anyone trying to get the previous state published, while it is a lot less risky for the honest counterpart in this attempt.
[3] Yes. I mean no one can force you to delete them if you want to keep the locally, but they become invalid. Only the transaction for opening a channel and a transaction for closing the channel is stored on the blockchain.
[1] So when a channel is open where are the records stored?
[2] is each transaction stored or is only the final decrement or increment stored or only
[3] When a channel is closed are all the records gone excepting the final records and do they have to go to the blockchain at that point?
[2] is each transaction stored or is only the final decrement or increment stored or only
[3] When a channel is closed are all the records gone excepting the final records and do they have to go to the blockchain at that point?
This document has a lot of the answers to your questions.
https://lightning.network/lightning-network-paper.pdf
https://lightning.network/lightning-network-paper.pdf
This document is really what you need to read. It explains in details the proposal and how it does work. I will quote below some sentences from the above document. As far as I know, the balances are updated between cooperating parties (lets say Alice and Bob) in the channel. To broadcast, the channel can use a timelock. Also, when parties disagree, the last agreed transaction is broadcasted. Close a channel means broadcast the channel balance/last transaction. I suggest you to read the paper though...
"Instead, both parties can commit to signing a transaction and not broadcasting this transaction. So if Alice and Bob commit funds into a 2-of-2 multisignature address (where it requires consent from both parties to create spends), they can agree on the current balance state [...] This refund is not broadcast on the blockchain." page 5
"In the case of micropayment channels, only two states are required: the current correct balance, and any old deprecated balances." page 5
"This invalidation process can exist through a process of channel consensus where if both parties agree on current ledger states (and building new states), then the real balance gets updated. The balance is reflected on the blockchain only when a single party disagrees." page 6
"By encumbering the Bitcoin transaction outputs with a hashlock and timelock, the channel counterparty will be unable to outright steal funds and Bitcoins can be exchanged without outright counterparty theft. Further, by using staggered timeouts, it’s possible to send funds via multiple intermediaries in a network without the risk of intermediary theft of funds." page 6
"Both parties can update the balance inside the channel with whatever output balances they wish, so long as it’s equal or less than the total funds committed inside the Funding Transaction; balances can move in both directions." page 29
This document has a lot of the answers to your questions.
https://lightning.network/lightning-network-paper.pdf
https://lightning.network/lightning-network-paper.pdf
[1]So when a channel is open where are the records stored?
[2] is each transaction stored or is only the final decrement or increment stored or only
[3] When a channel is closed are all the records gone excepting the final records and do they have to go to the blockchain at that point?
[2] is each transaction stored or is only the final decrement or increment stored or only
[3] When a channel is closed are all the records gone excepting the final records and do they have to go to the blockchain at that point?
Jump to: