6

Eltoo relies on a primitive SIGHASH_ANYPREVOUT or SIGHASH_NOINPUT (hereafter referred as APO) BPI118, constructing Eltoo from APO would be replacing the CHECKSIG figure 4 of Eltoo paper with a modified script. Most of this answer is based on a blog post by Russell O'Connor from this link(which goes into other covenant constructions too). For completeness, ...


5

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 ...


4

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 ...


3

In theory, it isn't clear to me yet if finding a min-cost flow is any harder when there are minimum flows. In practice, it's not at all a problem as long as the min HTLC size is small. That's because we calculate the optimum flows with a global minimum flow size (resolution) anyway, and typical values for that are 10k-100ksat. At the moment, the maximum ...


3

Assume the lightning network wants to support 100k payments per second globally. Now every time a payment is attempted, aborted or settled the balance of almost every channel in the payment flow changes. Assuming 5 channels being involved in a payment (and assuming no failed payments as the balance values would magically instantly known to all peers) this ...


3

A bit is a binary digit with the two possible expressions 0 and 1. Binary data is often represented as hexadecimal in writing as that is more compact and human-readable. Hexadecimal (base 16) encodes the (decimal) numbers 0 through 15 with the symbols 0-9 and A-F (where A-F represent 10-15). A few examples (subscript indicates base): 110 = 116 = 00012 510 = ...


2

This was a bug in c-lightning. In some cases c-lightning was sending 0 update_fee on regtest. It has been fixed with this PR and this fix will (probably) be included in the v0.10.1 release.


2

If you have jq installed, you can ask it to sum up all the values for you. For example, to get the total amount stored in your node’s UTXOs: lightning-cli listfunds | jq '[.outputs[].value] | add' If you want your output in BTC rather than satoshis, you can divide it right away: lightning-cli listfunds | jq '[.outputs[].value] | add / 100000000'


2

Short answer: Such rule would not change anything people could split their funds across several nodes similar to LNBIG.


1

There is absolutely no ability in Bitcoin for higher resolution than 1 Satoshi, as all values are internally represented in this unit. You can do this on second layer systems like Lightning which can allow arbitrary small amounts of BTC to be interacted with using that network, but the precision within Bitcoin itself is unlikely to change, if for no other ...


1

yes it can! As part of the offers proposal Rusty is currently suggesting to add a standard for so called onion messages to BOLT 07. You can find more details in the open pull request: https://github.com/lightningnetwork/lightning-rfc/pull/798/files


1

You won't know what the other node proposes unless some one starts the process of closing the channel and then your node will see what they propose and start digging into the estimation. In general one can access the man-page with lightning-cli help feerates (or in your case with lcli help feerates) from there we find further information with respect to ...


1

I think as of now the protocol does not support updating those channel parameters as they would need to be renegotiated. I could not find any message in the Protocol that would support such a functionality What you could do is to close the channel and reopen it But I guess you would want to avoid it and technically I do not see reasons why such an updated ...


1

You are right that in the BOLT3 Scripts the revocation path pays only to a single public key, the revocationpubkey. In order to keep the same restriction with a single pubkey, the revocationpubkey is derived based on both a secret generated by the local node and one by the remote node. Without the part of the secret only known to the local node, the remote ...


Only top voted, non community-wiki answers of a minimum length are eligible