[Cryptography] Electronic currency revived after 20-year hiatus

[Jehan Tremback]

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.

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.

I wrote a post with some friendly diagrams:
http://altheamesh.com/blog/universal-payment-channels/

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):
https://www.blockchain.com/thunder/

Ethereum does not suffer from this problem, so there is a multihop channel
implementation in alpha now, called the Raiden network:
http://raiden.network

Z-Cash has published a paper about anonymous payment channels:
https://z.cash/blog/bolt-private-payment-channels.html

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.

-Jehan

On Wed, Aug 17, 2016 at 1:56 AM, Natanael <natanael.l at gmail.com> wrote:

> Den 17 aug. 2016 06:48 skrev "Ray Dillinger" <bear at sonic.net>:
> >
> >
> >
> > On 08/16/2016 04:49 PM, Allen wrote:
> >
> > > Blockchains that can handle 20 billion transaction a day will be here
> > > within a year.
> >
> > That is an interesting assertion.  I do not believe it.
> >
> > 20G transactions.  Assume 100 bytes per, and that's terribly generous
> > in terms of how small you think you can get them.  2T bytes per day.
> > You have a data plan that will allow you to download 2T bytes daily?
> > You think you'll have one by the end of a year? You have a hard drive
> > that can store 700 Tbytes for even one year's worth of block chain
> > history? You think you'll have one by the end of a year?
> >
> > The only parties with that kind of connection and storage will
> > perforce act as Trusted Parties to all other users.  That means
> > they'll either Gox the users over and over, or they'll become
> > just as heavily regulated, insured, and monitored as any
> > conventional bank.  A banker is a banker is a banker.
> >
> > The vast majority of people are already letting strangers hold
> > their keys and trusting that they'll get their bitcoins back.
> > That means the online-wallet people and the exchanges function
> > as banks.  And these banks are Trusted. When they embezzle
> > (or even if they just get robbed), it leaves people broke.
> >
> > Ending the existence of Trusted parties and their ability to Gox
> > people, if you recall, was sort of the point of the block chain.
> >
> > It failed.
>
> 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.
>
> 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?
>
> Now combine them.
>
> 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.
>
> 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.
>
> 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.
>
> 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;
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160817/7ec1ca81/attachment.html>