@bitcyptex, he seems to think push is receivable amount (I think) it's good that you can customise it as you normally can't on the mobile wallets.
Well, he is not completely wrong. He is now able to receive coins over the Lightining Network. However, the other party can spend the coins which were pushed to them. This feature can be also useful in some other ways.
Also I think his transaction failed because he was trying to send testnet bitcoins to a lightning bitcoin node (just thought I'd make this clear if anyone was wondering).
That's not it. The website he used generates invoices for the testnet. Take a look at the following piece of code.
Code: (https://github.com/spesmilo/electrum/blob/0966edc637ba927ea6767b44aa937b0ca7805dd7/electrum/lnpeer.py)
if htlc.cltv_expiry - lnutil.NBLOCK_DEADLINE_BEFORE_EXPIRY_FOR_RECEIVED_HTLCS <= local_height \
or next_cltv_expiry <= local_height:
reason = OnionRoutingFailureMessage(code=OnionFailureCode.EXPIRY_TOO_SOON,
data=outgoing_chan_upd_len+outgoing_chan_upd)
await self.fail_htlc(chan, htlc.htlc_id, onion_packet, reason)
return
htlc.cltv_expiry seems to be the culprit here. If you compare the 'Time Lock Delta' for both testnet and mainnet on 1ml.com, you will see that it is equal to 40 and 144 respectively. At the time of the recording, the blocks on the testnet were mined one after another. If you take both of these factors in the account then it seems that that's the reason why it didn't work. It's a bit late here so I will investigate it further tomorrow.
Note: It seems that some mainnet notes have set their 'Time Lock Delta' to 40 or lower. The blocks on the mainnet are mined not as fast as on the testnet so it shouldn't impact the mainnet Lightning Network transaction failure rate significantly.
Quote from: https://bitcoin.stackexchange.com/a/87295
The time_lock_delta is the minimum difference in the number of blocks between the CLTV of an incoming HTLC and the forwarded HTLC.
I would appreciate if someone could link this post under that YouTube video.
