Published on: 2015-07-27T21:29:56+00:00
In a discussion between Anthony Towns and Joseph Poon, the issue of storage limitations for Bitcoin's HTLC outputs is addressed. They suggest storing the timeout and original Commitment Transaction height for each HTLC output to address the storage problem. However, there are concerns about the increased storage requirements if each HTLC output is multiplied by every commitment it's stored in. To overcome this, they propose using the nLockTime trick to store the height of HTLC storage and searching back down from R4 to find other HTLCs in the transaction.Joseph Poon notes in a recent post that storing the hash of the R value would increase its size to 26 bytes. He suggests using OP_RETURN metadata output to fit three outputs per metadata output if it is considered acceptable. Beyond three HTLCs, it is necessary to remember HTLC values forever. He also discusses anchor upgrades and suggests opening a new channel or creating a new anchor to spend existing anchors.The author discusses the technical details of using OP_RETURN metadata for transactions and explains the use of 16-bit and 32-bit values for timeouts and commitment transactions, respectively. The tradeoff between using OP_RETURN and local storage is discussed, with OP_RETURN being preferable for large hubs. Regardless of the chosen method, it is better than having the entire script as part of the output.Joseph Poon talks about solving the issue of identifying HTLC outputs using pubkeys as identifiers, noting that it is not possible due to P2SH being used. He suggests checking recent blocks before the Commitment Transaction for the search space but acknowledges that long-dated HTLCs break down this limitation. He suggests storing prior commitment transactions as a stop-gap solution, including the timeout and original Commitment Transaction height when the HTLC was first made. He dislikes using OP_RETURN as a solution but acknowledges its possibility.In a message to Anthony, Joseph Poon discusses the possibility of using OP_CSV in the long-term. He suggests overloading nLockTime with values below current unixtime as a filter or counter, providing enough bits of entropy even for billions of transactions in a single channel.In a conversation between Rusty Russell and Anthony Towns, the topic of cheating in Bitcoin payments is discussed. Russell suggests using a dummy output of "0: OP_RETURN 42" to make calculations trivial when dealing with old commitments. He also suggests adding an extra output "0: OP_RETURN 42 #R1 #R2 #R3 #R4" to deal with the issue of unhashing scripts in pay2scripthash outputs. The tradeoff between transaction size and identifiability is mentioned.In a recent email discussion, Anthony Towns raises concerns about the security of payment channels in the Lightning Network. He discusses the need to work out which Alice_N hash is being abused if Alice cheats and publishes an old commitment. A dummy output of "0: OP_RETURN 42" is suggested to make this calculation trivial. The process of checking if the anchor is the latest commitment transaction and finding the revocation key is explained. The use of OP_RETURN and p2sh outputs for HTLCs is also discussed.The lightning protocol for a network-protocol level is explained, involving Alice and Bob setting up a channel with fully signed commitment transactions. The process of updating the channel and voiding attempts to use older commitments is described. The use of pay2scripthash for HTLCs complicates the process.Overall, the discussions focus on addressing storage limitations, identifying HTLC outputs, ensuring security in payment channels, and optimizing transaction size in the Lightning Network.
Updated on: 2023-07-31T18:09:42.975458+00:00