but it is funny how you are using bolt2 (Peer Protocol for Channel Management).
and avoiding yet again:
bolt4: (Onion Routing Protocol)
bolt11 (Invoice Protocol for Lightning Payments)
Let me repeat again. bolt11 describes only how a payment invoice should be encoded/decoded. As for the bolt4: This document describes the construction of an onion routed packet that is used to route a payment from an origin node to a final node. bolt4 describes how the onion packet is constructed and how it can be validated by each node. It does not describe how it is passed around. Here's a piece of information from bolt2: The format of the onion_routing_packet portion, which indicates where the payment is destined, is described in BOLT #4.
type: 128 (update_add_htlc)
data:
[channel_id:channel_id]
[u64:id]
[u64:amount_msat]
[sha256:payment_hash]
[u32:cltv_expiry]
[1366*byte:onion_routing_packet] The "onion_routing_packet", which contains encrypted instructions for each hop, is a part of "update_add_htlc". So, Carol doesn't know anything about Diana unless Bob sends her "update_add_htlc". Bob can't send it unless Alice replies with "commitment_signed" and they finish exchanging revocation keys. Why? Again: Forwarding HTLCs
Requirements
A node:
until an incoming HTLC has been irrevocably committed:
MUST NOT offer the corresponding outgoing HTLC (update_add_htlc) in response to that incoming HTLC.
If you still disagree, tell me what kind of message nodes use to forward the "onion_routing_packet" without triggering the update of the commitment transaction. the millisat payment comes first. and is then rounded up/down into sat commitment as a second part
That's exactly what I have said in my previous post: The receiving node routes down the value to whole satoshis before preparing and signing the commitment transaction. The sending node does the same for their version of the commitment transaction. If either of them doesn't do that, the HTLC can be failed.
payment_hash (same for all parties involved in a route).. and its payment _secret (same for all parties of a route) is for the msat payment.
separetly the localpubkey remotepubkey(just between channel peers) and revoke keys(just between channel peers) are buzzwords for the channel commitment
Payment secret and payment hash are also used in the locking script of the HTLC output in the commitment transaction. payments are done as a separate HTLC(in msat) and once E has received the payment_hash from D, who got it from C, who got it from B who got it from A(who got it from E). then E knows to send payment_secret to D, who passes to C, who passes to B who passes to A. and then A and B make the commitment where B is deserved the value
You still haven't answered my question. How do all of these nodes communicate? How do they forward the onion packet?
Is there anyone here who is following our discussion? |
|
|
|
remember eric gives alice the payment_hash for the micropayment (millisat promise) with bob (not commitment)
bob uses the payment_hash to carol for his micropayment (millisat promise) with carol (not commitment)
carol uses the payment_hash to diana for her micropayment (millisat promise) with diana (not commitment)
diana uses the payment_hash to eric for her micropayment (millisat promise) with eric (not commitment)
eric then gives diana the payment_secret which she passes to carol who passes to bob who passes to alice
Alice offers Bob an HLTC ("update_add_htlc") and waits for "commitment_signed" which contains signatures for the commitment, HTLC-success and HTLC-timeout transactions. Forwarding HTLCs
Requirements
A node:
until an incoming HTLC has been irrevocably committed:
MUST NOT offer the corresponding outgoing HTLC (update_add_htlc) in response to that incoming HTLC.
Bob won't talk to Charlie unless he signs a new commitment transaction with Alice. If you believe that Bob and Charlie can communicate in a different way, tell us what kind of messages they use. because if you really think there is no ABCDE millisat micropayment temporary promise using H and R. and you think H and R are only used by commitments and only commitments exist. then erics H is going to be in AB's commitment which if AB broadcast such a commitment. then eric can spend the utxo put into his H using his R
thats why LN payments are separate and another reason why they dont get broadcast. aswell as being in a format not understandable to bitcoin network. to prevent eric from scamming alice and bob.
Did you read the other half of my post? Eric also needs two valid HTLC signatures that can be produced only by Alice and Bob. as for you saying in your post that you explained it already using your node logs
The logs also include commitment related messages. 2021-12-30T02:00:21.308Z DEBUG 03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: Creating commit_sig signature [REDACTED] for tx [REDACTED] wscript [REDACTED]
2021-12-30T02:00:21.310Z DEBUG hsmd: Client: Received message 20 from client
2021-12-30T02:00:21.310Z DEBUG 03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: Creating HTLC signature [REDACTED] for tx [REDACTED] wscript [REDACTED]
2021-12-30T02:00:21.311Z DEBUG 03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-chan#85: HTLC in 403 SENT_ADD_REVOCATION->SENT_ADD_ACK_COMMIT
2021-12-30T02:00:21.365Z DEBUG 03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: Sending commit_sig with 1 htlc sigs
2021-12-30T02:00:21.366Z DEBUG 03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: peer_out WIRE_COMMITMENT_SIGNED
you can tell because it says to add "amount=97653097msat" and we all know a "bitcoin commitment" does not handle msats. so whats being signed. is not a bitcoin commitment but a msat based LN payment
The receiving node routes down the value to whole satoshis before preparing and signing the commitment transaction. The sending node does the same for their version of the commitment transaction. If either of them doesn't do that, the HTLC can be failed. when talking about payments in LN.. dont confuse the matter by using bolt2 (channel management) and instead use reference from bolt11 (invoice payment)
bolt11 describes only how a payment invoice should be encoded/decoded. |
|
|
|
B does not update the A<>B 'commitment'. until after E promise is signed, which then pases to D, which then passes to C, which then passes to B
[...]
(A wont sign a commitment until it receives R(private key))
Alice finds various paths and needs to try them one by one to see if selected nodes have enough liquidity to forward her payment. There is no other way to do that other than to send "update_add_htlc" and sign a new commitment transaction. Once both nodes have exchanged funding_locked (and optionally announcement_signatures), the channel can be used to make payments via Hashed Time Locked Contracts.
Changes are sent in batches: one or more update_ messages are sent before a commitment_signed message, as in the following diagram:
+-------+ +-------+
| |--(1)---- update_add_htlc ---->| |
| |--(2)---- update_add_htlc ---->| |
| |<-(3)---- update_add_htlc -----| |
| | | |
| |--(4)--- commitment_signed --->| |
| A |<-(5)---- revoke_and_ack ------| B |
| | | |
| |<-(6)--- commitment_signed ----| |
| |--(7)---- revoke_and_ack ----->| |
| | | |
| |--(8)--- commitment_signed --->| |
| |<-(9)---- revoke_and_ack ------| |
+-------+ +-------+
I have already proved that in this post by showing you my node logs. If one the selected nodes is unable to forward the payment due to no liquidity in the outgoing channel, it sends "update_fail_htlc". Please, don't bring up "funding_locked" again. It is used only to signal that the funding transaction has reached enough confirmations for the channel to operate safely. by the way, A,>B do not create a 'commitment' at 2 using H(erics public key) in a commitment. because A<>B know eric has the privatekey(R) and if A or B broadcast a commitment with H, eric can jump in and send funds to where he likes using R.
No, Eric can't do that. HTLC outputs in commitment transactions require not only the payment secret to be spent but also a valid HTLC signature. When you open a channel, you share your htlc_basepoint, which is a compressed public key used only for HTLC payments in this particular channel. The other node shares their htlc_basepoint as well. You can use htlc_basepoint and per_commitment_point to calculate local_htlcpubkey and remote_htlcpubkey. Now, let's take a closer at locking scripts of HTLC outputs. Commitment transactions are asymmetrical which means that there are two possible scenarios: 1) (Offered) HTLC output in Alice's commitment transaction: # To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
OP_CHECKSIG
OP_ELSE
<remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
OP_NOTIF
# To local node via HTLC-timeout transaction (timelocked).
OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
OP_ELSE
# To remote node with preimage.
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
OP_CHECKSIG
OP_ENDIF
OP_ENDIF If remote_htlcpubkey (Bob's HTLC pubkey) is on the stack then the provided secret (the payment preimage) is hashed and checked against the payment hash. Otherwise, this output can be spent via a HTLC-timeout transaction which is timelocked and signed by both parties beforehand. Eric or any other intermediary node cannot spend this output as they cannot produce a valid signature for that public key. 2) (Received) HTLC output in Bob's commitment transaction: # To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
OP_CHECKSIG
OP_ELSE
<remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
OP_IF
# To local node via HTLC-success transaction.
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
OP_ELSE
# To remote node after timeout.
OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_CHECKSIG
OP_ENDIF
OP_ENDIF If remote_htlcpubkey (Alice's HTLC pubkey) is on the stack then the provided secret (the payment preimage) is hashed and checked against the payment hash and the output can be spent via a HTLC-success transaction. Again, Eric or any other intermediary node cannot spend this output as they cannot produce valid signatures for these keys. HTLC-timeout and HTLC-success transactions, which require both Alice's and Bob's HTLC signatures, consume HTLC outputs and create another locked output which is delayed so that the other party has enough time to broadcast a penalty transaction if necessary. |
|
|
|
Creating multiple wallets with 2 or 3 passphrases is a interesting feature for me. Can i do this in Electrum? [...] When i open my wallet with the pin, then is there any way to open some hidden child-wallets?
You need to create a separate wallet for each passphrase. Create a new wallet with the same seed. Once you type in your seed, select "Options", "Extend this seed with custom words" and add your passphrase as the 13th word. Only 2.7 kByte. Maybe have to put some coins in, then the file will be heavier.
Yes, it will be larger. Some of my wallets weight more than 1 MB. Once you enable and use Lightning, it should increase in size significantly. |
|
|
|
Manager: HhampuzNazwa kampanii: AllStarsBet101.comIle do zarobienia/tydzień / ilość postów: Sr Member - $45 w BTC/tydzień, Hero Member/Legendary - $60 w BTC/tydzień Jakie rangi: 6x Sr Member, 8x Hero Member/Legendary Dodatkowe informacje: Minimum 20 postów tygodniowo, w tym minimum 10 w sekcji Gambling. |
|
|
|
For example, I have read about instances in which an LN node failed, the user restored from a backup that did not have the correct channel state, which resulted in the backup-restored node trying to close the channel via an old channel state.
You're right. Although, it's fairly uncommon to run an old backup, even unintentionally. LND by default generates static backups, which can be only used to request the other party to close a channel. C-lightning's backup plugin backups the whole channel database to a remote directory/drive and it constantly overwrites old backups. What's the best channel_capacity/network_contribution ratio? For instance, would it be more contributive to open 100 of 0.01 BTC rather than 2 of 0.50 BTC?
100 channels sound better. If someone undercut (in terms of fees) only some of your channels, it should not impact your routing effectiveness greatly. Also, you are more likely to get more routing attempts through you as long as you choose channels and set your fees reasonably. Also, how do I choose the proper nodes to do this?
That's one of the trickiest parts of running a Lightning node. I usually select some random medium-sized nodes from either amboss.space or 1ml.com and then check the shortest path from my node to theirs using lnrouter.app. Don't forget that path finding algorithms also take the route length into consideration. Also, how do I choose the proper nodes to do this? I had read about triangles, but I'm not sure if that's what I'm talking about.
You can learn about liquidity triangle/square/pentagon swaps here. Once you set up a mainnet node, you can use that website to find partners for the swap. Liquidity swaps might actually improve your routing performance. Yesterday, I performed a triangle swap with two other bitcointalk members. Each of us opened a 0.05 BTC channel to the other person. This way, we gained additional 0.10 BTC capacity, which means that this swap has doubled my node's capacity. I paid 222 sat for the opening transaction. We dropped the fees to 0 and TheJuice's script took care of the rebalancing. On the same day, I routed 6 transactions from the channel I opened and I got paid 222.76 satoshi. The channel paid itself off in just a few hours.
|
|
|
|
So every day i end my business with Elektrum, then i make an backup. And then i can restore everything if needed (File -> Save backup), even the lightning channels, right?
I quickly glanced over Electrum GitHub page and it turns out that such backups contain only static backups of Lightning channels. They can be only used to force-close channels; in other words, you will be able to recover your funds, but you won't be able to make Lightning payments anymore. You should make a new backup whenever you open a new channel. If you want to make a backup which will allow you to keep using your channels, you have to copy your wallet file manually. It is located in %appdata%/Electrum/wallets directory. However, this is extremely risky. If you accidentally use an out of date copy, you might lose some of your coins due to conflicting channel states between you and your channel partner. “move your coins” and “non-chain transaction” is “Lighning”? Or did You mean “copying”?
" on-chain transaction" and "move your coins" refer to a normal Bitcoin transaction from one address to another. Is it not possible to transfer the last PC-backup to mobile Elektrum App and restore and work there? (Same version of Elektrum)
I don't think that you can import a PC backup on your mobile and vice-versa, but don't quote me on that. |
|
|
|
You cannot change your seed and passphrase (13th word).
To be precise, you can import your existing seed and extend it with any passphrase, but as others have said, Electrum will generate completely different addresses. So, if only your passphrase is compromised, you can safely reuse your seed if you stored it in a separate location. However, you will need to move your coins via an on-chain transaction to a new address. |
|
|
|
So is it not an good advice to use extra words as an passphrase? It an extra security to the wallet, isn’t it?
It is a good idea to set a passphrase as long as you have a reliable backup strategy. You should not keep your seed and passphrase together. Some people and shops using Lightning because it’s cheaper and faster. If i have to restore the wallet (maybe lost) with the seed, will everything be restored, even all Lightning-nodes and payments?
You can't restore your Lightning channels from your seed. You have to use the built-in backup functionality (File -> Save backup). However, you should avoid importing old wallet backups as it might cause your Lightning channels to close and in some edge cases, you might lose money. You can safely recreate your wallet with your seed on some other device at any time, but you won't be able to access coins locked up in your channels. By the way, if you want to learn more about Lightning support in Electrum, visit Electrum Lightning Network walkthrough. If i restore the wallet, can i saftly change the seed/pin so that the wallet cannot be compromised from others, someone who found it?
You cannot change your seed and passphrase (13th word). You can change your wallet password which only encrypts your wallet file. You should generate a new seed and move your coins if your wallet is compromised. |
|
|
|
That would explain it, thank you would my computer of been infected from a download of some sort ?
There are plenty of ways. You might have downloaded an infected file or entered a website which exploited some kind of browser vulnerability to infect your computer. You might want to try downloading Malwarebytes to scan your computer and see if it would have warned you. You should reinstall your OS anyway. |
|
|
|
Some other user reported a similar problem a few months ago with the same Bitcoin address. It looks like your computer has been infected with some kind of clipboard malware which replaced your Electrum address with the one you posted. Make sure to follow these instructions: You need to format your computer, reinstall your OS from scratch, download Electrum and ensure you verify your download prior to installing, and then create a brand new wallet and a new seed phrase.
You won't be able to get your coins back. |
|
|
|
Jeżeli zastanawialiście się jak często ktoś może spróbować Was oszukać poprzez zamknięcie kanału nieaktualną transakcją, to znalazłem stronę, która pokazuje wszystkie nieudane próby oszustw. Od końca 2017 roku, 419 prób oszustwa zostało udaremnionych, przez co ~5,13 BTC trafiło w ręce poszkodowanych. Strona nie pokazuje udanych prób, bo technicznie nie ma możliwości, żeby odróżnić je od innych transakcji. @cygan, jak idą prace nad Twoim węzłem?  |
|
|
|
Someone said always generate a new btc receiving address you receive each time you receive so that way... people wouldn't know about your transaction history and they wouldn't know if you own how much btc. Would you say that is accurate then?
Sounds good. However, you will need to be extra careful when you decide to spend your coins. Ledger Live might automatically combine inputs from different addresses in the same transaction which would leak that you control all of them. You can use coin control in Electrum to get around this problem. Alternatively, you can use different accounts in Ledger Live if you really don't want to mix up two or more different addresses. So you telling me if there is 1 or 2 confirmations, its still possible for a transaction to get reversed/cancelled? Or is the only term for that called double spend? The thing is I would be trading with stranger so I want to make sure I am receiving the btc.
Learn about chain reorganisations and a 51% attack. You should be fine with 1 confirmation for most of the time. Even if your incoming transaction is included in an orphaned block, it should be also mined in the longest chain as miners select transactions mostly based on their fees. So blockstream.info is the main website for checking the status of a transaction?
No, there are quite a lot of block explorers out there, for example: mempool.space, blockcypher.com, blockchair.com. You can use whichever you find to be the most intuitive. |
|
|
|
But what if Bitcoin Core suddenly also rebroadcasts my transaction (though this has not happened, hence my post)? If both broadcast it, am I not in risk of double spending?
You have nothing to worry about. Bitcoin Core would rebroadcast the same transaction so it wouldn't be considered as a double-spend attempt. If some node receives the same transaction then they simply ignore it since it's already in their mempool. |
|
|
|
Alternatively, you could also use getrawtransaction "txid". The command should return you hex-encoded data which you can paste, for example, here. Your wallet should periodically rebroadcast your transactions, but this way, BlockCypher will do it for you. |
|
|
|
Bitcoin Core has the option of 'abandon transaction' greyed out on the transactions.
Try abandoning the transaction manually in the console. Select 'Window -> Console' (or press CTRL+T) and type in: abandontransaction "txid". You might also need to remove mempool.dat from your data directory beforehand. |
|
|
|
If you ever wondered how often someone is penalized for fraudulent behaviour, forkmonitor keeps track of all penalty transactions ever broadcast. Apparently, there have been 419 unsuccessful cheat attempts with a total of ~5.13 BTC at stake since the end of 2017. |
|
|
|
Trochę jestem spóźniony, ale też przyłączę się do życzeń Skoro rzucacie takimi pozytywnymi predykcjami, to nie zapomnijcie o konsolidacji wyjść, póki opłaty transakcyjne są niskie. Przynajmniej jeden kanał Lightning też może się Wam przydać. Myślę, że warto o tym pomyśleć za nim zrobi się znowu gorąco. |
|
|
|
When you're more encouraged than discouraged to play by the rules is when things work properly. I have never been cheated by my lightning partners, have you?
You don't have do it on purpose. Accidents happen. Someone could run an old backup and close the channel using their (outdated) commitment transaction. oh and watchtowers can only intercept and change ownership if you trust them to have the keys to do these interceptions on your behalf..
Watchtowers do not hold any keys. They only store pre-signed penalty transactions in an encrypted format. See LND's altruist watchtowers. |
|
|
|
franky1, please stop editing your posts and make new ones instead. It's really difficult to keep up with you when you edit the same post over and over again. LN has no network wide audit/consensus that checks that all nodes/channels are all connected to the bitcoin network.
The only reasons why you need to be connected to the Bitcoin network are: 1) you need to check if the funding transaction has been confirmed 2) you need to process new incoming blocks and check if the other party didn't broadcast a commitment transaction 3) the other party might request a fee update to the latest commitment transaction; if your response is too low or too large then your peer might close or temporarily disable the channel Currently, the third point enforces connection to some Bitcoin backend, but I could see someone modifying their client to use some third-party source for fee estimates. However, this would put them at a risk as someone could close the channel and keep using it. The modified node would keep singing new commitment transactions even though their inputs could have been already spent which would make all of those transactions invalid. |
|
|
|
|
Show Posts
