[Lightning-dev] An Argument For Single-Asset Lightning Network

2019-01-03 Thread Lawrence Deacon
Do cross-asset lightning nodes do not offer premium-free American call options? = I would argue that cross-asset lightning nodes do not offer premium-free American call options for the following reasons. Say I wanted to set up to purchas

[Lightning-dev] Reuse of payment_hash in lightning invoices

2019-01-03 Thread Andrea RASPITZU
Good morning list, I wanted to know your thoughts about the reuse of payment_hash in lightning invoices, currently BOLT11 uses as example a donation invoice which seems to be "permanent" i.e the payment_hash isn't changing after having received a donation.I believe the reuse of known payment_hash

Re: [Lightning-dev] An Argument For Single-Asset Lightning Network

2019-01-03 Thread ZmnSCPxj via Lightning-dev
Good morning Lawrence, While true, on Lightning, interest earnings are ***tiny*** enough that the premium "paid" in this manner is minimal. Increase in alternative interest earnings for Bitcoin on non-Lightning alternatives would also cut down the available liquidity on Lightning and increase L

Re: [Lightning-dev] Reuse of payment_hash in lightning invoices

2019-01-03 Thread ZmnSCPxj via Lightning-dev
Good morning Andrea, > For example a malicious receiver can provide an invoice with assisted routes > where among those he/she controls a node and that node won't forward to the > htlc but steal the funds instead (the preimage is known to the intermediate > node as well), thus it will be claime

Re: [Lightning-dev] An Argument For Single-Asset Lightning Network

2019-01-03 Thread ZmnSCPxj via Lightning-dev
Good morning Lawrence, On re-reading your argument, no, you have misunderstood massively. The two HTLCs together form a *single* American Call Option, issued by the exchange to the initiator of the "payment". It is not the initiator somehow issuing an American Call Option to itself by routing

Re: [Lightning-dev] An Argument For Single-Asset Lightning Network

2019-01-03 Thread Lawrence Deacon
Good morning, > On 3 Jan 2019, at 13:04, ZmnSCPxj wrote: > > Good morning Lawrence, > > While true, on Lightning, interest earnings are ***tiny*** enough that the > premium "paid" in this manner is minimal. > Increase in alternative interest earnings for Bitcoin on non-Lightning > alternati

Re: [Lightning-dev] An Argument For Single-Asset Lightning Network

2019-01-03 Thread Lawrence Deacon
> On 3 Jan 2019, at 13:24, ZmnSCPxj wrote: > > Good morning Lawrence, > > On re-reading your argument, no, you have misunderstood massively. > > The two HTLCs together form a *single* American Call Option, issued by the > exchange to the initiator of the "payment". > > It is not the initiat

Re: [Lightning-dev] Reuse of payment_hash in lightning invoices

2019-01-03 Thread Andrea RASPITZU
Okay so the knowledge of a preimage for a certain payment_hash is the sufficient (and only) payment proof for the payer. But in any case the reuse of payment_hashes should be strongly discouraged, in the donations scenario 2 donors will send across the network a payment for the same preimage and if

Re: [Lightning-dev] Quick analysis of channel_update data

2019-01-03 Thread Fabrice Drouin
Follow-up: here's more detailed info on the data I collected and potential savings we could achieve: I made hourly routing table backups for 12 days, and collected routing information for 17 000 channel ids. There are 130 000 different channel updates :on average each channel has been updated 8 t

Re: [Lightning-dev] Quick analysis of channel_update data

2019-01-03 Thread ZmnSCPxj via Lightning-dev
Good morning, > - in set reconciliation schemes: we could reconcile [channel id | > timestamp | checksum] first Perhaps I misunderstand how set reconciliation works, but --- if timestamp is changed while checksum is not, then it would still be seen as a set difference and still require fu