Topic: [Complete] A fortnight of lessons on the lightning network (Read 722 times)
Bump!
I thought I'd just add that it says at the bottom of the paper they're expecting a new draft. I'll be happy to change the above in compliance with that (or add new days).
That paper wasn't yet everything and we still have a lot to grow in this space.
That paper wasn't yet everything and we still have a lot to grow in this space.
• Transaction malleability means that transactions can be mutated and added to the blockchain without extensions to the protocol to ensure for sequence number validation and setting expiry times. Without the being resolved it opens up the possibility for an attack vector for a hostage of funds unless the user agrees to split the funds with them.
▪ This would require a soft fork for miner software in order to fix how they handle transactions, core nodes wouldn’t be affected unless they wanted to change to match a more accurate mempool but that might be unnecessary.
▪ The 20 byte SIGHASH
◦ The software should include an additional input script of OP_CHECKSIG or a new address type altogether for the additional data to be stored as: OP_DUP OP_HASH160 <20 byte hash> OP_EQUALVERIFY.
◦ All existing clients will return true for this command if the appropriate redeemScript of the P2SH transaction is given.
◦ SIGHASHNOINPUT makes it impossible for an attacker to invalidate an entire transaction tree by publishing an old transaction. This means the input script of the transaction doesn’t need a valid UTXOID, so that even though the output being spent may be invalid, a new output may be filled in the transaction instead (one that is valid).
▪ By solving malleability, both parties can spend transactions without knowing the outputs of the previous transaction and are also able to invalidate old transactions.
▪ Under the current paradigm, when opening a channel you have to commit funds before making the first Commitment Transaction which means your funds have to be committed and the other party must give you access to funds otherwise they’ll be stuck until they do. It wouldn’t even be possible to use an output tx hash that they gave you as it still relies on both your funding transactions to return the same output and they could lie as to what theirs was in order to stop you from spending it.
▪ This would require a soft fork for miner software in order to fix how they handle transactions, core nodes wouldn’t be affected unless they wanted to change to match a more accurate mempool but that might be unnecessary.
▪ The 20 byte SIGHASH
◦ The software should include an additional input script of OP_CHECKSIG or a new address type altogether for the additional data to be stored as: OP_DUP OP_HASH160 <20 byte hash> OP_EQUALVERIFY.
◦ All existing clients will return true for this command if the appropriate redeemScript of the P2SH transaction is given.
◦ SIGHASHNOINPUT makes it impossible for an attacker to invalidate an entire transaction tree by publishing an old transaction. This means the input script of the transaction doesn’t need a valid UTXOID, so that even though the output being spent may be invalid, a new output may be filled in the transaction instead (one that is valid).
▪ By solving malleability, both parties can spend transactions without knowing the outputs of the previous transaction and are also able to invalidate old transactions.
▪ Under the current paradigm, when opening a channel you have to commit funds before making the first Commitment Transaction which means your funds have to be committed and the other party must give you access to funds otherwise they’ll be stuck until they do. It wouldn’t even be possible to use an output tx hash that they gave you as it still relies on both your funding transactions to return the same output and they could lie as to what theirs was in order to stop you from spending it.
Scalability issues
• If every user wanted to make only 3 transactions a year, the blockchain could only handle around 35 million users at 500 bytes a tx (2 in at 140-200 bytes and 2 out at 40 bytes and).
• If we need to accomodate for this then a hard fork would be required meaning all previous nodes will have to update to maintain their wallets compatiblity and ability to send transactions
• Miner code will also have to be updated and nodes and miners must decide on their consensus rules so that all are compatible (i.e a miner might try to not recognise blocks higher than 1MB in size) - to get around this issue a soft-cap can be added whereby a certain limit is imposed onto miners but they don't have to fully respect it in order to get their reward and get the block accepted. This would also cut down on the amount of hard forks that would be needed.
• For HTLC revocations and channel closures, a high fee could be involved meaning that miners are more likely to accept and process the transaction sooner. The non-cooperative closures can then be included above the soft cap but still below some sort of hard cap imposed by nodes.
These strategies would therefore make it hard or almost impossible for an attacker to gain control of funds unless they spend a lot to disrupt the mempool (in which the funds will be lost and they might not even succeed). Also since HTLCs and Channels are generally recommended to be done with smaller amounts, a channel owner should find it easier to absorb the loss and normally don't open channels with random people if they have a high amount of funds (or they can segregate that amount for only connecting with trusted parties).
Extra uses of the lightning network
• Instant transactions: on the lightning network with a cooperative party, transactions can be done within seconds.
• Exchange arbitrage: if a large market swing occurs, people can quickly move their funds from one exchange to another and demand a higher price for their cryptocurrency without having to wait longer for a confirmation - bank transfers to coinbase can take 15 minutes or less from some countries.
• Micropayments - most transaction son the bitcoin blockhain need a fee of at least 128 sats. If the price does well this could become a higher and higher amount to spend each time.
• It offers smart contracts and escrow opportunities without compromising the security of bitcoin's main chain.
• Hops on the network can be done between different coin chains. If Alice has 0.1BTC and there is no direct route to Bob to pay him, But chris and david both have Litecoin Channels open then the similar amount of funds can be transferred between them in the transaction and allow for alice and bob to still send funds (Disclaimer: I have no idea if litecoin is compatible I just picked my favourite to shill
).
• If every user wanted to make only 3 transactions a year, the blockchain could only handle around 35 million users at 500 bytes a tx (2 in at 140-200 bytes and 2 out at 40 bytes and).
• If we need to accomodate for this then a hard fork would be required meaning all previous nodes will have to update to maintain their wallets compatiblity and ability to send transactions
• Miner code will also have to be updated and nodes and miners must decide on their consensus rules so that all are compatible (i.e a miner might try to not recognise blocks higher than 1MB in size) - to get around this issue a soft-cap can be added whereby a certain limit is imposed onto miners but they don't have to fully respect it in order to get their reward and get the block accepted. This would also cut down on the amount of hard forks that would be needed.
• For HTLC revocations and channel closures, a high fee could be involved meaning that miners are more likely to accept and process the transaction sooner. The non-cooperative closures can then be included above the soft cap but still below some sort of hard cap imposed by nodes.
These strategies would therefore make it hard or almost impossible for an attacker to gain control of funds unless they spend a lot to disrupt the mempool (in which the funds will be lost and they might not even succeed). Also since HTLCs and Channels are generally recommended to be done with smaller amounts, a channel owner should find it easier to absorb the loss and normally don't open channels with random people if they have a high amount of funds (or they can segregate that amount for only connecting with trusted parties).
Extra uses of the lightning network
• Instant transactions: on the lightning network with a cooperative party, transactions can be done within seconds.
• Exchange arbitrage: if a large market swing occurs, people can quickly move their funds from one exchange to another and demand a higher price for their cryptocurrency without having to wait longer for a confirmation - bank transfers to coinbase can take 15 minutes or less from some countries.
• Micropayments - most transaction son the bitcoin blockhain need a fee of at least 128 sats. If the price does well this could become a higher and higher amount to spend each time.
• It offers smart contracts and escrow opportunities without compromising the security of bitcoin's main chain.
• Hops on the network can be done between different coin chains. If Alice has 0.1BTC and there is no direct route to Bob to pay him, But chris and david both have Litecoin Channels open then the similar amount of funds can be transferred between them in the transaction and allow for alice and bob to still send funds (Disclaimer: I have no idea if litecoin is compatible I just picked my favourite to shill
).
One of the biggest risks of the lightning network is that core nodes and merchants must leave the private keys for their channels on online devices, they can airgap private keys for blockchain funds separately but it'd be difficult to do this with the lightning network.
Editor note: it's also not possible to partioally close a channel as far as I can tell meaning the user may have to trust a third party to try to transfer their funds out of a channel.
Timelock issues:
The initial party wanting to send funds must set a timelock themselves, if the timelock is too short they will be able to access their fudns before the transaction is complete meaning that the other party used in transferring the funds may have their funds stolen. This means speical attention must be given when writing the software to ensure noncompliant nodes don't meddle with other users funds and that the most recent state is able to be broadcast and accepted by the blockchain.
Forced expiration spam:
• This would occur by spamming the mempool with transactions higher in fee than the HTLC transaction in order to make it become invalid and allow the spammer to steal back their funds once a certain time has passed.
To mitigate thie risk it would be possible to use sequence number whereby a penalty must be published with an even sequence number and commitment transactions with an odd number. If the commitment transaction published has an odd number then the even numbered transactions would be easy to spot in the mempool.
Editor's note: this doesn't seem to suggest anything over mitigating the issue of sharing private keys after each commitment transaction as surely a user can just sign an odd commitment transaction (old one) and a new commitment transaction with a higher (and even) sequence number.... (but maybe I have this wrong). This would, however, work with only a slight tweek to the mempool validation since the next transaction could be compared to the first and if it credits the user that didn't publish the first one and they've already signed that commitment transaction in the past to acclaim it's their address then they could receive a reimbursement of their funds and the penalty.
• A recommended solution to reduce the amount of risk involved in this process is to send large amounts in multiple transactions since lightning network fees are pretty low. This would mean that each HTLC would have to be closed cooperatively or the user can only take a tiny amount of funds each time.
• If a spam attack happens on the blockchain, there is also a chance that the blocks can resize dynamically in order to fit certain lightning transactions from uncooperative channels.
Hacker theft:
• It is better that a node leave it's channels with little funds in them and the extra funds needed can be outsourced to other nodes or handled by people with more secure nodes.
• Nodes with a higher level of security (less prone to hacking or accidentally publishing keys somehow
) should be able to have more funds online and be able to partake in more transactions and potentially charge higher fess.
• There seems to be a mention of an idea to allow for a way to send outputs from a commitment transaction so a user is able to push their funds back onto the blockchain and storing them with airgapped keys (presumably the other party credits themselves in the commitment transaction and pushes funds out to the other person after that - or the channel is forclosed and instantly reopened after the hour for 6 confirmations).
Data loss:
This would mean a user would not be able to publish their most recent commitment transaction and dispute one if it gets published which can be resolved by having a third party store the channel data in an encrypted format they can't access (the user would still have to hold onto their seed nmemonic in order to regain access to their funds and claim the other party published an invalid/outdated Commitment).
Late broadcasts
A third party can charge a fee either before or after the service is provided whereby they will oversee the users' channels and check no outdated commitment transactions are being published. However, OP_CHECKSEQUENCEVERIFY may come in handy for this too to make it take a long enough time for the user to not notice before they lose their funds.
Miner collusion:
It is possible miners could be paid to not broadcast or mine a transaction.
For this not to occur it should be made harder for miner blocks to be identified as to where they have come from.
There is also a chance a miner could take a fee, identify all of their blocks as not mining the thief's coin and then mine a block that has a coinbase funding a different one of their addresses that they just don't prove belongs to them, meaning the thief has lost all of their funds and the fees paid to the miners and this may be enough of an inccentive for theives to not want to do this type of attack (as well as it being hard to arrange and successfully carry out).
Editor note: it's also not possible to partioally close a channel as far as I can tell meaning the user may have to trust a third party to try to transfer their funds out of a channel.
Timelock issues:
The initial party wanting to send funds must set a timelock themselves, if the timelock is too short they will be able to access their fudns before the transaction is complete meaning that the other party used in transferring the funds may have their funds stolen. This means speical attention must be given when writing the software to ensure noncompliant nodes don't meddle with other users funds and that the most recent state is able to be broadcast and accepted by the blockchain.
Forced expiration spam:
• This would occur by spamming the mempool with transactions higher in fee than the HTLC transaction in order to make it become invalid and allow the spammer to steal back their funds once a certain time has passed.
To mitigate thie risk it would be possible to use sequence number whereby a penalty must be published with an even sequence number and commitment transactions with an odd number. If the commitment transaction published has an odd number then the even numbered transactions would be easy to spot in the mempool.
Editor's note: this doesn't seem to suggest anything over mitigating the issue of sharing private keys after each commitment transaction as surely a user can just sign an odd commitment transaction (old one) and a new commitment transaction with a higher (and even) sequence number.... (but maybe I have this wrong). This would, however, work with only a slight tweek to the mempool validation since the next transaction could be compared to the first and if it credits the user that didn't publish the first one and they've already signed that commitment transaction in the past to acclaim it's their address then they could receive a reimbursement of their funds and the penalty.
• A recommended solution to reduce the amount of risk involved in this process is to send large amounts in multiple transactions since lightning network fees are pretty low. This would mean that each HTLC would have to be closed cooperatively or the user can only take a tiny amount of funds each time.
• If a spam attack happens on the blockchain, there is also a chance that the blocks can resize dynamically in order to fit certain lightning transactions from uncooperative channels.
Hacker theft:
• It is better that a node leave it's channels with little funds in them and the extra funds needed can be outsourced to other nodes or handled by people with more secure nodes.
• Nodes with a higher level of security (less prone to hacking or accidentally publishing keys somehow
) should be able to have more funds online and be able to partake in more transactions and potentially charge higher fess. • There seems to be a mention of an idea to allow for a way to send outputs from a commitment transaction so a user is able to push their funds back onto the blockchain and storing them with airgapped keys (presumably the other party credits themselves in the commitment transaction and pushes funds out to the other person after that - or the channel is forclosed and instantly reopened after the hour for 6 confirmations).
Data loss:
This would mean a user would not be able to publish their most recent commitment transaction and dispute one if it gets published which can be resolved by having a third party store the channel data in an encrypted format they can't access (the user would still have to hold onto their seed nmemonic in order to regain access to their funds and claim the other party published an invalid/outdated Commitment).
Late broadcasts
A third party can charge a fee either before or after the service is provided whereby they will oversee the users' channels and check no outdated commitment transactions are being published. However, OP_CHECKSEQUENCEVERIFY may come in handy for this too to make it take a long enough time for the user to not notice before they lose their funds.
Miner collusion:
It is possible miners could be paid to not broadcast or mine a transaction.
For this not to occur it should be made harder for miner blocks to be identified as to where they have come from.
There is also a chance a miner could take a fee, identify all of their blocks as not mining the thief's coin and then mine a block that has a coinbase funding a different one of their addresses that they just don't prove belongs to them, meaning the thief has lost all of their funds and the fees paid to the miners and this may be enough of an inccentive for theives to not want to do this type of attack (as well as it being hard to arrange and successfully carry out).
More on htlcs and payment arrangements
It's recommended only a small amount is used per timelocked contract (HTLC) due to the prospect of the funds not reaching their appropriate due to an uncooperative party and their funds being locked up in the contract (potentially). It isn't possible for them to arrange for a reroute with the locked funds either.
If higher amounts a used, nodes may call for higher transaction fees to be paid on the transaction they're helping and locking thier funds up for. It's also better tot ry to reduce the number of hops between you and the designate node as you can incur a fee from each node (editor note: a lot of wallets have a built in function to limit the fees that can be charged).
If a transaction doesn't reach the desired receiver, the one it dues reach is supposed to send an equal payment back to the sender as a refund (this service is probably covered by the fee). The person the funds stopped at shouldn't disclose their preimage to the original sender in order to protect their funds in the HTLC.
Once this is done all users can elect to close the contract with a new Commitment transaction.
If a direct route can't be found between the sender and the intermidiary receiver, all the members of the network who helped transfer the funds can wait until the HTLC expires in order to claim their funds and may have to.
This may allow for som enodes with ihg connectivity to offer a service for closing out hash timelocks for a fee allowing the original spender to use their funds while the service waits to be able to spend theirs (but the sender may lose an amount similar to another transaction fee doing this). These nodes can also outsource locking posibilities to other compliant nodes that have connections with them and pay them a fee for it. The well connected node can then finish the routing of the transaction too.
Transaction Routing
The ideas with routing would be to have two different layers of nodes.
One layer being well connected main nodes that allow for people to involve them in their hops.
The second layer being any othe rnodes from the average user that may not be online all the time.
Layer 1 is a bit like how ISPs and IPs work, for example if someone in the US sends information to an IP beginning in 86, their ISP knows to forward it on to an ISP in Europe to determine where the packet should go.
Nodes, in a similar way, can just determine how to get data to the ISP/layer one nodes rather than trying to find an exact route to the other node.
Editor note: the paper goes on to say that the fees are for the lockup time for funds which I have omitted however, it may be helpful to know that only your counterparty can set the fee/determine your fee and once you've paid that then they have to settle fees with everyone else along the route.
It's recommended only a small amount is used per timelocked contract (HTLC) due to the prospect of the funds not reaching their appropriate due to an uncooperative party and their funds being locked up in the contract (potentially). It isn't possible for them to arrange for a reroute with the locked funds either.
If higher amounts a used, nodes may call for higher transaction fees to be paid on the transaction they're helping and locking thier funds up for. It's also better tot ry to reduce the number of hops between you and the designate node as you can incur a fee from each node (editor note: a lot of wallets have a built in function to limit the fees that can be charged).
If a transaction doesn't reach the desired receiver, the one it dues reach is supposed to send an equal payment back to the sender as a refund (this service is probably covered by the fee). The person the funds stopped at shouldn't disclose their preimage to the original sender in order to protect their funds in the HTLC.
Once this is done all users can elect to close the contract with a new Commitment transaction.
If a direct route can't be found between the sender and the intermidiary receiver, all the members of the network who helped transfer the funds can wait until the HTLC expires in order to claim their funds and may have to.
This may allow for som enodes with ihg connectivity to offer a service for closing out hash timelocks for a fee allowing the original spender to use their funds while the service waits to be able to spend theirs (but the sender may lose an amount similar to another transaction fee doing this). These nodes can also outsource locking posibilities to other compliant nodes that have connections with them and pay them a fee for it. The well connected node can then finish the routing of the transaction too.
Transaction Routing
The ideas with routing would be to have two different layers of nodes.
One layer being well connected main nodes that allow for people to involve them in their hops.
The second layer being any othe rnodes from the average user that may not be online all the time.
Layer 1 is a bit like how ISPs and IPs work, for example if someone in the US sends information to an IP beginning in 86, their ISP knows to forward it on to an ISP in Europe to determine where the packet should go.
Nodes, in a similar way, can just determine how to get data to the ISP/layer one nodes rather than trying to find an exact route to the other node.
Editor note: the paper goes on to say that the fees are for the lockup time for funds which I have omitted however, it may be helpful to know that only your counterparty can set the fee/determine your fee and once you've paid that then they have to settle fees with everyone else along the route.
[Back on the more useful stuff, probably got another day of useful and then I might be back to analysing the paper for the rest]
It’s possible to open a channel between the other person and have a third party form a 2-of-3 multisig. If one of the parties in this transaction won’t participate, the channel funds go to the other party as the penalty (presumably rather than all 3 picking a settlement transaction, each pair agree the amounts they are owed by the channel).
This idea is proposed so the third can focus on setting transaction fees to ensure both partys of the channel pay a reasonable amount in fees.
Lightning network fees should be significantly lower than blockchain fees and are generally paid for the locking up of funds when making a transaction
The fees should be almost unnoticeable with the lightning network for its many different parties that can arrange a hop to the next node. This will allow for keeping the lightning network a viable alternative to the bitcoin blockchain for scalability and speed (with its near instant transactions).
What the lightning network aims to solve:
This means that the bitcoin network can remain fast and scalable to deal with high demand, while allowing for this to be done programmatically to ensure ever user can always take their money back If the other party refuses to cooperate or they just want to take their funds back.
When multiple hops are in use, each participant (“hop” node) takes the responsibility of taking the funds to the next, each participant receives a HTLC with a lower time constraint than the last in order to ensure no double spends can occur on anyone and so each participant knows they still can redeem their funds once the payment clears.
Decrementing timelocks:
Taking the example from the paper, Alice wants to send funds to Dave, through Bob and Carol.
Alice checks how many hops it should take to get the transaction to clear and sets her timelock accordingly, for example since there are four hops that can be taken she can set the timelock to 3. Bob and Carol’s timelocks will be a decremented amount of this so:
Alice and Bob make a HTLC of 3 days expiry
Bob and Carod then make a HTLC of 2 days expiry
Carol and Dave then make a HTLC with a 1 days expiry.
Assuming Dave and Carrol cooperate with each other and agree on the value, the HTLC can be overridden with a new commitment transaction instead which could then funnel down to the rest, however R and the HTLC would still be valid until the new Commitment Transaction was fully signed. None of this gets broadcast back to the chain and all of them can make a new Commitment Transaction (going backwards up the chain) once they receive and/or make a preimage (where necessary).
For each of the HTLC contracts:
• Locks are only in force for the time limit specified, if a signed preimage is delivered after the time specified it can’t be accepted as the timelock will already be void
• One party won’t be able to give funds to the next unless they know they are able to receive funds from the last hop as they do (I.e double spends and fake transactions shouldn’t exist on the network) – and thus the decrementing timelock works in a way that the last HTLC takes longer to become invalidated than the current one so you can’t be in a position where this can occur.
If the receiver of the funds were to broadcast the preimage then it may be possible for the other members to take the money for themselves, so it is important that this information is only relaeased to the last person in the hop that has an HTLC contract they need the preimage to make claimable.
If one party refuses to cooperate, their channel gets closed onto the blockchain but it doesn’t affect everyone else in the chain, they’re still able to use their channels but must go back to the previous commitment transaction before the timelock.
However parties also face a timelock when a person becomes unresponsive and have to keep the HTLC open until it expires.
It’s possible to open a channel between the other person and have a third party form a 2-of-3 multisig. If one of the parties in this transaction won’t participate, the channel funds go to the other party as the penalty (presumably rather than all 3 picking a settlement transaction, each pair agree the amounts they are owed by the channel).
This idea is proposed so the third can focus on setting transaction fees to ensure both partys of the channel pay a reasonable amount in fees.
Lightning network fees should be significantly lower than blockchain fees and are generally paid for the locking up of funds when making a transaction
The fees should be almost unnoticeable with the lightning network for its many different parties that can arrange a hop to the next node. This will allow for keeping the lightning network a viable alternative to the bitcoin blockchain for scalability and speed (with its near instant transactions).
What the lightning network aims to solve:
This means that the bitcoin network can remain fast and scalable to deal with high demand, while allowing for this to be done programmatically to ensure ever user can always take their money back If the other party refuses to cooperate or they just want to take their funds back.
When multiple hops are in use, each participant (“hop” node) takes the responsibility of taking the funds to the next, each participant receives a HTLC with a lower time constraint than the last in order to ensure no double spends can occur on anyone and so each participant knows they still can redeem their funds once the payment clears.
Decrementing timelocks:
Taking the example from the paper, Alice wants to send funds to Dave, through Bob and Carol.
Alice checks how many hops it should take to get the transaction to clear and sets her timelock accordingly, for example since there are four hops that can be taken she can set the timelock to 3. Bob and Carol’s timelocks will be a decremented amount of this so:
Alice and Bob make a HTLC of 3 days expiry
Bob and Carod then make a HTLC of 2 days expiry
Carol and Dave then make a HTLC with a 1 days expiry.
Assuming Dave and Carrol cooperate with each other and agree on the value, the HTLC can be overridden with a new commitment transaction instead which could then funnel down to the rest, however R and the HTLC would still be valid until the new Commitment Transaction was fully signed. None of this gets broadcast back to the chain and all of them can make a new Commitment Transaction (going backwards up the chain) once they receive and/or make a preimage (where necessary).
For each of the HTLC contracts:
• Locks are only in force for the time limit specified, if a signed preimage is delivered after the time specified it can’t be accepted as the timelock will already be void
• One party won’t be able to give funds to the next unless they know they are able to receive funds from the last hop as they do (I.e double spends and fake transactions shouldn’t exist on the network) – and thus the decrementing timelock works in a way that the last HTLC takes longer to become invalidated than the current one so you can’t be in a position where this can occur.
If the receiver of the funds were to broadcast the preimage then it may be possible for the other members to take the money for themselves, so it is important that this information is only relaeased to the last person in the hop that has an HTLC contract they need the preimage to make claimable.
If one party refuses to cooperate, their channel gets closed onto the blockchain but it doesn’t affect everyone else in the chain, they’re still able to use their channels but must go back to the previous commitment transaction before the timelock.
However parties also face a timelock when a person becomes unresponsive and have to keep the HTLC open until it expires.
This is a ramble but an interesting one nontheless.
What is a merkel root tree?
[ALT TEXT: This is a diagram of a merkel root for those who can't view images, if you've seen one before no need to see it again]
This is a data structure that works a bit like a binary tree where every node has two child nodes, the difference is that the parten node normally contains a has of the children instead of actual data and if there is only one child node, the other child node for any node is a duplicate of that child (this is explained better in satoshi's whitepaper).
The keys used for dealing with these transactions are made using BIP32.
BIP32 uses a merkle root tree and uses a branch very far down the tree and assigns that to the first “day” of transactions.
The idea for this system is to start with the deepest child and work your way up, each node on the tree stores the master private key, from which can be derived a master public keys and then public keys and addresses.
The master public keys are shared so that both wallets can derive the same keys for building up raw transactions.
Each master private key also stores information for the node(s) below them so if Alice works up the tree every day and gets to day 5 and decides to disclose her key for day 4, the rest of the eksy for day 3,2,1 can be generated however the keys for day 6+ can’t be.
The ability that this data structure/key generation gives is that only a few kilobytes of data needs to be transferred between clients in order for one client to know the rest of the addresses associated with the other client and to invalidate their transactions (through giving access away to their private keys so it makes it useless to publish old commitment transactions).
What is a merkel root tree?
[ALT TEXT: This is a diagram of a merkel root for those who can't view images, if you've seen one before no need to see it again]
This is a data structure that works a bit like a binary tree where every node has two child nodes, the difference is that the parten node normally contains a has of the children instead of actual data and if there is only one child node, the other child node for any node is a duplicate of that child (this is explained better in satoshi's whitepaper).
The keys used for dealing with these transactions are made using BIP32.
BIP32 uses a merkle root tree and uses a branch very far down the tree and assigns that to the first “day” of transactions.
The idea for this system is to start with the deepest child and work your way up, each node on the tree stores the master private key, from which can be derived a master public keys and then public keys and addresses.
The master public keys are shared so that both wallets can derive the same keys for building up raw transactions.
Each master private key also stores information for the node(s) below them so if Alice works up the tree every day and gets to day 5 and decides to disclose her key for day 4, the rest of the eksy for day 3,2,1 can be generated however the keys for day 6+ can’t be.
The ability that this data structure/key generation gives is that only a few kilobytes of data needs to be transferred between clients in order for one client to know the rest of the addresses associated with the other client and to invalidate their transactions (through giving access away to their private keys so it makes it useless to publish old commitment transactions).
[This was a large topic (8+ pages 43-50) feel free to look at the paper if you want to know more, I just got the important stuff, the diagrams may be a helpful supplement – but I’m pushing my 1 page limit as it is]
A similar construction to the bidirectional payment channel should be created in order handle the payment. If Alice and Bob both have 0.5 btc each in their mutual channel and Alice wants to send funds to someone Bob has a connection with:
1. A new Commitment Transaction is made for the channel with refunds of 0 and 1 and a new Commitment Transaction, with the second output going towards the new channel.
2. The new commitment transaction made for the new channel pay Alice 0.4btc, Bob 0.5btc and an extra 0.1btc output to Bob’s contact
4 keys are used in this new HTLC, the ones for the old commitment transaction and the ones for the new as well as an additional message R (preimage) which states that the funds can be transferred from alice to bob and to bob’s counterparty. Presumably Bob’s counterparty signs that after he updates their current balance on the commitment transaction and both of them agree.
Before the HTLC runs out, Bob is able to broadcast his delivery transaction to return the 0.1 btc back to Alice and reset both of their balances to 0.5 (this may be done if the other party refuses to sign a commitment or Bob’s client can’t deal with the transaction) – bob doesn’t have to wait on the refund to confirm when he broadcasts one and Alice should have access to her funds immediately.
Alice can also broadcast a return transaction that brings the funds back to her, Alice must wait a predetermined amount of time before this transaction will validate however.
If Bob can produce a preimage R, then this R makes his HTLC execution transaction compliant with the blockchain and he is free to broadcast that beyond this point (as long as he has a preimage). This new transaction produces two RSMCs with two multisigs, the first is only valid after 1000 confirmsations but the second is valid immediately.
HTLC termination off chain requires both cosigners to agree on the new state of the channel. The sender must prove they have preimage R and fulfilled their obligations.
If they can both agree on the new channel state, it’s better to sort the new Commitment Transaction for the old channel off chain (saves fees and block size…) They must also sign breach remedy agreements for the HTLC so that becomes invalidated.
If one party becomes unresponsive, the information they have should be enough to publish what is theirs on the blockchain and refund both members of the channel – submitting their HTLC commitment transaction, initial commitment transaction and delivery transactions.
Order for closing an HTLC
1. Alice (the sender) signs a new Commitment Transaction and a Revocable Delivery Transaction for bob’s funds in the HTLC and sends it to Bob.
At this point, Bob is able to broadcast either the new commitment transaction or the HTLC commitment transaction so he can still take his funds back, but once a new commitment transaction is signed out of the HTLC, he will go with that one if he wanted to close the channel).
2. Bob then signs and sends a Commitment Transaction and the revocable delivery for Alice’s funds in the HTLC.
Bob’s funds aren’t signed from the HTLC for the revocable delivery but rather the original channel it seems.
3. Alice signs bob’s revocable delivery and commitment transaction for the new non-htlc channel.
Within the time window (the paper gives an example of a few days but I’m assuming it’s minutes or seconds now):
If the transaction goes though, Bob is able to broadcast R and the commitment transactions to take his money back.
If the time runs out and bob doesn’t do this, Alice is able to broadcast her HTLC Timeout transaction and revocable delivery transaction and the relevant data to the blockchain. She normally has a small amount of time to do this, and may have a similar time (or less) than what Bob had so she must be fast or may risk using the funds in the multisig.
A similar construction to the bidirectional payment channel should be created in order handle the payment. If Alice and Bob both have 0.5 btc each in their mutual channel and Alice wants to send funds to someone Bob has a connection with:
1. A new Commitment Transaction is made for the channel with refunds of 0 and 1 and a new Commitment Transaction, with the second output going towards the new channel.
2. The new commitment transaction made for the new channel pay Alice 0.4btc, Bob 0.5btc and an extra 0.1btc output to Bob’s contact
4 keys are used in this new HTLC, the ones for the old commitment transaction and the ones for the new as well as an additional message R (preimage) which states that the funds can be transferred from alice to bob and to bob’s counterparty. Presumably Bob’s counterparty signs that after he updates their current balance on the commitment transaction and both of them agree.
Before the HTLC runs out, Bob is able to broadcast his delivery transaction to return the 0.1 btc back to Alice and reset both of their balances to 0.5 (this may be done if the other party refuses to sign a commitment or Bob’s client can’t deal with the transaction) – bob doesn’t have to wait on the refund to confirm when he broadcasts one and Alice should have access to her funds immediately.
Alice can also broadcast a return transaction that brings the funds back to her, Alice must wait a predetermined amount of time before this transaction will validate however.
If Bob can produce a preimage R, then this R makes his HTLC execution transaction compliant with the blockchain and he is free to broadcast that beyond this point (as long as he has a preimage). This new transaction produces two RSMCs with two multisigs, the first is only valid after 1000 confirmsations but the second is valid immediately.
HTLC termination off chain requires both cosigners to agree on the new state of the channel. The sender must prove they have preimage R and fulfilled their obligations.
If they can both agree on the new channel state, it’s better to sort the new Commitment Transaction for the old channel off chain (saves fees and block size…) They must also sign breach remedy agreements for the HTLC so that becomes invalidated.
If one party becomes unresponsive, the information they have should be enough to publish what is theirs on the blockchain and refund both members of the channel – submitting their HTLC commitment transaction, initial commitment transaction and delivery transactions.
Order for closing an HTLC
1. Alice (the sender) signs a new Commitment Transaction and a Revocable Delivery Transaction for bob’s funds in the HTLC and sends it to Bob.
At this point, Bob is able to broadcast either the new commitment transaction or the HTLC commitment transaction so he can still take his funds back, but once a new commitment transaction is signed out of the HTLC, he will go with that one if he wanted to close the channel).
2. Bob then signs and sends a Commitment Transaction and the revocable delivery for Alice’s funds in the HTLC.
Bob’s funds aren’t signed from the HTLC for the revocable delivery but rather the original channel it seems.
3. Alice signs bob’s revocable delivery and commitment transaction for the new non-htlc channel.
Within the time window (the paper gives an example of a few days but I’m assuming it’s minutes or seconds now):
If the transaction goes though, Bob is able to broadcast R and the commitment transactions to take his money back.
If the time runs out and bob doesn’t do this, Alice is able to broadcast her HTLC Timeout transaction and revocable delivery transaction and the relevant data to the blockchain. She normally has a small amount of time to do this, and may have a similar time (or less) than what Bob had so she must be fast or may risk using the funds in the multisig.
The network is designed so that both parties are assured that they have full control over their funds so most funding transactions should never have to broadcast closure information (the clients just know it’s available to them if there are any problems).
Once someone decides to close a channel, they can contact the other party and can sign out the funds from the funding transaction based on the most recent Commitment Transaction. Once this is done, no further payments can be made within the channel and funds will be returned back to the user as soon as the transaction is broadcast (this can be done almost immediately if both parties agree to sign a new transaction – which would be the case for cooperative closure).
Cooperative closures allow both parties to receive funds immediately and also allow for fewer transactions to be published on the blockchain (less data has to be stored).
Hashed Timelock Contract (HTLC)
These are used for linking multiple bidirectional payment channels to create multiple hops for when you want to spend to someone you don’t have a channel directly open with.
HTLC uses nLockTime to ensure that the funds can only be spent after a certain point in time so that one channel can’t spend funds without crediting it to the desired node after them. This transaction data must also be revocable for if the node can’t be used for routing (i.e. it turns malicious).
1. Bob must be able to sign a random 20 bytes of data on the input of a transaction saying he will allow Alice to claim 0.1 bitcoin after 3 days. (so as to timelock bob’s bitcoins to the same value). [presumably both have to stake 0.1BTC into a contract).
2. If the three days elapses then the above clause is nullified and the contract becomes nullified and neither is able to settle or claim the funds.
3. Either party should pay out to the terms stipulated in the contract once they both agree.
4. If the users don’t agree on how to settle the contract then a penalty is awarded to the user who complied with the terms of the contract first.
HTLCs are marked up in days whereas RSMCs are marked up by blocks (for most computers this isn’t a problem as there are many timeservers and most computers store UTC and convert it for the user whenever they want to see the time – eliminating timezone issues).
This is essentially a way to allow for funds to be sent to the sender to send the funds on within a specific timeframe and if that fails then the sender may take their funds back.
These timestamps are enforced by the blockchain and verification must be possible in all full nodes already to ensure an appropriate timestamp is being suggested for each block (I.e blocktime <= current time). Special IF-ELSE conditions are used in these transactions to ensure they function correctly. (translated example from page 31 of whitepaper shown below):
OP_IF
OP_HASH160 OP_EQUALVERIFY
2 OP_CHECKMULTISIG
OP_ELSE
2 OP_CHECKMULTISIG
OP_ENIF
Essentially:
IF we are past the time given in the TimeLock then The address R gets funded and Alice and Bob take their share of the remaining funds back. If we are still in that time and the transaction is not valid, Bob and Alice take all of their funds back provided they agree on their new Commitment Transaction.
Once someone decides to close a channel, they can contact the other party and can sign out the funds from the funding transaction based on the most recent Commitment Transaction. Once this is done, no further payments can be made within the channel and funds will be returned back to the user as soon as the transaction is broadcast (this can be done almost immediately if both parties agree to sign a new transaction – which would be the case for cooperative closure).
Cooperative closures allow both parties to receive funds immediately and also allow for fewer transactions to be published on the blockchain (less data has to be stored).
Hashed Timelock Contract (HTLC)
These are used for linking multiple bidirectional payment channels to create multiple hops for when you want to spend to someone you don’t have a channel directly open with.
HTLC uses nLockTime to ensure that the funds can only be spent after a certain point in time so that one channel can’t spend funds without crediting it to the desired node after them. This transaction data must also be revocable for if the node can’t be used for routing (i.e. it turns malicious).
1. Bob must be able to sign a random 20 bytes of data on the input of a transaction saying he will allow Alice to claim 0.1 bitcoin after 3 days. (so as to timelock bob’s bitcoins to the same value). [presumably both have to stake 0.1BTC into a contract).
2. If the three days elapses then the above clause is nullified and the contract becomes nullified and neither is able to settle or claim the funds.
3. Either party should pay out to the terms stipulated in the contract once they both agree.
4. If the users don’t agree on how to settle the contract then a penalty is awarded to the user who complied with the terms of the contract first.
HTLCs are marked up in days whereas RSMCs are marked up by blocks (for most computers this isn’t a problem as there are many timeservers and most computers store UTC and convert it for the user whenever they want to see the time – eliminating timezone issues).
This is essentially a way to allow for funds to be sent to the sender to send the funds on within a specific timeframe and if that fails then the sender may take their funds back.
These timestamps are enforced by the blockchain and verification must be possible in all full nodes already to ensure an appropriate timestamp is being suggested for each block (I.e blocktime <= current time). Special IF-ELSE conditions are used in these transactions to ensure they function correctly. (translated example from page 31 of whitepaper shown below):
OP_IF
OP_HASH160
2
OP_ELSE
2
OP_ENIF
Essentially:
IF we are past the time given in the TimeLock then The address R gets funded and Alice and Bob take their share of the remaining funds back. If we are still in that time and the transaction is not valid, Bob and Alice take all of their funds back provided they agree on their new Commitment Transaction.
When a new commitment transaction is created, the old revocable delivery transaction must be invalidated through a half signed breach remedy agreement – this spends from the old commitment transaction. If one of the parties incorrectly broadcasts the old commitment transaction to the blockchain, the new breach remedy agreement with the revocable delivery agreement allows the one party strictly following the protocol to take back control of their funds.
This adds an incentive to both parties to keep only the latest Commitment Transaction as keeping any more may mean you accidentally publish one that is out of date and compromises all of your funds in that channel. The person who broadcasted the wrong Commitment Transaction only has the number of blocks (discussed above) to refute the claims of the other and take all the money, if this doesn’t happen, the blockchain goes by the thief’s word once he broadcasts the old Revocable Delivery clause.
It is necessary to keep an eye on the state of the blockchain and on the state of your channels just in case someone is in breach of agreement, this only really needs to be done once for a period of the number of blocks for the statute * 9 minutes (to be safe) – a third party can be incentivised (either paid beforehand or during) to watch over the blockchain and can be given just the Breach remedy transaction in case an out of date Commitment Transaction is published by the other party. With just the Breach Remedy transaction, the third party has no power over the channel other than to spot malicious activity from the other party.
Revocable commitment transaction generation
The commitment transactions are signed as p2sh (pay to script) as the redeem script must be signed to release the funds from a multisig transaction. The delivery transactions are just P2PKH (paying to an address beginning with a 1) or P2SH (address beginning with a 3).
A new public key is used for each confirmation transaction and is never reused, a master private key can be exchanged on channel formation in order to deal with this.
The order:
This adds an incentive to both parties to keep only the latest Commitment Transaction as keeping any more may mean you accidentally publish one that is out of date and compromises all of your funds in that channel. The person who broadcasted the wrong Commitment Transaction only has the number of blocks (discussed above) to refute the claims of the other and take all the money, if this doesn’t happen, the blockchain goes by the thief’s word once he broadcasts the old Revocable Delivery clause.
It is necessary to keep an eye on the state of the blockchain and on the state of your channels just in case someone is in breach of agreement, this only really needs to be done once for a period of the number of blocks for the statute * 9 minutes (to be safe) – a third party can be incentivised (either paid beforehand or during) to watch over the blockchain and can be given just the Breach remedy transaction in case an out of date Commitment Transaction is published by the other party. With just the Breach Remedy transaction, the third party has no power over the channel other than to spot malicious activity from the other party.
Revocable commitment transaction generation
The commitment transactions are signed as p2sh (pay to script) as the redeem script must be signed to release the funds from a multisig transaction. The delivery transactions are just P2PKH (paying to an address beginning with a 1) or P2SH (address beginning with a 3).
A new public key is used for each confirmation transaction and is never reused, a master private key can be exchanged on channel formation in order to deal with this.
The order:
- Both make two unsigned copies of the commitment transaction
- Both sign the revocable delivery transaction
- Both exchange unsigned transactions and sign each others for refunding themselves first
- Both exchange back and sign the transaction that ensures their output comes back to them
- The Breach Remedy Transactions are then transferred at this point to invalidate the old Confirmation Transactions
• In order to ensure the last Commitment Transaction is pushed to the blockchain, OP_CHECKSEQUENCEVERIFY is avaliable. This is an (output?) script in the bitcoin blockchian and it works by invalidating all of the previous Confirmation Transactions made (should one be broadcast to the blockchain and a new one comes into fruition). The addition of this function was originally for double spends such as RBF transactions to replace previous transactions in the mempool or for mistake correction in transaction.
• This is in the Commitment Transactions (exchanged between the two channel parties) with the number of network confirmations needed to be achieved on the funding transaction before the commitment transactions may be added. This number can be reduced if both parties agree at a later date, say they want to close the channel and return a transaction but the Commitment Transaction is 900 blocks away, they can both sign a new transaction to release the funds now. The initial funding transactions also enforce this number but it can still be superseded by the Commitment Transactions.
(EDITOR NOTE: even though the block height is given in a transaction (normally), transactions may be added by miners before that block height is reached if the signature validates for some software).
• Setting the sequence number to the maximum number available for the field means that no wait time is added. The superseding transaction is only valid within the original number of confirmations, if the limit was 1000 confs and we are past that point, the new transaction won’t be able to confirm and a new transaction will have to be signed and then published to the chain.
The use of a timestop was suggested whereby – if the blocks were full (deemed by the miners) a 1 can be added to the end of the version number in order to make the software ignore this. However, since asicboost uses the version number I’m not sure what they were getting at with this, BUT, an spv client and a full node would both probably be able to request block header information to determine how full blocks are and if a block is 990kb+ they could probably both agree to refuse to process that block but the task would be put on the two users and the miners to keep track of how many blocks have been full. This is to prevent a DOS attack being instigated where someone attempts to fill all the blocks with a higher fee than the one in the outgoing transaction until they can put it onto the chain.
All of this relies on miners not trying to start a 51% attack on the bitcoin+lightning network though. It is suggested this bit of data could be stored separately in the block header since the coinbase and timestamp can’t be used as they produce a mining nonce.
Since this data is put in an output so the commitment transaction would look like this (for Alice 0.75BTC and Bob for 1BTC)
Alice + BOB → 1.75 in multisig
[inputs] [outputs]
Alice’s CT → Alice 0.75BTC (Sequence=1000), Bob 1BTC (immediately spendable)
Bob’s CT → Alice 0.75BTC (immediately spendable), Bob 1BTC Sequence=1000
This means that whoever broadcasts the commitment transaction, providing the other party agrees, has to wait to spend their funds the 1000 blocks but the other member can spend their funds immediately after broadcasting their confirmation to the blockchain (delivery transaction). Once both have published their revocable delivery transactions, the channel is now considered closed. Alternatively, they still don't have to wait this time if both parties agree to cooperatively close the channel and can still sign another transaction without the sequence limit.
• This is in the Commitment Transactions (exchanged between the two channel parties) with the number of network confirmations needed to be achieved on the funding transaction before the commitment transactions may be added. This number can be reduced if both parties agree at a later date, say they want to close the channel and return a transaction but the Commitment Transaction is 900 blocks away, they can both sign a new transaction to release the funds now. The initial funding transactions also enforce this number but it can still be superseded by the Commitment Transactions.
(EDITOR NOTE: even though the block height is given in a transaction (normally), transactions may be added by miners before that block height is reached if the signature validates for some software).
• Setting the sequence number to the maximum number available for the field means that no wait time is added. The superseding transaction is only valid within the original number of confirmations, if the limit was 1000 confs and we are past that point, the new transaction won’t be able to confirm and a new transaction will have to be signed and then published to the chain.
The use of a timestop was suggested whereby – if the blocks were full (deemed by the miners) a 1 can be added to the end of the version number in order to make the software ignore this. However, since asicboost uses the version number I’m not sure what they were getting at with this, BUT, an spv client and a full node would both probably be able to request block header information to determine how full blocks are and if a block is 990kb+ they could probably both agree to refuse to process that block but the task would be put on the two users and the miners to keep track of how many blocks have been full. This is to prevent a DOS attack being instigated where someone attempts to fill all the blocks with a higher fee than the one in the outgoing transaction until they can put it onto the chain.
All of this relies on miners not trying to start a 51% attack on the bitcoin+lightning network though. It is suggested this bit of data could be stored separately in the block header since the coinbase and timestamp can’t be used as they produce a mining nonce.
Since this data is put in an output so the commitment transaction would look like this (for Alice 0.75BTC and Bob for 1BTC)
Alice + BOB → 1.75 in multisig
[inputs] [outputs]
Alice’s CT → Alice 0.75BTC (Sequence=1000), Bob 1BTC (immediately spendable)
Bob’s CT → Alice 0.75BTC (immediately spendable), Bob 1BTC Sequence=1000
This means that whoever broadcasts the commitment transaction, providing the other party agrees, has to wait to spend their funds the 1000 blocks but the other member can spend their funds immediately after broadcasting their confirmation to the blockchain (delivery transaction). Once both have published their revocable delivery transactions, the channel is now considered closed. Alternatively, they still don't have to wait this time if both parties agree to cooperatively close the channel and can still sign another transaction without the sequence limit.
In order to create a transaction, Alice and Bob need to:
If we stick with the example of Alice and Bob:
Alice devotes 1BTC to the channel
Bob devotes 0.75BTC to the channel
Both share scripts for the unspent transaction outputs once the original channel is funded.
The transaction is signed such that:
Thanks to suchmoon for the table
And the original transactions can then be signed once these are shared with each other so Alice can sign her 1 btc into the 2 of 2 multisig address and Bob can sign the 0.75 into the multisig address too (these will be done in one funding transaction as otherwise one may be able to lock someone else’s coins up in the channel and not return them since the transaction will be void if one of the utxos doesn’t exist).
A suggested softfork for the inputs used when signing the channel opening transaction (the first signed transaction passed) use SIGHASH NOIPUT to ensure the funds can be spent from the address without the need for an input transaction being broadcast or signed, this is significant as you can’t get a UTXO without signing a transaction and you couldn’t use a utxo of someone without getting the funding transaction which could then be used to lock up their funds so a SIGHASHNOINPUT script means that you don’t need to submit a funding transaction before you know you can definitely get your funds back from the channel, however the previous settlement method is used for now (with a refund of both funds signed at once).
When the two parties of the channel get their closing transaction/ commitment transaction (the transaction that allows them to withdraw their funds from the channel at any time), both parties must agree to conform to certain rules such as: only the last commitment transaction should be published to the blockchain; if any transaction published older than the most recent one is broadcast, the funds of the entire payment channel are transferred to the other party as a penalty. To determine who broadcast the fraudulent transaction to the blockchain, two Commitment Transactions are signed with individual identifiers for the respective party. The maximum penalty is designed to ensure people are discouraged from intentionally finding holes in the protocol.
For this to work both must transfer unsigned transactions with their identifier for the other to sign, once this is done they can sign the Commitment Transaction with their identifier and they have a way to determine who is to blame for broadcasting a transaction. This does not allow for a penalty to be assigned yet though.
- create an unsigned transaction and share it with the other party in order to determine the funds will be placed into the 2-of-2 multisig
- create a signed transaction and share it with the other party in order to give back the original funds to the rightful owner should one node go offline
- sign the original transaction and fund the multisig
If we stick with the example of Alice and Bob:
Alice devotes 1BTC to the channel
Bob devotes 0.75BTC to the channel
Both share scripts for the unspent transaction outputs once the original channel is funded.
The transaction is signed such that:
Alice’s input 1 btc in → Alice’s output 1BTC back to her address
Bob’s input 0.75 btc in → Bob’s output 0.75BTC sent back to his address
Thanks to suchmoon for the table
And the original transactions can then be signed once these are shared with each other so Alice can sign her 1 btc into the 2 of 2 multisig address and Bob can sign the 0.75 into the multisig address too (these will be done in one funding transaction as otherwise one may be able to lock someone else’s coins up in the channel and not return them since the transaction will be void if one of the utxos doesn’t exist).
A suggested softfork for the inputs used when signing the channel opening transaction (the first signed transaction passed) use SIGHASH NOIPUT to ensure the funds can be spent from the address without the need for an input transaction being broadcast or signed, this is significant as you can’t get a UTXO without signing a transaction and you couldn’t use a utxo of someone without getting the funding transaction which could then be used to lock up their funds so a SIGHASHNOINPUT script means that you don’t need to submit a funding transaction before you know you can definitely get your funds back from the channel, however the previous settlement method is used for now (with a refund of both funds signed at once).
When the two parties of the channel get their closing transaction/ commitment transaction (the transaction that allows them to withdraw their funds from the channel at any time), both parties must agree to conform to certain rules such as: only the last commitment transaction should be published to the blockchain; if any transaction published older than the most recent one is broadcast, the funds of the entire payment channel are transferred to the other party as a penalty. To determine who broadcast the fraudulent transaction to the blockchain, two Commitment Transactions are signed with individual identifiers for the respective party. The maximum penalty is designed to ensure people are discouraged from intentionally finding holes in the protocol.
For this to work both must transfer unsigned transactions with their identifier for the other to sign, once this is done they can sign the Commitment Transaction with their identifier and they have a way to determine who is to blame for broadcasting a transaction. This does not allow for a penalty to be assigned yet though.
How micropayment channels solve scalability
• Micropayments mean that only the people who need to care about a transaction need to know it.
▪ These payments are then isolated from the main bitcoin blockchain and are instead stored between the clients.
▪ A series of timelocks work to ensure that the funds become available to a party only after a certain amount of time has passed if the remote client does not volunteer to close a channel.
▪ Whenever funds are sent, a new signed and timelocked transaction is made between both parties so the original owner(s) are in full control even without the cosigner's agreement.
• So that one party isn’t able to just lock up the funds of the other, a script for a penalty is added to the protocol for the 2 of 2 multisig so that in the event one participant doesn’t cosign an updated transaction, the new inputs go to the compliant party’s control.
• The only time a transaction needs to be broadcast are when starting a channel or when faced with an uncooperative party. If everyone on the bitcoin network has a channel on the lightning network then this will solve the scaling problem somewhat. There may still be 1 billion utxos that take 20 million searches to get them added into the blockchain but this will only happen ONCE per every channel made rather than once per every transaction. Even if there are only 3 transactions made in a channel before its closure then it will still allow the blockchain to become more scalable.
• These locks also mean that the transaction can be sent through multiple micropayment channels without one being able to spend the funds until a certain amount of time has passed, and by that time, the channel participants will have found a new route to send the funds and the old transaction should become unspendable.
(EDITOR’S NOTE: the trouble from this I see with the lightning network is that it might be preferable either to: not keep all funds open with one channel and split them between 5+ people or to keep funds on the current blockchain in bitcoin or in an altcoin that will maintain its value with bitcoin if bitcoin becomes the dominant currency somewhere – most default timings are set to 2 weeks (or at least a day) and if that’s enforced by your channel and you run out of food, you may have a long time to wait).
• Micropayments mean that only the people who need to care about a transaction need to know it.
▪ These payments are then isolated from the main bitcoin blockchain and are instead stored between the clients.
▪ A series of timelocks work to ensure that the funds become available to a party only after a certain amount of time has passed if the remote client does not volunteer to close a channel.
▪ Whenever funds are sent, a new signed and timelocked transaction is made between both parties so the original owner(s) are in full control even without the cosigner's agreement.
• So that one party isn’t able to just lock up the funds of the other, a script for a penalty is added to the protocol for the 2 of 2 multisig so that in the event one participant doesn’t cosign an updated transaction, the new inputs go to the compliant party’s control.
• The only time a transaction needs to be broadcast are when starting a channel or when faced with an uncooperative party. If everyone on the bitcoin network has a channel on the lightning network then this will solve the scaling problem somewhat. There may still be 1 billion utxos that take 20 million searches to get them added into the blockchain but this will only happen ONCE per every channel made rather than once per every transaction. Even if there are only 3 transactions made in a channel before its closure then it will still allow the blockchain to become more scalable.
• These locks also mean that the transaction can be sent through multiple micropayment channels without one being able to spend the funds until a certain amount of time has passed, and by that time, the channel participants will have found a new route to send the funds and the old transaction should become unspendable.
(EDITOR’S NOTE: the trouble from this I see with the lightning network is that it might be preferable either to: not keep all funds open with one channel and split them between 5+ people or to keep funds on the current blockchain in bitcoin or in an altcoin that will maintain its value with bitcoin if bitcoin becomes the dominant currency somewhere – most default timings are set to 2 weeks (or at least a day) and if that’s enforced by your channel and you run out of food, you may have a long time to wait).
NOTE: remember I'm trying to make the whitepaper more concise, people will question this part so it's helpful to have it even if it isn't directly related to why the lightning network as a thing and how it functions. If you want an argument about Moore's law feel free to open a topic .
My blurb:
• transactions are sent over a series of micropayment channels (so payments can be made off chain).
• Transactions are signed and broadcast across the bitcoin blockchain which allows for untrusted parties to send payments to each other. These are broadcast via a series of decrementing timelocks in order to increase security (this allows for malleability reduction as it means that a transaction can’t be double spent – for example: if Alice sends a transaction to Bob, Alice initially sends a transaction but Bob’s node crashes, Alice must wait for that transaction to become invalid before broadcasting a transaction from Alice → Derek → Bob, bob can’t then try to rebroadcast the old transaction for acceptance and cause Alice to lose the same amount of funds twice.
The Trouble Of The Bitcoin Blockchain
• The bitcoin blockchain uses a broadcast protocol whereby all participants/nodes receive a copy of the state changes to the chain.
• If this protocol is used for all financial transactions, significant lag may be caused on many machines (for example when updating the chainstate – the database of unspent transaction outputs)
Why the blockchain won’t keep up
• Visa processed 100 billion transactions in 2014[2], based on standard micropayments currently of 2 inputs and 2 outputs using native segwit addresses ~280 bytes, would make for 26[2sf] terabytes of data a year. With 1 billion transactions, and the fastest searching algorithms (with self balancing trees or a balanced hash function) is 20 million searches for each transaction 1bn(log2(1bn)). Most processors are able to handle several billion tasks a second so 20 million tasks on their own isn’t too much of a problem but with the average of 300 million transactions a day that visa faced, this would be impossible for most computers to handle, and would trequire a clock speed of[3] 247GHz just to keep up with the current transactions, making resyncing impossible (as it is the point where the system can just about keep up with the transactions), there will be further complications to this such as memory recall times from disk (milli seconds), ram (micro seconds), cache and registers still take a few nanoseconds to access so will still cause issues with processing the sheer number of transactions.
• The processing power mentioned above would price many people out of being able to run a full node and would mean bitcoin will be a lot more centralised. At the least, there could be many people running a node but with a recent chain copy if they have 1THz of CPU power or higher.
• The increase in demand may lead to more centralisation and more third parties being trusted which means less people will have voting rights on the chain and those people have more power to drive up fees for transactions and can allow for custody of coins to be held by someone else (so they can spend your coins as they wish) or they can censor who can send funds on the blockchain too and ban or freeze a certain address for spending funds. They can also refuse to accept a transaction and rewind blocks to credit the wrong person for a certain amount in an extreme case.
. My blurb:
• transactions are sent over a series of micropayment channels (so payments can be made off chain).
• Transactions are signed and broadcast across the bitcoin blockchain which allows for untrusted parties to send payments to each other. These are broadcast via a series of decrementing timelocks in order to increase security (this allows for malleability reduction as it means that a transaction can’t be double spent – for example: if Alice sends a transaction to Bob, Alice initially sends a transaction but Bob’s node crashes, Alice must wait for that transaction to become invalid before broadcasting a transaction from Alice → Derek → Bob, bob can’t then try to rebroadcast the old transaction for acceptance and cause Alice to lose the same amount of funds twice.
The Trouble Of The Bitcoin Blockchain
• The bitcoin blockchain uses a broadcast protocol whereby all participants/nodes receive a copy of the state changes to the chain.
• If this protocol is used for all financial transactions, significant lag may be caused on many machines (for example when updating the chainstate – the database of unspent transaction outputs)
Why the blockchain won’t keep up
• Visa processed 100 billion transactions in 2014[2], based on standard micropayments currently of 2 inputs and 2 outputs using native segwit addresses ~280 bytes, would make for 26[2sf] terabytes of data a year. With 1 billion transactions, and the fastest searching algorithms (with self balancing trees or a balanced hash function) is 20 million searches for each transaction 1bn(log2(1bn)). Most processors are able to handle several billion tasks a second so 20 million tasks on their own isn’t too much of a problem but with the average of 300 million transactions a day that visa faced, this would be impossible for most computers to handle, and would trequire a clock speed of[3] 247GHz just to keep up with the current transactions, making resyncing impossible (as it is the point where the system can just about keep up with the transactions), there will be further complications to this such as memory recall times from disk (milli seconds), ram (micro seconds), cache and registers still take a few nanoseconds to access so will still cause issues with processing the sheer number of transactions.
• The processing power mentioned above would price many people out of being able to run a full node and would mean bitcoin will be a lot more centralised. At the least, there could be many people running a node but with a recent chain copy if they have 1THz of CPU power or higher.
• The increase in demand may lead to more centralisation and more third parties being trusted which means less people will have voting rights on the chain and those people have more power to drive up fees for transactions and can allow for custody of coins to be held by someone else (so they can spend your coins as they wish) or they can censor who can send funds on the blockchain too and ban or freeze a certain address for spending funds. They can also refuse to accept a transaction and rewind blocks to credit the wrong person for a certain amount in an extreme case.
I have seen little evaluations of the lightning network that cover the high level and low level content. I will attempt to take a look at the LN based on it's whitepaper and project the important parts I think are neccessary to give you a basic knowledge.
Please do not reply to this topic, any responses will be deleted, discussion topic can be found here instead: https://bitcointalksearch.org/topic/m.53607856
As my first pieces of advice, this may not be as comprehensive as you expect or it may be more than you can handle. I'm trying to condense a 70 page document into 14 pages that can be easily read and quickly understood, I will try to cover everything but may leave out some parts I don't find important or parts I think are covered elsewhere. I would encourage you to do your own research either alongside this or afterwards.
I noticed a lot of webcasters seem to do seminars at 8pm UTC so this will become the time I upload my lessons here. They should be short enough that you can fit two or three into a 10 minute period if you miss some days.
I would also encourage you to try if you want to learn more:
https://bitcointalksearch.org/topic/timelord2067s-timely-test-main-net-lightning-loans-to-a-t-in-202122-5184177 ← Timelord2067's Timely Test & Main-neT LighTning Loans to a "T" in 2020
https://bitcointalksearch.org/topic/liberated-loycevs-legendary-little-lightning-loans-5149962 ← Liberated: LoyceV's Legendary Little Lightning Loans
https://bitcointalksearch.org/topic/free-lightning-tests-5186778 ← Free lightning tests by jackg
I got asked for a donation address so I'll post my staked one down here: bc1qdj5v2q8p398rdy6sexc0fapk4hcq0p54xz56ez - I don't expect to receive anything though.
The references I used:
Edit log:
Revisions made on lesson #3 and #4 as per recommendations on script availability and precompleted forks
Please do not reply to this topic, any responses will be deleted, discussion topic can be found here instead: https://bitcointalksearch.org/topic/m.53607856
As my first pieces of advice, this may not be as comprehensive as you expect or it may be more than you can handle. I'm trying to condense a 70 page document into 14 pages that can be easily read and quickly understood, I will try to cover everything but may leave out some parts I don't find important or parts I think are covered elsewhere. I would encourage you to do your own research either alongside this or afterwards.
I noticed a lot of webcasters seem to do seminars at 8pm UTC so this will become the time I upload my lessons here. They should be short enough that you can fit two or three into a 10 minute period if you miss some days.
I would also encourage you to try if you want to learn more:
https://bitcointalksearch.org/topic/timelord2067s-timely-test-main-net-lightning-loans-to-a-t-in-202122-5184177 ← Timelord2067's Timely Test & Main-neT LighTning Loans to a "T" in 2020
https://bitcointalksearch.org/topic/liberated-loycevs-legendary-little-lightning-loans-5149962 ← Liberated: LoyceV's Legendary Little Lightning Loans
https://bitcointalksearch.org/topic/free-lightning-tests-5186778 ← Free lightning tests by jackg
I got asked for a donation address so I'll post my staked one down here: bc1qdj5v2q8p398rdy6sexc0fapk4hcq0p54xz56ez - I don't expect to receive anything though.
The references I used:
| number | type |
| main paper | https://lightning.network/lightning-network-paper.pdf |
| 1 | https://bitcoin.stackexchange.com/questions/64703/lightning-why-do-we-need-decrementing-timelocks-in-multi-hop-payments/78433 |
| 2 | https://en.wikipedia.org/wiki/Visa_Inc |
| 3 | 20 000 000 (number of searches) x 4 (2 input 2 output average) x 300 000 000 (number of transactions a day) / (3600x24 – seconds in a day) = 247 000 000 000 Hz |
Edit log:
Revisions made on lesson #3 and #4 as per recommendations on script availability and precompleted forks
Jump to: