Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2015-01-11T22:24:47+00:00


Summary:

In an email conversation, Nathan Cook asks for a concrete example of scriptPubKeys/transactions using an idea proposed by an unknown individual to make the review process easier. The proposal suggests having only one channel as a deposit saver instead of opening a second payment channel in the opposite direction. They provide a link to a CLTV-using micropayment channel demo on GitHub for reference material.The email also includes an apology for not providing feedback on a protocol related to payment tree and suggests forking the existing code in bitcoinj and extending it with new functionality if one wanted to implement it. The author mentions the original Satoshi design and agrees with Gregory's phrasing that Bitcoin will likely become multi-layered over time. The proposal from GreenAddress to be a well-known signer who is trusted to not double spend is mentioned. From a miner's perspective, there are multiple schemes where they are viable if cost(fraud) is less than reward(block).Another email conversation discusses the implications of developing bi-directional micropayment channels. The focus is on the concept of zakat, a system based on trust, which contrasts with the trustless nature of bitcoin. The message provides links to further information on zakat and a traditional philanthropic historic overview. Mike Hearn shares his thoughts on the original design documented at the bottom of a wiki page and how time-locked transactions can be broadcast across the network and replaced by broadcasting a new transaction with higher sequence numbers. He discusses how miners could pick any version under the 2-of-2 channel model but disagrees with Gregory's claim that people refuse to use protocols affected by malleability. The message also promotes the website Go Parallel aimed at parallel software development.In another email conversation, Mike Hearn discusses the issue of Bitcoin's safety and the potential for malicious miners to break the system. He argues that even a small percentage of malicious miners could cause significant damage to the network. Additionally, he points out that clients cannot enforce that all versions have the same fee attached. Hearn suggests that the ideal scenario would be absolute soundness in the rules, followed by cryptographic soundness, economic soundness, and honesty soundness. However, as it is impossible to make the entire system absolutely sound or cryptographically sound, users must navigate this risk stack. Hearn also notes that one man's integrity is another man's malice, and so a risk analysis has to import the clarity of judgment, morality, coerceability, personal values, etc. of everyone in the trust chain. In order to mitigate these risks, users of Bitcoin should behave in ways that cannot be harmed by a failure to follow the rules.The design for time-locked transactions using sequence numbers was intended to allow high frequency trading between parties but could be vulnerable to attacks. Broadcasted transactions with a lock time far in the future could fill up memory and use up CPU time and bandwidth. However, there is a concern that Bitcoin must still work even if miners are malicious and willing to break things to gain more money. In this scenario, there is nothing forcing miners to include the latest version in the block chain, they could pick any version. In the 2-of-2 channel model, both parties must sign and agree on the same fee attached. It is also argued that user-friendly apps that use refunds currently do not exist, so it is uncertain whether people would refuse to use them or not depending on the prevalence of attacks which is currently unknown.In an email conversation between Mike Hearn and an unknown recipient, Hearn discussed a limitation on most existing micropayment channel ideas, stating that payments can only flow in one direction. However, he noted that the original protocol as designed by Satoshi did not have this limitation, but it has evolved this way because of ad-hoc DoS fixes over time. Hearn suggested that eventually, a different approach to handling DoS attacks based on resource prioritization and scheduling will become needed or implemented, allowing the original design to be safely brought back to life. The unknown recipient disagreed with Hearn's understanding, stating that expecting replacement to work and be enforced is completely unsafe. They added that people refuse to use protocols that are broken by refund malleability.In a Bitcoin development mailing list, Mike Hearn stated that most micropayment channel ideas have a limitation of one-way payment flow. He further added that the original protocol as designed by Satoshi had no such limitation but has evolved over time due to ad-hoc DoS fixes. He mentioned that a different approach to handling DoS attacks based on resource prioritisation and scheduling will become necessary in the future and the original design could be safely brought back to life at that point. Jeff Garzik questioned Mike's reference to the "original design" without mentioning how it was different or better.


Updated on: 2023-08-01T11:05:36.941216+00:00