New record! 647.73 satoshi in fees collected from 60 transactions in February. A few days ago, I opened a dual-funded channel with @n0nce and it turned out to be the right call. We routed 41 transactions in a single day!  |
|
|
|
Hey Rath, thanks a lot for trying! It's really good to know that I'm apparently unreachable or at least not well reachable. I just opened a new channel with good inbound liquidity; maybe retry tomorrow or whenever that's locked in, if you wish.
Edit: @Rath_ got the new channel on-chain now!
I was able to send 1 satoshi through your offer, but 100 and 1000 satoshi payments still fail. Well... if you're interested, we can open a dual-funded channel  It seems that either my or your node is underconnected or lacks liquidity. |
|
|
|
lno1pgyhgetnwss8getnws2q2m3sde3k283q2lpjlt6ze9es9je8c5xdxzcry7yz5flpwcnq84lxx2pcvu5v36hlqsyt78v7gcwx7az9aanft87whfedvey8gvm68f9uygrypnwe5r4578el5tlxznasdp8rjql9ulavwyadpxnmaeh9v0l4xc5lvq3qqrurq Of course will also send anything right back; preferably using one of your offer codes posted in here (that's what they're made for; reusability & statically receiving sats without interaction from the 'receiver'  ). Your offer seems to be working fine as my node can fetch an invoice, but I can't find a route to you. I have already tried sending as little as 1 satoshi with no luck. |
|
|
|
They lack knowledge of revocationbase_priv, right? So how can they calculate it?
revocationbase_priv = revocation_basepoint_secret Commitment transactions are asymmetrical. Here's what happens when A wants to update. A constructs B's commitment transaction. Let's assume that it has only 2 outputs ("to_local" and "to_remote"). "to_local" output is delayed. "to_remote" output can be spent immediately. In B's commitment transaction, "to_local" can be spent by B after a delay and "to_remote" refunds A their coins. In this case, A uses their "revocation_basepoint" and B's "per_commitment_point" to calculate the revocation public key. A sends "commitment_signed", which includes the signatures for that transaction, to B. Once B verifies if the signature is valid, they can send "revoke_and_ack" which includes "per_commitment_secret" used to generate "per_commitment_point" for the previous commitment transaction, and "next_per_commitment_point" which A will need in the future to construct the next B's commitment transaction. type: 133 (revoke_and_ack)
data:
[channel_id:channel_id]
[32*byte:per_commitment_secret]
[point:next_per_commitment_point]
A is now able to generate revocation private key for B's previous commitment transaction as they know B's "per_commitment_secret". B repeats the same process for A's commitment transaction. They use B's "revocation_basepoint" and A's "per_commitment_point" for the revocation public key to lock the "to_local" output.If A broadcasts their previous commitment transaction, B can spend A's "to_local" output immediately using their revocation private key, which includes A's "per_commitment_secret" and B's "revocation_basepoint_secret".Note that A and B don't send (un)signed transactions between each other. They only need to exchange signatures as they can construct each other's commitment transaction at any time. The committer is safe as long as they don't publish that old signed transaction. What I don't understand is what will they reveal if they do broadcast it. According to my understanding, the other party needs to somehow work out the private key of revocation_pubkey, which is revocation_priv.
Nothing is really revealed at that moment. Both parties can reconstruct both commitment transaction at any time. However, they can't publish the other party's commitment as they don't have all signatures. Once the commitment transaction is broadcast, it can't be replaced*. Both parties have everything they need to broadcast a penalty transaction before the outdated commitment transaction is broadcast. * - it doesn't make sense to replace the current commitment transaction using RBF with some old one paying a higher fee as its "to_local" output can be spent immediately by one of the parties anyway. |
|
|
|
It will be false after Lightning Network better adoption and every exchange, merchant will accept it. So far there is not even a single exchange that do that. They are at a stage of implementing segwit right now. But still people in 2022 wants a $$ deal, not a sat deal. At least people i deal with. There's actually quite a few exchanges which already support the Lightning Network. Here's an up-to-date list. I have had channels to both Bitfinex and Nicehash for a couple of months now. I also tried their Lightning deposits/withdrawals and they worked flawlessly. |
|
|
|
Is there a way I can convert the BTC Pay Lightning invoice to regular Bitcoin, so I can just send the payment with fiddling around or giving my keys to someone else?
You can use third-party services like Boltz, Lightning Conductor, ZigZag for that. They can pay any Lightning invoice if you pay them via an on-chain transaction. All of these services charge a small fee and they are not instantaneous as your transaction needs to be confirmed first. |
|
|
|
I just realized that when I sent bitcoins to my electrum wallet, actually it was received on different reception addresses (on the same electrum wallet).
Could you confirm that with my seed phrase I will be able to recover ALL my bitcoins (and not some on specific reception addresses)
If the other address has been a part of your wallet since the beginning (meaning you didn't import it and it was generated automatically) then you will be to recover that address using your seed. |
|
|
|
Manager: yahoo62278Nazwa kampanii: Highpertoken Sig and Avatar campaignIle do zarobienia/tydzień / ilość postów: Full Member - 0.0004 BTC/tydzień, Sr Member - 0.0008 BTC/tydzień, Hero Member - 0.001 BTC/tydzień, Legendary - 0.0012 BTC/tydzień Jakie rangi: Full Member, Sr Member, Hero Member, Legendary Dodatkowe informacje: Minimum 20 postów tygodniowo. |
|
|
|
How do I contact electrum support to look into this?
If you are certainly sure that the destination address is exactly the same as the one generated by the website, you should contact their support instead. They might be experiencing some kind of technical problem or you might have sent the coins to a wrong address, which usually happens due to some clipboard malware. |
|
|
|
The reason why I ask this is because I want to install a new app on my nano ledger s... so want to know if I should install the latest ledger live update before this. Thus is it required?
You should be able to install the latest version of apps even with outdated Ledger Live. You just won't be able to use new features if any are introduced in an update. The latest update added native support for NFTs for the Ethereum network, so you can safely skip it if you are not interested in them. |
|
|
|
Manager: Little MouseNazwa kampanii: Thunderpick.com Signature CampaignIle do zarobienia/tydzień / ilość postów: Hero Member/Legendary - $90 w BTC/tydzień Jakie rangi: 10x Hero Member/Legendary Dodatkowe informacje: Minimum 20 postów tygodniowo, w tym minimum 10 w sekcjach Gambling. |
|
|
|
1. randomly with any extra data that can be false so that it confuses others
All messages are encrypted so it doesn't really matter what you put inside (still, the specs recommend using zeros). The overall size of the message is more important as standardised messages have a fixed size, so a third-party might try to guess what you are talking about with some other node. 2. with onion routing to have private updates, or (1) because just waiting for a official update can be "no new data for a significant portion of a connection's lifetime"
I have no idea where you got the "private updates" from. Your quote suggests that you can create synthetic traffic in combination with BOLT04. In other words, for example, you can send ping messages while routing a payment to pretend that the payment was split or forwarded to a different node. You just need to send a ping message with the same size as "update_add_htlc". 3. to do other things like changing keys
Encryption keys are changed every 500 uses. Ping/pong messages count as one use. As ping/pong messages are sent frequently, they are the cause of frequent key rotations. They are not used to exchange new keys. No extra data is sent here. yep you can put in lots of stuff into the extension part.. but you keep dismissing this. maybe you dont understand, or maybe your purposefully ignoring what happens with TLV in the extension
Let me explain my point again. Here's what you said before: but there are hundreds of messages.. heck even the simple ping/pong messages can include updates to the fee's cltv's and such.
Yes, technically you can fit this information in there. However, an optional TLV payload was not a part of the initial specs and the Lightning Network works well without depending on it. Here's how I replied to you: Even the ping/pong messages? Are you sure that we are looking at the same specifications? You might as well put a picture of your cat inside of your "ping" message, but the recipient won't know how to handle it correctly as it's non-standard.
None of the existing wallets or implementations expects information about fees, ctlv timelock or liquidity in the TLV payload. They would ignore it. Sure, you could modify your client to behave this way, but you would still have to comply with the specifications to be able to talk with other nodes without any problems. So, if the TLV payload is not used to exchange this information, what's your next idea? and if C is private. there wont be a BC or CD or CW on the DNS network bootstrap map..
instead of seeing a tree that links
ABCDE
ABCWXYZ
ZYXWCBA
ZYXWCDE
you would instead see
AB ZYXW
If we assume that all of the C's channels are private then you are almost correct (you forgot about DE). Although, "DNS network bootstrap map" is not really a suitable name for DNS bootstrapping used by new nodes and a local map of the network maintained by every node. Technically, any Lightning node can be listed in the DNS seeds. heres the funny part, there is no consensus in LN. so while you play games saying that the rules are strict and network compliant and everyone is forced,default public. where peopel cant just switch on and off their visibility. and where people cant negotiate payments away from YOUR version of pre organised payment setup from bootstrap data. BUT reality is there is no network wide audit, (well there wasnt and shouldnt.. though public loving person you are, you may want there to be. )
i guess you cant think of PR campaign to promote privacy, so you avoid wanting to discuss that its an option. and instead want to quote andreas saying things about how its default and forced to be public.
What's the point of discussing what the Lightning Network could look like if we can't come to agreement how pathfinding and payment routing works at the moment in existing implementations and wallets? Other people already have a hard time keeping up with our discussion, especially that we are constantly switching between private, public and disabled channels in examples. |
|
|
|
The following post is a continuation of the discussion which started here.
And that's how you learned that "Routing" type messages do not contain any routing instructions or liquidity information. bolt07 messages: announcement_signatures, channel_announcement, node_announcement, query_short_channel_ids/reply_short_channel_ids_end, channel_update, query_channel_range/reply_channel_range
Their types are: 259, 256, 257, 261, 258, 263, 264 respectively.
None of these messages include "onion_routing_packet", "hop_data" or any other routing instructions.
even simple messages like ping and pong can add payloads of different information, well outside of your "update_add_htlc" mantra where you think everything is done inside
Again, just because you can technically fit some data inside ping/pong messages, it doesn't mean that the other node expects it. In fact, you should not send any data using them: type: 18 (ping)
data:
[u16:num_pong_bytes]
[u16:byteslen]
[byteslen*byte:ignored]
A node sending a ping message:
SHOULD set ignored to 0s.
MUST NOT set ignored to sensitive data such as secrets or portions of initialized memory.
So, as per specifications, the data sent through ping/pong messages is just a bunch of zeros. 3. maybe the many ways many wallets do it, is not spec compliant to YOUR wallet. but your wallet after all is not interested in privacy, hense why you think your wallet is limited to only a dozen message types.
Feel free to name those privacy-oriented wallets which do not follow the specifications to improve the privacy of their users. EG W does not tell X about C because WC is private. so X cant tell y and Y cannot tell Z .
so you as Z will just see Z-Y-X-W but not -C..
As Z, you won't learn about the CW channel, but you can still learn about AB, BC, CD, DE from either W, who can learn about them from C, or from some outside node which had received a gossip message about any of those channels. W can safely forward gossip messages from C as those messages are exactly the same for every hop. |
|
|
|
if you speak to rath_ he will tell you his LN wallet does not have privacy, his wallet announces his channel balance changes to a central DNS/explorer/whole network so that everyone can see whats available to make routes.
Oh, wow. Slow down for a moment. I have never said that. You should take a look at at least one paper describing the probing attack on the Lightning Network. LN nodes gossip about channels available for routing and their total capacities. To issue a (multi-hop) payment, the sender creates a route based on its local knowledge of the graph. As local channel balances are not public, payments often fail due to insufficient balance at an intermediary hop. In that case, the payment is attempted along multiple routes until it succeeds. This constitutes a privacy-efficiency tradeoff: hidden balances improve privacy but hinder routing efficiency. As for the "central DNS", you are ignoring the fact that nodes use DNS bootstrapping ( just like Bitcoin nodes) to discover peers. Lightning nodes talk not only to their channel partners but also to other participants of the network. You fail to acknowledge that even though you can easily check it on your own by either setting up your own node or running a non-custodial wallet like Electrum. oh and rath_ thinks even if i set my C to be private, he can still see
A-B-C-D-E
\
W-X-Y-Z
all because HIS wallet defaults and forces his channels to be public so he does not understand that privacy was and is possible.
Yes, I could still see WX, XY and YZ channels as you assume that they are public. and instead can build routes without testing them. the flaw of this convenience of saving a few hundred bytes of data. is ofcourse lack of privacy, and also the reason he had a 70% fail rate for payments because he wasnt testing routes before trying to push payments
There is no other way to test if the payment will go through other than to actually send it. You fail to prove which "private message" in our opinion is actually supposed to do that. You will very likely come up with another non spec-complaint message. For example, we suspect which edges might be able to forward a payment because their capacity seems big enough. But we can’t be certain unless we try it out or ask the channel owners directly. Even if we were able to ask the channel owners directly, their balance might change by the time we have asked others, computed a path, constructed an onion and send it along |
|
|
|
Here are the stats for January. One of my largest channels, which I opened with some other bitcointalk user, was offline for at least half a month. Some of the routed payments were free of charge as I wanted to rebalance two of my channels this way.  |
|
|
|
So, to get the funds I sent again, just by forcing the channel to close? And for that I depend on the other node? Well, you already have some confirmations (specifically 9400 lmao)
A cooperative close involves one transaction. A force close involves two transactions - one of which is a commitment transaction. Your wallet should broadcast the second transaction automatically after a certain time (usually 144 blocks) since the commitment transaction has been confirmed. The force close should be initiated only if the other party is offline or unwilling to cooperate. I have no idea why you had to force close your channel twice. |
|
|
|
I only know that I opened an LN channel on Electrum, my balance disappeared, it appeared going away in my transactions list, and I didn't send my entire balance to anyone
That's how Lightning works. You send your coins to a multi-signature address controlled by you and the other node. Once the funding transaction reaches a couple of confirmations, you can spend those coins only over the Lightning Network. You can withdraw your balance to your on-chain address if you close the channel either cooperatively or uncooperatively (via a commitment transaction). Commitment transactions are signed by both parties when the state of the channel changes (fee update, incoming/outgoing Lightning transactions). They can enforce the current off-chain balance of the channel on-chain. |
|
|
|
Could I disable it and ask to close the channel?
Yes, you can disable it safely. Try closing the channel again. In the worst case scenario, you might see an error that the inputs have already been spent. Another thing: I paid a 13 cents USD tax, maybe it wouldn't be this low tax amount that justifies this whole delay?
No, it doesn't matter. Those two transactions look to me like funding transactions and not closing or commitment transactions. |
|
|
|
Reply to me with a new BOLT12 offer of a fixed amount of 1515 sats (forget the 10 sats).
I will disable it once you pay it. Here you go: lno1pqp3w80cpg09getdwphhyctj0ysx7enxv4ezqen0wgsxgctjddmrqun5xdupgrjjv96xsgzmddjhjum9dej9683qw0dq55jnjrpks4uyrcsg78fgjf6uwm4l5lk0me5hcm9lfu34kn6lqsqs6jevw9z0nhhr2pxvu6fpzaxvk0al52um3pp4j4c7shn5rhy6nueka0aug8h5lcudj0egp090mulku0kxes4998wtwfvsxf7ycgndw Why don't you reuse my previous offer, though? I made sure that anyone can request an invoice with any amount using it. |
|
|
|
|
Show Posts
