From matsjj at gmail.com Tue Aug 11 18:42:50 2015 From: matsjj at gmail.com (Mats Jerratsch) Date: Tue, 11 Aug 2015 20:42:50 +0200 Subject: [Lightning-dev] ThunderNetwork - A Java LightningNetwork Implementation Working Today Message-ID: 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 : > 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