[Lightning-dev] ThunderNetwork - A Java LightningNetwork Implementation Working Today

[Mats Jerratsch]

Hey Joseph,

thank you very much for your invaluable feedback!

Can you elaborate, why you think that the client is not able to close
the channel? I think this is a misunderstanding on your side, which
most of the rest of your post argues from. While there is a slight
favor for the server in the channel design, there is nothing what
prevents the client from broadcasting (and enforcing) the channel.

I will of course respect your inquiry - if you really mean it after
that misunderstanding - and stop calling it a Lightning Network
implementation as long as it does not provide the complete no-trust.

I have thought a lot about RBF, and it is definitely a problem with
this implementation.

2015-08-11 20:30 GMT+02:00 Joseph Poon <joseph at lightning.network>:
> Hi Mats,
>
> Interesting work on payment channels, I think a lot of the bitcoinj code
> can be used for further development as the necessary bitcoin softforks
> for LN are incorporated. A bitcoinj implementation for lightning would
> be great!
>
> On Tue, Aug 11, 2015 at 06:12:04PM +0200, Mats Jerratsch wrote:
>> I present you a implementation for a Lightning Network Payment-Hub +
>> Client. Everything is written in Java and can be accessed on
>
> Can you do me a big favor and not call this an implementation for
> Lightning Network, though? I would prefer some name like "payment
> channel networks" or something similar, as it's materially different in
> design and trust models. In particular, if exit scams occur, I don't
> want it to be associated with Lightning Network.
>
>> I made some changes to the channel design to have everything working
>> on the current Blockchain, without the need for softforks. Due to
>> that, the network is no longer no-trust, but low-trust. This will
>> change with the upcoming new OP_CODES.
>
> Yeah, a lot of the code can definitely be used for a full LN
> implementation when the opcodes come in for sure!
>
>> The provided wallet is just a prototype, I will focus on building a
>> potent backend in the future. There are many wallets out there
>> already, it will be much more useful if those add these
>> functionalities.
>
> Some quick feedback (might have more later):
> * I don't think a dual-Commitment structure is necessary if only one
>   party can close out the channel. The purpose of having two Commitments
>   is so that the payout structure is different. In this case, since only
>   the server can broadcast the final balance (and the client has no way
>   to close out the channel), only the B Commitment is necessary).
> * HTLCs have significant malleability risks with malicious servers
>   (hostage scenarios).
> * If you presume full-RBF (which I think is a game-theoretic
>   eventuality), clients can pay a higher fee to mutate the server's
>   broadcast of the Commitment, which will result in the server's funds
>   being held up permanently until the server is willing to negotiate
>   (malleability hostage scenario).
> * Exit Scamming is a distinct and likely possibility. The server can
>   develop a good reputation for a while, then decide to screw over
>   everyone. The server refuses to do any further transactions in any
>   channel which has funds in the clients favor (current channel balance
>   for the client is above what was funded). With the timeout, the server
>   gets the original deposit back, which is above what they should get
>   back, in other words, the server steals your money.
> * This creates an asymmetric playing field. If one cannot be confident
>   they will receive their funds back, this is similar to depositing your
>   money on a hosted wallet such as Coinbase or whatever. The primary
>   value of transacting on bitcoin is that the social costs of
>   counterparty risks are minimized -- and counterparty risk is one of
>   the primary inputs on interest rates (remove trust -> remove
>   counterparty risk -> remove fees/interest). This can only exist if
>   you're sufficiently willing to transact with nearly anyone (minimal
>   underwriting).
>
>> Furthermore, as there are less everyday payments on the blockchain,
>> there is more space for important transactions of higher value.
>
> I agree that this is one of the primary values of payment channel based
> systems. To extend and take your point in a different direction, there
> is a risk if everyone uses blockchain transactions for every day
> purchases, that high-value transactions will crowd out low-value
> transactions. There is a tension that exists between the need for
> sufficiently high fees to pay miners (when the block rewards decline)
> and allowing low-fee transactions to be on-chain in a timely manner.
>
> --
> Joseph Poon