From joseph at lightning.network Tue Aug 11 18:30:47 2015 From: joseph at lightning.network (Joseph Poon) Date: Tue, 11 Aug 2015 11:30:47 -0700 Subject: [Lightning-dev] ThunderNetwork - A Java LightningNetwork Implementation Working Today In-Reply-To: References: Message-ID: <20150811183047.GC8380@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