<oembed><type>rich</type><version>1.0</version><author_name>npub13f3qkf0gj3zwnypll339zsjsjsw2xxxnm5m3xzyzrdxtuvxafq4qmv7cz5</author_name><author_url>https://nostr.ae/npub13f3qkf0gj3zwnypll339zsjsjsw2xxxnm5m3xzyzrdxtuvxafq4qmv7cz5</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-02-12&#xA;📝 Original message:&gt; On 12 Feb 2015, at 13:49, Mike Hearn &lt;mike at plan99.net&gt; wrote:&#xA;&gt; If unconfirmed payments become flaky enough that people stop using them, then a portion of the Bitcoin community will find workarounds like trusted third parties, trusted hardware, whatever and will just struggle one. Other people will look at the new tradeoffs/complexity, and decide that Bitcoin is no longer better for them than banks.&#xA;&#xA;How about a Ripple-like IOU-based payment network that is 100% decentralized, for &#34;dumb and daily&#34; payments only? IOUs will propagate from node to node and will trusted because of a &#34;joint escrow&#34; transaction between each pair of nodes (locking up certain amount on both ends in 2-of-2 multisig). Total amount of debt from one node to another will be limited to 50% of the locked amount (e.g. if both nodes lock up $20 each, they allow debt up to $10 in each direction). When debt is reaching its limit, it&#39;s being &#34;cleared&#34; by debtor via a real BTC transaction or simply by &#34;closing&#34; the contract transaction with correct proportion on outputs to pay off the debt.&#xA;&#xA;Every node may require an arbitrary fee for a service of providing his funds to back IOUs, when making a payment, merchant/customer may find several possible &#34;paths&#34; and choose the quickest/cheapest one to use. Centralization is possible at a proportional capital expense. If some node wants to be Visa-scale with millions of contracts and a lot of fees to earn, they&#39;ll have to lock up huge amount of money. This puts natural limit on centralization or associated risk. &#xA;&#xA;Example:&#xA;&#xA;I pay $10. The following path is discovered and signed off by the Merchant who accepts an ad-hoc 0.3% fee:&#xA;&#xA;Me: $10 -&gt; $9.99 (Alice) -&gt; $9.98 (Bob) -&gt; $9.97 (Merchant).&#xA;&#xA;Now I owe $10 to Alice, Alice owes $9.98 to Bob, Bob owes $9.97 to Merchant. Clearing of debts happens independently between each participant based on their debt-to-capital ratio and whether any party wishes to exit. Of course, if several paths are discovered within a reasonable timeframe, Merchant will choose the cheapest one. And maybe abort transaction if the proposed path is too expensive (e.g. total fee is &gt;1%).&#xA;&#xA;Pros:&#xA;&#xA;- Decentralized.&#xA;- Mere seconds to settle a payment.&#xA;- Infinite scalability (no global consensus). Each payment involves 5-7 nodes only.&#xA;- No trusted parties or federation (trust is &#34;purchased&#34; using &#34;joint escrow&#34; txs on blockchain)&#xA;- No funny currency, IOUs denominated in BTC.&#xA;- No global consensus or protocol. Nodes can be semi-compatible, upgrade independently. All risks are local.&#xA;&#xA;Political problems solved:&#xA;&#xA;- No need to debate zeroconf transactions. We don&#39;t *need* them anymore to buy a coffee.&#xA;- No need to debate block size limit. It&#39;d still be nice to raise it when needed, but for 99% of transactions we&#39;ll have a good decentralized solution off-chain, so the issue is less pressing.&#xA;&#xA;Cons:&#xA;&#xA;- Some amount of cash needs to be locked up with random nodes most of the time. If one of the nodes is offline, payments can&#39;t be cleared through that node. Although, it could not be a big problem as the network is useful for small-ish payments and every node will have 10-15 contracts, so it will tolerate occasional unavailability of some of them. &#xA;&#xA;&#xA;&#xA;&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/4105f17b/attachment.html&gt;</html></oembed>