LN is a bit like a spoke-hub: instead of making a connection from anywhere to anywhere, everyone makes only a few connections. That's just plain wrong. The Lightning Network is completely distributed at its core. It may be right for some services built on top of the Lightning Network, such as mobile wallet providers easing the flow by providing a gossip source or even a custodial wallet. But that must not be assimilated to the Lightning Network as defined. There were some previous models based on an *actual* hub-and-spoke architecture for payment channels, and they are very different from the Lightning Network. |
|
|
|
Downloading the Bitcoin Core client software from bitcoin.org seems a bit challenging and seems like it requires to understand how to use command line functions, which I don't have a good handle on.
You *absolutely don't* need any command line, or other typical-tech-savy-knowledge, to run bitcoin-core. Here is for example an overview of the GUI. In your case, i would recommend downloading the graphical (`bitcoin-qt`) client and set up pruning. The full validation is going to take some time and the GUI will hang during that time, once initial sync has been processed it'll be much faster to get up to date with the network when you start your bitcoin client. You can find binaries at: Don't forget to verify the signatures  |
|
|
|
Now the implementation is merged into the reference client, activation discussions slowly restarted on IRC (`##taproot-activation` on freenode). Here is a wiki page (thanks to David Harding) summing up the "main" different activation methods proposed so far, as well as a rationale and pros / cons for each of them. |
|
|
|
I don't really see big opportunity costs for Bitcoin hodlers if they provide liquidity for Lightning,
Agree, as it's actually a virtuous circle: the more participants/services join, the lesser the opportunistic cost. The lesser the opportunistic cost, the more new people join. Not even mentioning protocol upgrades that help this move forward (eg splicing out). So it's not really different if you hold the BTC (improductively) in your wallet.
Strongly disagree ! You are leaving your coins in a hot wallet on alpha software (and protocol!) here. So it *is* different, just a trade-off (that a lot of us choose to make, at least for part of their funds). |
|
|
|
Ok, that's a known issue with LND, but i thought it was patched. Thanks. The encountered error is due to a protocol violation by the node your friend is running. At some point either the LND implemention was sending some gossip messages in the wrong order (a channel update before a channel announcement). c-lightning v0.9.1-59-gd5cb0d8 If possible, please downgrade to the last release (git checkout v0.9.1). You are currently running master. Hope LND and c-lightning implementations can coexist and communicate between each other They are! That's why there is a protocol |
|
|
|
Hi, Yeah as mentioned above opening an issue is generally preferable as it gets more eyeballs than here (if a thread here is noticed at all). A few questions: - What version are you running ? - Did you try other peers as well ? - What implementation is your friend running ? What version ? - Could you provide slightly more logs (specifically the lines from `openingd` just before `peer_out WIRE_ERROR`) ? Is this a problem on my side?
Yes. I can connect to your friend's node just fine using both v0.9.0-1 and v0.9.1 . |
|
|
|
Again I am with a question.
When I open a channel, I only use the coins that are in the channel to move them back and forth. If I want to take out some of the coins that have gathered in the channel, I have to close it and open a new one, right?
Can anyone else fund my channel? For example, Bob and Alice have a channel that is 0.001BTC, can Jack transfer 0.0001 coins to Bob and Alice's channel outside the LN and thus increase the channel volume to 0.0011?
The idea is if someone has to send me BTC he can directly fund my channel.
No, this is called splice-in (or out - same but decrease channel capacity). See above, it's theoretically possible but not yet spec'ed. |
|
|
|
|
No, the signature is valid for an input but signs what the sighash mode tells it to sign. What i mean is that if you have a 2-input transaction with one NONE-signed input and one ALL-signed input, someone can just malleate the transaction by removing the ALL-signed input and creating an output paying them.
|
|
|
|
The use case I originally had in mind, as I wrote above, is an exchange or web wallet which would allow its users to "withdraw coins to a Lightning channel" with an onchain payment. Of course, if the exchange itself is connected to LN, and the channel of the user who wants this kind of payment is bidirectional, a direct LN payment is a better alternative. But there are cases where an on-chain payment could be preferrable:
- if the user wants to increase his LN capacity
- if he has only an unidirectional channel
- if the service provider (exchange, wallet etc.) isn't connected to LN, for example for regulatory reasons (I read this argument somewhen, but I dunno if it really realistic)
In a future with a more complex LN protocol wrt fees (currently the opener pays everything, which is a bad incentive for such entities to directly open a channel), the exchange could just open the channel and pay the opener through the first commitment transaction pair ? In these cases, for the service provider it doesn't matter to which address he pays, as long as the transaction is under control of the customer. The service provider simply "hands out control" of the used UTXOs to the customer and deducts the amount of them from the user's balance.
Yet another fundamental thought . In a future where a high number of people use Bitcoin LN won't be enough and we definitely need a way to: - Allow a shared management of utxos - Allow to hand utxos as you describe (without an onchain tx, so maybe hand the control of a LN channel ?) To the best of my knowledge the closest proposal to that are channel factories. So in this case, if I interpret the SIGHASH variants right (according to the above linked article), I could imagine a combination of SIGHASH_ANYONECANPAY with SIGHASH_NONE (if a whole UTXO under control of the service provider is used, the service provider simply "hands it out" to the customer and deducts the amount from his balance once the tx is confirmed - no matter to what address) or SIGHASH_SINGLE (if a part of the coins has to be transferred to a change address of the service provider) could be used for this kind of withdrawals.
By signing a transactiono using ACP|NONE you are giving the control not only to your customer but to anyone who claims it, so basically the first miner to include the tx . The only way to securely hand an utxo (still, that i know of) is currently to unlock it and re-lock it to the receiver through an on-chain transaction. There might exist some more complex design to hand the *control* or *part* of the utxo (re channel factories). |
|
|
|
The channel partner has a key, and in theory he could cooperate with the sender of the funding transaction. So what I meant was that the sender could send the money to the multisig address using another funding transaction which competes with the "legit" transaction which uses your input. We would arrive then at the same problem you described: the txid would have changed, invalidating the commitment transactions.
However, I don't know if this attack makes any sense - could the channel partner access these funds or could they only be mobilized again if both channel partners cooperate and provide their signatures to close the channel?
I don't think so, but i do think that it is an interesting thought because it comes to the blurry limits of what defines a Bitcoin payment. Not the technical mean which is the transaction, but the conceptual action of transferring value. If you hand me an address, and i do a transaction which pays to another address. Would you accept it as a payment ? No. If we collaborate to create a transaction to pay you, and i finally broadcast a different transaction, would you accept it as a payment ? You should not. This is not an attack, just an absence of payment. This is why I think the proof of payment feature of Bitcoin Lightning Network payments is important, and that we *must preserve it*. We can always bikeshed on the definition of an onchain Bitcoin payment, and endlessly argue if there was a transfer of value. If we use the Lightning Network, we just have a proof that the transfer occurred. |
|
|
|
There's a time lock added to commitment transactions of whatever the dev sets it at but its normally between 24 hours and 2 weeks depending on how active the node is - so this type of attack could be mitigated.
Yeah, i know about commitment transactions however i fail to see the attack. |
|
|
|
What if we organize the transaction in a different way: if you're the receiver, the sender of the transaction only signs his input, sends this information to you, and you use an additional input controlled by yourself and sign the TX? So you would have the control over the txid. This would result in a bigger transaction (in bytes) but still could have advantages over an approach with two transactions. But I don't know if Bitcoin allows that ...
Yes Bitcoin does allow that, and that's what is used by the channel dual funding proposal . EDIT: (just to be explicit) you would have to have some interaction with the sender though, as they need to know about your input to sign the transaction (with sighash ALL). The other way around would be to use ANYONECANPAY, but it's not possible as it would create a malleability vector (which becomes an attack vector in this case as it would change the txid). Possible problem: If the sender knew when you exchanged the commitment transactions and he cooperates maliciously with your channel partner, however, he could try to instantly spend the output in another transaction hoping it gets confirmed first than your transaction. This would be however a relatively risky attack.
How so ? The sender does not have a key in the multisig. |
|
|
|
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,
For the general case I tend to agree, but it is too big an assumption here because of how bad it can get. and you would also not lose anything beyond transaction fees.
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. |
|
|
|
I noticed you answered your question yourself after having written the answer, so here it is anyway (TL;DR: you are right). 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?
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. Or even better: use a BTC amount on-chain transaction and refund an already opened channel (this would be a kind of splice-in)?
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). 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.
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. |
|
|
|
|
@jackg : a wild guess, but maybe incoming capacity issues ? If you were able to send from both channels, then both can presumably connect and discover routes correctly. If you opened the channels that may be the reason.
|
|
|
|
Yes, the idea with the lightning network originally was that there were essentially 2 layers of nodes... The first layer deals with how to find people and routing information and the second deals with participating in the network (sending and receiving nodes but not necessarily routing).
Yep I'm aware, but I still don't understand the relation with being "more anonymous"?.. The only part of added privacy I can think of is your direct peer not knowing the full amount you want to transfer Since acinq at least used to have the longest running nodes and were the main developers I was trying to work out if there's a way to disable funds going through any main servers (even though we can probably trust the developers of the ln, no device is completely secure and if you want to be fairly anonymous)...
Why would you not want the ACINQ node to be in your route ? If they aren't the first node they don't know you are part of it .. In addition, regarding your sentence about trust in ln developers : you don't need to trust anyone in the network with your funds. Just the open source software you are running. |
|
|
|
is there a way to disable it if you wanted to be more anonymous?
To disable what ? MPP ? To be more anonymous how ? |
|
|
|
Hypothetical question. If I provide larger channel capacity in LN , but with moderately higher fees required, would you choose to pay my fee to complete payment "in a single shot"? Asking for a friend.
I think MPP will still only be used as a fallback for some time, so yes (your route will be tried first). However at some point if the sum of the base fee of the MPP routes is cheaper... No. |
|
|
|
I looked at statistics, the usage went up around last half 2019 then tapered off. looks like not that terrribly popular although not died.
Good news, less people open public channels and expose suboptimal routing nodes :-) IT seems stagnated. Are there benefits starting to weigh in?
Do you mean no technical improvements ? If so, LOL. I wonder if major wallets are supporting or starting to support LN?
Electrum |
|
|
|
Thus, it might seem a bad idea to allow unenforceable amounts We have the same in euros: most shops reject 1 and 2 cent coins, and yet most prices end on 9 cents. This is not comparable at all, I think. Shops reject 1 and 2 cents coins because they can't automagically get a 10$ ticket out of a thousand of them. On LN they can. And this was not about payments but about forwarding fees. Even if you can see an utility for payments too (pay-per-call on an API for example). Entire cents, currently worty far more than 100 satoshi, are lost due to rounding. And nobody cares  Why would anyone care about possibly losing a fraction of a satoshi due to rounding? Again, not comparable : my point that these tiny amounts may become valuable in a fraction of seconds. That is again true for a forwarding node or a payee for an autonomous service. OR for example, the possbility of a more than 6 digit per Bitcoin world. Instead of breaking Bitcoin's social contract by adding more decimal places onchain, do it in L2.  Absolutely, I think the need for those tiny amounts is already present today, and it might be even more with a price increase ! |
|
|
|
|
Show Posts
