<div dir="ltr">Oh, I forgot to mention- there is nothing about payment channels that requires a blockchain. They can be just as easily be run by a bank, and payments can trustlessly go across multiple banks. This is the basis of Interledger: <a href="https://interledger.org">https://interledger.org</a></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 17, 2016 at 6:30 PM, Jehan Tremback <span dir="ltr"><<a href="mailto:jehan.tremback@gmail.com" target="_blank">jehan.tremback@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I have to agree with Natanael. A payment channel allows two peers to send money to one another without any packets sent to anyone else. The record of the payment is stored only by the peers, with the channel closing mechanism making it unfeasible for either of them to cheat.<div><br></div><div>Multi-hop payment channels allow money to be routed across completely trustless intermediaries. With a routing protocol, you can send money to anyone else, just like you can send data to anyone else over the internet.</div><div><br></div><div>I wrote a post with some friendly diagrams: <a href="http://altheamesh.com/blog/universal-payment-channels/" target="_blank">http://altheamesh.<wbr>com/blog/universal-payment-<wbr>channels/</a><br><div><br></div><div><div>There are working implementations of multi-hop payment channels for Bitcoin (the Lightning network or Thunder network). Right now the Bitcoin stuff doesn't work on the main chain because Bitcoin has extremely primitive scriptability, and there needs to be a fork to update it (unfortunately, the Bitcoin community currently seems unable to agree on anything): <a href="https://www.blockchain.com/thunder/" target="_blank">https://www.<wbr>blockchain.com/thunder/</a></div></div></div><div><br></div><div>Ethereum does not suffer from this problem, so there is a multihop channel implementation in alpha now, called the Raiden network: <a href="http://raiden.network" target="_blank">http://raiden.network</a></div><div><br></div><div>Z-Cash has published a paper about anonymous payment channels: <a href="https://z.cash/blog/bolt-private-payment-channels.html" target="_blank">https://z.cash/blog/<wbr>bolt-private-payment-channels.<wbr>html</a></div><div><br></div><div>Digital Cash should be respected as a historical stepping stone, but I see no real benefit to the scheme. Maybe it is useful for some niche applications that benefit from its characteristics.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Jehan</div></font></span></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Wed, Aug 17, 2016 at 1:56 AM, Natanael <span dir="ltr"><<a href="mailto:natanael.l@gmail.com" target="_blank">natanael.l@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><span><p dir="ltr"></p>
<p dir="ltr">Den 17 aug. 2016 06:48 skrev "Ray Dillinger" <<a href="mailto:bear@sonic.net" target="_blank">bear@sonic.net</a>>:<br>
><br>
><br>
><br>
> On 08/16/2016 04:49 PM, Allen wrote:<br>
><br>
> > Blockchains that can handle 20 billion transaction a day will be here<br>
> > within a year.<br>
><br>
> That is an interesting assertion.  I do not believe it.<br>
><br>
> 20G transactions.  Assume 100 bytes per, and that's terribly generous<br>
> in terms of how small you think you can get them.  2T bytes per day.<br>
> You have a data plan that will allow you to download 2T bytes daily?<br>
> You think you'll have one by the end of a year? You have a hard drive<br>
> that can store 700 Tbytes for even one year's worth of block chain<br>
> history? You think you'll have one by the end of a year?<br>
><br>
> The only parties with that kind of connection and storage will<br>
> perforce act as Trusted Parties to all other users.  That means<br>
> they'll either Gox the users over and over, or they'll become<br>
> just as heavily regulated, insured, and monitored as any<br>
> conventional bank.  A banker is a banker is a banker.<br>
><br>
> The vast majority of people are already letting strangers hold<br>
> their keys and trusting that they'll get their bitcoins back.<br>
> That means the online-wallet people and the exchanges function<br>
> as banks.  And these banks are Trusted. When they embezzle<br>
> (or even if they just get robbed), it leaves people broke.<br>
><br>
> Ending the existence of Trusted parties and their ability to Gox<br>
> people, if you recall, was sort of the point of the block chain.<br>
><br>
> It failed.</p>
</span><p dir="ltr">Just like how Bitcoin solved the unsolvable Byzantine General's problem by ignoring the original problem statement and going for a probabilistic approximation, Bitcoin's got a solution here too. </p>
<p dir="ltr">You know Bitcoin's smart contracts? And how it supports multisignature transactions, and timeouts? And that it's got "payment channels", where two people can merge all their transactions they performed during a timeperiod into just two (a commitment transaction and a settlement transaction on the blockchain, where the two parties simultaneously keeps a non-final settlement transaction ready in memory until they're done? </p>
<p dir="ltr">Now combine them. </p>
<p dir="ltr">You create a "wallet" where you commit money to a payment channel against a Lightning Network routing node (server) for a time period, where that server can't steal from you (because you never signed a transaction that leaves the server with all your money). The network of Lightning Network nodes has payment channels as their backbone links too. </p>
<p dir="ltr">So it kind of becomes an email for instant high volume transactions, with a blockchain to settle on from time to time - you tell your server who on what server to send X coins to, and sign the corresponding transaction to enable it to transfer that sum. All the involved payment channels are updated accordingly to reflect that transfer of money, updating the non-final settlement transactions being held in memory. </p>
<p dir="ltr">Even freezing funds would fail, because after a certain amount of time of non-cooperation from the server it will be possible to just withdraw it singlehandedly. </p>
<p dir="ltr">You could question if they wouldn't just reverse a set of transactions that pay out money and try to run with what's been committed to them. Of course there's a number of reasons, based on game theory;</p>
<p dir="ltr">The total sum that the server will be able to claim for itself at any period in time will be relatively small compared to the sums involved (any attempts at inflating it would trigger a large number of warning systems that flag unusual behavior). Thus the reward and incentive is small. </p>
<p dir="ltr">Any sign of reversing any transaction is provable thanks to settlement transactions being signed and mutually updated (you just show the world the signed transaction that the server reversed through sending a prior one to the blockchain). Thus there's accountability, and high risk of getting caught. </p>
<p dir="ltr">Because malice can be detected so quickly, the timeframe for attacks given the automated systems involved is limited to mere seconds before you get flagged. </p>
<p dir="ltr">The above points combined with that trust takes time to build, and that fees for processing transactions is likely to be more profitable (analogous to the Bitcoin mining situation), the incentive is to follow the protocol and proceess transactions as told by the users.</p>
<br></div></div><span class="">______________________________<wbr>_________________<br>
The cryptography mailing list<br>
<a href="mailto:cryptography@metzdowd.com" target="_blank">cryptography@metzdowd.com</a><br>
<a href="http://www.metzdowd.com/mailman/listinfo/cryptography" rel="noreferrer" target="_blank">http://www.metzdowd.com/mailma<wbr>n/listinfo/cryptography</a><br></span></blockquote></div><br></div>
</blockquote></div><br></div>