The first three scenarios are indeed possible, the last one is identical to the second.
This is called a collaborative close. It has the advantage of using a lower on-chain fee since the transactions are not time critical and the users get their coins back immediately (no dispute time).
If the other node is unresponsive (offline or doesn't sign a ...
Let's disect this function call:
void sha256(struct sha256 *sha, const void *p, size_t size)
First we realize that the return value is void which means the function does not return the sha256 of the data. However we see that the first argument struct sha256 *sha is a pointer to a sha256 struct with the name sha. This suggests that the pointer that we pass ...
With the current specification it is not possible to make a spontaneous payment to somebody on the network. However, this will likely change very soon, as it is one of the features on the roadmap and will be discussed in the specification group in November.
There are tricks on how to do a payment by delivering a large fee at the destination and continue ...
You basically answered the question already yourself. Besides the 1% channel reserve you as the funder are responsible for paying onchain fees in case you need to force close the channel by spending the commitment transaction.
C Lightning (and lightning nodes in general) are rather overestimating onchain fees as they cannot rely on the fact that the fees ...
I started out writing this answer while trying to do it myself, but then found out that we don't yet have tools to manually edit partially signed Bitcoin transactions (PSBTs) which is the very last step before we finalize the double-spend. So this answer is currently incomplete, but I'm planning on building out that tooling and write a plugin that automates ...
Plugins can be written in any language as long as a client library for that language exists.
The command line API and the Plugins communicate with lightningd over a unix domain socket using JSON RPC 2.0.
As far as I know no Java / Scala lib exists. I have started creating one at this pull request: https://github.com/ElementsProject/lightning/pull/2223
It is possible to run Lightning (both LND and c-lightning) with bitcoind pruned mode.
There are already packages turning the pruned mode on when disk space is limited: Lightning Power Node Launcher (works with LND) and BTCPayServer docker (works with c-lightnig).
There is a lot of conflicting information online, because it became possible only after ...
First of all welcome to the lightning network and keep asking excellent questions!
the important information is within the result of the listfunds command. For example here:
The channel_total_sat says that the capacity of your channel is 500k satoshi. Whereas the channel_sat says that you own 500k ...
As you mentioned your question is almost a duplicate of Why does my c-lightning node pay more than the invoice plus routing fees?
But you asked if there is a way of knowing how much you will overpay before you pay.
There are two ways :
You can configure lightningd with a maximum allowed fee for a payment. In that case your node won't use a route with ...
Technically you can double spend the output that was used for the funding TX with a higher fee. Then the channel will never be opened. Practically I don't think any of the lightning network implementations offer an api to do so.
c-lightning by itself does not expose it's RPC over the network. This is to avoid having to dictate what kind of authorization and authentication to use in order to provide access control.
There are however a couple of options that are easy to implement and will do what you want:
Implement a small proxy plugin that'll export the information you need over ...
One lightweight alternative that I use quite often when setting up a Lightning node is spruned. The following will get you up and running:
Install some dependencies:
apt-get install -y git python3 \
Natively c-lightning does not support paying invoices to yourself. But I have provided a trick described in this video: https://www.youtube.com/watch?v=Dwl-0cY6KkU&t=1s:
The trick is to create an invoice and then use getroute to find a route to some node and then go back (possible over another route with another getroute call). once you have such a ...
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 ...
Yes, there are basically two ways to avoid becoming a forwarding node:
Do not announce your channels, and keep them private
Reject any incoming HTLC that is not destined for you
The first is supported by the protocol itself, and is a proactive measure against forwarding any payment that is not destined for you, while the latter is a reactive measure and ...
listpeers returns data on nodes that you have connected with OR the nodes with which you have an open channel. If you have an open channel with a node, but the connection with that node has been lost, then the node will still appear in the output, with "connected": false. If you are connected with a node but do not have open channels, then it will ...
The hsm_secret is used to derive keys for both onchain and offchain (channels commitments) transactions.
To retrieve on chain funds you can rescan the block chain for your utxos by using the --rescan startup option of lightningd.
You can not re create the whole state of your channels just from the hsm_secret, which are stored in the ...
You can trigger a shell script with them, and more.
This is related to the plugin functionalities provided by lightningd and not bitcoind.
lightningd allows you to run plugins to deeply modify its behaviour, or extend its possibilities. It idiomatically (small and robust core, customizable functionalities) relies a lot on them and therefore directed the ...
There is nothing special about those two blocks, aside from containing a funding transaction that c-lightning would like to verify (causing it to look the block up) and it being pruned in your bitcoind.
Restarting indeed results in the lookup, which is kept in memory until it succeeds or fails, is forgotten giving you the temporary result of no longer ...
OK, the three figures you care about here are:
They have 1600000 - 1599884 millisatoshis, ie 116. But they need to keep at least 546 satoshis reserve, ie. 546,000. Until they do, we won't let them spend any.
Hence the warning when you created an invoice: there's ...
You are correct in that you cannot run a LND node with a pruned bitcoind server.
Pruning isn't compatible with transaction indexing because the index would point to transactions which have been pruned (no longer in store).
Each lightning node requires transaction indexing, because it will be looking for specific txid's on-chain throughout the lifetime of ...
The protocol is purposefully built in such a way that DoS attacks are mitigated and reduced in impact. Each channel_announcement contains a reference to the funding transaction, and each node verifies that this funding transaction matches the information in the announcement. This makes the creation of a channel_announcement non-free, and binds some resources ...
Use the RPC-Interface listfunds lightning-cli listfunds which lists all payment channels and UTXO.
If you wish to have a more nicely display you can use this small tool: https://github.com/renepickhardt/lightning-helpers
git clone https://github.com/renepickhardt/lightning-helpers.git
sudo make install
it aggregates ...
Whether you run a full node or a lightweight node is a first layer question. It is a question about how you keep track about what happens on the blockchain. And even though this is important for you, the Lightning nodes that are communicating with your Lightning node do actually not care about it and in fact they don't even (have to) know about your Bitcoin ...
When I set up a lightning channel with a node, have I need to put some bitcoins in it?
Generally, yes. The person who initiates the channel creation process (i.e. the person that says "I want to open a channel with you") is the one who funds the channel.
Then, if I wanted to buy something using lightning network (for example, a sticker from Blockstream), ...
After a lot of research I found the solution to my problem.
I didn't know this, but in nodejs there's a huge difference if your server runs on 127.0.0.1 and on 0.0.0.0.
It isn't said in the lightning-charge docs, but except the --port attribute you also have --host which you can set.
Starting lightning-charge with this line charged --api-token ...
The problem seems that the other nodes are also offline which is why you can't connect to them.
Luckily you don't have to be connected as you can do a force close by publishing your channel state to the Bitcoin network (the disadvantage is that you have to wait for the timelock until you can spend your outputs)
Just try lightning-cli close ENTER-CHANNEL-...
In order for list nodes to provide some output you need to first connect to at least one peer on the network. Because the peer is giving you all the information from the gossip protocol about announced nodes and announced channels.
So do lightning-cli connect firstname.lastname@example.org:9735 to peer with ...