Mats Jerratsch [ARCHIVE] on Nostr: š Original date posted:2015-08-11 š Original message: Hey Joseph, thank you ...
š
Original date posted:2015-08-11
š Original message:
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
š Original message:
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