Joseph Poon [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-11 📝 Original message: Hi Mats, Interesting work ...

📅 Original date posted:2015-08-11
📝 Original message:
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