Pretty much everything would stay the same. If you look at the relevant messages channel_announcement and channel_update we have the following formats:
type: 256 (channel_announcement)
After some searching through the BOLT documents and talking with the lnd slack community, I found an answer:
B->C. If B were to send 4,999,999 millisatoshi directly to C, it would
neither charge itself a fee nor add its own cltv_expiry_delta, so it
would use C's requested min_final_cltv_expiry of 9. Presumably it
would also add a shadow route to ...
The flags field (2 bytes) has been split into two different (1 byte) fields, the message_flags (most significant bits) and the channel_flags field (least significant bits). Hence the flags value displayed in lnd has the message_flags byte set to 0x00 and the message_flags set to 0x01.
message_flags indicates that this channel_update has some optional fields ...
First of all: it is in fact not possible at this time to sort a stuck payment. The htlcs are a contract in which you agree to fulfill a payment if the routing node provides a preimage within a time window (the timelock). Assume you would be allowed to remove an htlc before the timelock, not only would this be a breach to the contract but it could easily ...
The Current Problem
The major challenge in the current routing mechanism is finding channels with sufficient balance on one side of a node to forward an incoming payment. To be more descriptive, the channel_announcement or the channel_update messages that are broadcasted contains the short_channel_id through which lightning nodes can look up the transaction ...
Lightning invoices are signed by the node issuing the invoice in order to verify the signature we need to know the node id. Thus it is included in the invoice. Lightning nodes provide an API to decode invoices.
In c-lightning you can do (lnd below!)
lightning-cli decodepay ...
Stuff like this can usually be found in the lightning-rfc aka BOLT (basics of lightning technologies) which is the formal protocol specification.
Currently channel capacity can't succeed 1/6 of a Bitcoin. However for BOLT1.1 (the next version of the protocol) it was agreed that this limit should be dropped (if both nodes of a channel agree to do so). Single ...
BOLT#7 outlines in the rules for receiving channel_announcement messages, that any previously known channel with differing node_ids, should result in the blacklisting of all associated nodes for both the current message and the previously known channel.
if it has previously received a valid channel_announcement, for the same transaction, in the same block, ...
The 4000000 Weight Units limitation is the maximum Bitcoin block size limit (link to the BIP).
The 400000 Weight Units limitation is the limit for a transaction to be standard (hence relayed).
The penalty transaction is crucial to the security of Lightning Network channels, so you need a transaction which can be relayed, hence a transaction which size is ...
First of all I think there seems to be a small confusion about the notation. One does not spend a transaction but transaction outputs. In the case of offered htlcs the output is only one (of potentially many others) output.
Also I understand the timelock slightly different. If you publish the commitment transaction it can be mined and verified directly. It ...
Why is the description field limited to 639 bytes?
Every field in lightning invoice is of the form:
type (5 bits)
data_length (10 bits, big-endian)
data (data_length x 5 bits)
The data_length indicates the size of the data that is to be followed. Since data_length itself has a size of 10 bits, it can represent a number up to 1023 (210 -1). Thus the size ...
According to my understanding the receiving node will first check the signature of related the dsha256 of the entire message before verifying the timestamp and not check the remainder of the message if the signature is invalid. So if other fields apart from signature are changed, then the signature will not be valid (as the message has changed) and the node ...
The failure message must go along the same route it came, because any intermediate step does not know where the payment was originally sent from. Every hop only knows the previous and next hops in the sequence, and so the only option it has is to return the information to the previous hop on the route.
I think what you ask is not possible when we want to follow the protocol for the following reasoning: (sorry I am a bit weak on BOLT 07)
If you look at BOLT 07 and the channel announcement messages you will see that you have to sign off channels with the bitcoin_keys that belong to the node_ids of the funding pupkey.
If you change your node_id you would ...
There is an article series on medium by rusty Russell (one of the main authors of the BOLTs)
The first part can be found at https://medium.com/@rusty_lightning/the-bitcoin-lightning-spec-part-1-8-a7720fb1b4da and the succeeding parts are linked from there.
This article series is from late 2016 and also somewhat outdated.
I recently started to write a ...
Testing further this, I found an answer for it: with current settings for lnd, one cannot transfer an amount such that leaves one of the sides with less that 1% of the channel capacity. This is most likely to prevent that one side to try to commit to an old state, since the punishment would be low.
For example, in the above case, if the channel capacity is ...