Topic: The Lightning Network FAQ - page 61. (Read 33714 times)

I think bitcoin too was made overly complicated for the average person - but I don't know what the average person wants. Most currency systems could do with a mixture of government banks and private holders imo.

For the general case I tend to agree, but it is too big an assumption here because of how bad it can get.


No! You would loose the complete access to the utxo, as in this case you comitted to a multisig with your channel partner [which you don't trust and] which provided you with a "refund" transaction... Not valid anymore (as it spends a non-existent tx). As this "refund" transaction is actually the first commitment transaction, neither the channel can operate.
The only way out of this is to beg your channel partner to be nice and sign a new refund tx for the real tx.

Both the spender and your channel peer have a leverage on you.

In my post there was an error (because I had changed the wording to be clearer from active to passive but forgot to change a crucial part  ). so I think your post answers the "wrong" question correctly. What I meant was to open a channel for the receiver of the coins, not the sender. Thanks anyway

@darosior: Thanks! So it works a bit like I imagined. But your answer made it clearer for me, above all the part you highlighted about the trust which is necessary for the transaction sender. Incentive-wise, however, in the case the sender is a service like an exchange, which must be profitable and thus "just work", there is no reason for him to "cheat" changing the transaction ID, and you would also not lose anything beyond transaction fees.

Thanks also about the hint about the mailing list discussion, will see if I find it.

I noticed you answered your question yourself after having written the answer, so here it is anyway (TL;DR: you are right).

Yes, but only if the sender effectively cooperates as otherwise your funds would be stuck in limbo.

You need to:

• Start the funding process with your peer (here you get the keys to form the 2of2 Script)
• Get the sender to create a transaction which pays to this Script and hand you the txid
• Complete the funding process with your peer by exchanging the commitment transactions refering to the txid
• Have the sender broadcast the transaction (hence trusting them to not change the transaction, which would change the txid before doing so.

FWIW, it's possible with c-lightning if you want to try this out with the (dangerous) fundchannel_start, fundchannel_complete commands.


It's possible in theory but has not been spec'ed. You can find some discussions about this on the #lightning-dev ML (end of 2018 iirc).


Yes, splice-in / splice-out would be great (and a lot of people are looking forward to it) but is quite complex state-machine-wise.

Gigameg blocks, the miners, the pools, and the data-center-node-operators bear the cost, and also at a cost to the user because he/she cannot verify the transactions him/herself.

I know it's not convenient for most of the people to run a full node, but it shouldn't suggest that the Core developers must make design-decisions that should take away anyone's ability to run one.

The on chain transition to you would need to have two (or more) outputs, 1 the 'on chain' transaction to you and 2 an output that gets 'locked' in a newly opened channel. This would work very similar to someone opening a channel valued less than the value of an input (less tx fees), and the remaining value being sent to one or more change addresses.

A technical question:

Is it possible to receive a BTC amount on-chain from another person and simultaneously open a LN channel for him/her for me with the same transaction, if the sender cooperates? Or even better: use a BTC amount on-chain transaction and refund an already opened channel (this would be a kind of splice-in)?

In theory (if I remember well the funding mechanism of Poon-Dryja channels) at least the first variant (opening a new channel) should not be a problem if you exchange the commitment transactions with your channel counterparty based on the transaction you got from that other person. For this to work, however, the person who has sent the transaction must cooperate and broadcast the transaction to the channel's multisig address only after this exchange took place (which could lead to "logistic" challenges but should be solvable). About the second variant (add the transaction amount to an existing channel), I don't know currently much about splice-ins, but maybe someone here does

I imagine this could be useful if exchanges offered this service. You could withdraw an amount on-chain, and instead to have to do the channel opening transaction yourself additionally, the withdraw amount is added to an existing payment channel or opens another one to a LN node.

---

Ah, and @Khaos77: All altcoins which reach a certain popularity will get the same transaction cost problem as Bitcoin. Even sooner or later with big blocks (if they are not gigabyte-sized ).

Edit: There was an error in the first paragraph, I corrected it.

Providing financial services to third world countries are difficult because of the very small amounts of money involved that will often not result in meaningful profits for anyone for someone in a first world country doing business.

LN may make some inroads into third world countries that are relatively wealthy, but I would see its primary user base to be those in developed world conducting high volume transactions.

Altcoins have been subject to 51%-type attacks with increasing frequency as of recently. This means that for most altcoins, waiting 60 minutes (equivalent to 6 bitcoin confirmations in terms of blocks found), when the altcoin gets the target rate of confirmations, will not give the same level of confidence that it will not be reversed. 

Yeah there's a limit to security with a lot of altcoins for sure and the only two I've looked into that have similar security or theoretically better were litecoin (and decred if the PoS part works).


There's going to be a short answer and a long answer herevand I'll go with the shorter.
So when you receive a transaction the sender signs a receiving transaction identifier of their own in order to spend the funds to you. They then broadcast this transaction to the network so miners can take a look at it and confirm it.

When you want to spend your bitcoin you do the same steps again and sign your input transaction identifier.

The fiat inflation won't be a problem, there still won't be much use for the current equivalent of a penny, even if it's called a dollar by then.
I don't expect Bitcoin deflation due to lost funds to reach an order of magnitude any time soon, so that shouldn't be much of a problem either.

I believe the problem with using altcoins is they're not as secure, not as robust, and not as valuable as Bitcoin. They can use it as a MOE, but most of the time, convert back to Bitcoin for safe-keeping. How much would the costs of conversion be?

This is considering inflation of the fiat currency doesn't exist and deflation of bitcoin due to lost funds also doesn't exist.

I get that it makes less sense but even if a Satoshi is 0.1 cents, you might still want more accuracy - and it's free on the lightning network.

You can use LN without going back on-chain. I feel like I'm mentioning my favourite mobile LN wallets too much already (BlueWallet and Phoenix), but it just works well. The former is custodial, the latter creates a channel for you. With both, you can receive and send LN funds without worrying about on-chain transactions by yourself. So $5 will be 42,000 sats, and transactions will cost (much) less than 1% in fees.

I'm pretty sure the idea was that 1 satoshi would never be worth more than a penny

Afaik the idea Satoshi had was 1 Satoshi being $1.

Already you need 2 significant figures to handle cents. Then what if someone from Sweden wants the more accuracy down to a hundredth of a króna? 1 Swedish króna = 0.12 us dollar. So thats already 0.001 Satoshi?

Then there's rupees which need even more sf.

Edit: by sf and significant figures I mean the numbers after the decimal point.

The other issue is we are talking USD and such. There are some currencies out there that are worth a lot less then that. And people might need to send what is a fraction of a US penny to someone because where they are that is all they need to do in the local fiat.

-Dave

I think the confusion is mine.  I thought you were talking about having millisats on-chain at some point in future.  Seems I misinterpreted your post.

What? But I thought it doesn't include the extra 4 decimal places onchain after closing of the channel because the extra 4 are unenforeable. I'm currently confused. Hahaha.

This explains the choice for 8 decimals:
Of course this ignores the possibility of micropayments, which could be in-game, on-demand, or pay-per-second. But even if a service would offer to pay a fraction of a cent, they could use their internal calculation system (kinda like LN is doing). For example: if an in-game sword costs $0.001, you can deposit $0.01 and still have $0.009 left.. And since it's less than a penny, even though you can't withdraw it, you wouldn't care.
I don't think I've ever paid anything less than $0.01 though.

A VoIP provider might be a better example: they often charge fractions of a cent per minute, and just take it off your balance. You can't deposit $0.01, but once it's in your balance, you can pay fractions of a cent.

I suppose the only question remaining would be "Are there any downsides from a technical perspective"?  If there's no harm in future-proofing, it seems like an obvious thing to do.  So I can't help but think that if there were no cost to doing it, it might have been implemented before now.  I'm guessing that perhaps it makes transactions larger if we have to store extra digits in the blockchain?  Another 4 characters to go from 8 to 12 decimal places may not sound much, but ideally we want transaction sizes smaller to aid with scaling.

Millisats might not be a feature we need now, or something we can't think that we would need tomorrow, but in my opinion, it might be a feature that we might be thankful for, and thank the developers, for having the vision, IF in case Bitcoin "goes to the moon" of a different solar system. Haha.