acinq / eclair Goto Github PK

On Mac OS Sierra 10.12.6

My command is.

mvn test -Dtest=IntegrationSpec 

And the output is.

14:57:19.264 INFO   - Slf4jLogger started
14:57:19.335 INFO   - using tmp dir: 
/path/to/my/workdir/eclair/eclair-core/target/integration-47f6913d-c5fb-44e4-8a23-c3adcd8c25f9
/path/to/my/workdir/eclair/eclair-core/target/bitcoin-0.14.0/bin/bitcoind: /path/to/my/workdir/eclair/eclair-core/target/bitcoin-0.14.0/bin/bitcoind: cannot execute binary file
14:57:20.005 INFO   - waiting for bitcoind to initialize...
14:57:50.040 INFO   - Slf4jLogger started
14:57:50.045 INFO   - hello!
14:57:50.046 INFO   - version=null commit=null
14:57:50.057 INFO   - initializing secure random generator
14:57:50.290 INFO   - generating fake channels
14:57:50.308 INFO   - stopping bitcoind
[ERROR] Tests run: 17, Failures: 7, Errors: 10, Skipped: 0, Time elapsed: 31.719 s <<< FAILURE! - in fr.acinq.eclair.integration.IntegrationSpec
[ERROR] wait bitcoind ready(fr.acinq.eclair.integration.IntegrationSpec)  Time elapsed: 30.047 s  <<< FAILURE!
java.lang.AssertionError: assertion failed: timeout 30 seconds expired: 
        at fr.acinq.eclair.integration.IntegrationSpec.withFixture(IntegrationSpec.scala:40)
        at fr.acinq.eclair.integration.IntegrationSpec.runTest(IntegrationSpec.scala:40)
        at fr.acinq.eclair.integration.IntegrationSpec.runTests(IntegrationSpec.scala:40)
        at fr.acinq.eclair.integration.IntegrationSpec.org$scalatest$FunSuiteLike$$super$run(IntegrationSpec.scala:40)
        at fr.acinq.eclair.integration.IntegrationSpec.org$scalatest$BeforeAndAfterAll$$super$run(IntegrationSpec.scala:40)
        at fr.acinq.eclair.integration.IntegrationSpec.run(IntegrationSpec.scala:40)

I tried to run ./target/bitcoin-0.14.0/bin/bitcoind manually but it returns zsh: exec format error: ./target/bitcoin-0.14.0/bin/bitcoind

So I copied my system bitcoind (and bitcoin-* those are executable.) files in ./target/bitcoin-0.14.0/bin/bitcoind and run again but having same error.
I realized that by insepcting file command system bitcoind returns

/usr/local/bin/bitcoind: Mach-O 64-bit executable x86_64

but ./target/bitcoin-0.14.0/bin/bitcoind returns

./target/bitcoin-0.14.0/bin/bitcoind: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.24, BuildID[sha1]=eb18d2bc1d03862fb8144e2dab8914641fc3175c, stripped

So I looked into IntegrationSpec.scala but couldn't understand how it prepares bitcoind executable. May be the problem is that my system bitcoind is version 0.15.99 but I still don't understand why it cannot create executable when testing.

What should I do to handle version difference? Or someone at least explain me how does eclair make a bitcoind executable in target/ ?

thanks in advance.

I'm trying to connect Eclair to a btcd testnet instance, but I can't find the equivalent configuration for zeromq.

• In the Eclair README there is a minimal bitcoin.conf recommendation;

zmqpubrawblock=tcp://127.0.0.1:29000
zmqpubrawtx=tcp://127.0.0.1:29000

• And in the reference.conf of Eclair there is an entry like this;
  zmq = "tcp://127.0.0.1:29000"

It's my bad or currently Eclair is not compatible with Bitcoin Go implementation btcd?

When sending a Shutdown while bombarding Eclair with a lot of HTLCs it very often responds with CannotSignBeforeRevocation and uncooperative close.

This seems to be happening because of the shutdown logic code in Channel.scala which tries to send a commit sig regardless of whether a commitment point is available or not:

case Event(remoteShutdown@Shutdown(_, remoteScriptPubKey), d: DATA_NORMAL) =>
	if (!Closing.isValidFinalScriptPubkey(remoteScriptPubKey)) throw InvalidFinalScript(d.channelId)
	Try(d.localShutdown.map(s => (s, d.commitments)).getOrElse {
	// first if we have pending changes, we need to commit them
	val commitments2 = if (Commitments.localHasChanges(d.commitments)) {
	  val (commitments1, commit) = Commitments.sendCommit(d.commitments)
	  forwarder ! commit
	  commitments1
	} else d.commitments

When replaced with this (quick and dirty) code, the number of CannotSignBeforeRevocation is greatly reduced, although they still do happen sometimes (perhaps my wallet also contributes to that somehow).

case Event(remoteShutdown@Shutdown(_, remoteScriptPubKey), d: DATA_NORMAL) =>
	if (!Closing.isValidFinalScriptPubkey(remoteScriptPubKey)) throw InvalidFinalScript(d.channelId)
	Try(d.localShutdown.map(s => (s, d.commitments)).getOrElse {
	// first if we have pending changes, we need to commit them
	val commitments2 = if (Commitments.localHasChanges(d.commitments)) {

          val commitments1 = d.commitments.remoteNextCommitInfo match {
            case Right(_) =>
              Try(Commitments.sendCommit(d.commitments)) match {
                case Success((commitments3, sig)) =>
                  log.info(s"sending a new sig, spec:\n${Commitments.specs2String(commitments3)}")
                  forwarder ! sig
                  commitments3
                case Failure(cause) =>
                  throw CannotSignWithoutChanges(d.commitments.channelId)
              }
            case Left(waitForRevocation) =>
              log.info(s"already in the process of signing, will sign again as soon as possible")
              val commitments3 = d.commitments.copy(remoteNextCommitInfo = Left(waitForRevocation.copy(reSignAsap = true)))
              commitments3
          }

          commitments1
        } else d.commitments

Sending a payment to the same payment request, more than once fails? Is this intentional or a measure to prevent mistakes?

In case this is intentional due to that the request is uniquely tracking the preimage secret, would it be possible to create payment requests that are user friendly as a layer on top of it?

Some Monacoin geeks are trying to build Lightning Network using Eclair in few weeks.
Currently they are using patched version of ACINQ/bitcoin-lib.
And I think that should be refactored to use their monacoin-lib.
This will be useful for another alt-coins supports Lightining.

A sends an HTLC to B, after HTLC is cross-signed A disconnects and then B closes a channel uncooperatively while A is not connected, B also spends it's HtlcSuccessTx immediately.

A listens to blockchain events all this time and gets B's spent commit, reacts by broadcasting it's ClaimP2WPKHOutputTx and ClaimHtlcTimeoutTx for in-flight HTLC (even though it has 6 blocks of CLTV timeout), then gets B's HtlcSuccessTx and extracts a preimage.

The problem is remote spent commit tx does not get confirmations in A's wallet and as a consequence A's ClaimP2WPKHOutputTx and ClaimHtlcTimeoutTx don't get confirmations either. Moreover, once 6 blocks of CLTV timeout pass, restarting a wallet causes the following exception:

java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
Caused by: java.lang.reflect.InvocationTargetException
    at java.lang.reflect.Method.invoke(Native Method)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
    ... 1 more
Caused by: org.bitcoinj.wallet.UnreadableWalletException: Could not connect 1d10acc39ef37c9b217bc7ce14365a1201fbefc67417acb29465fe17d55b82d2 to 455d8e8a80156e3afc16c81cdbcbdfda70c2ab93da90eda58fb0f6cbf2943f29
    at org.bitcoinj.wallet.WalletProtobufSerializer.connectTransactionOutputs(WalletProtobufSerializer.java:756)
    at org.bitcoinj.wallet.WalletProtobufSerializer.readWallet(WalletProtobufSerializer.java:543)
    at org.bitcoinj.wallet.WalletProtobufSerializer.readWallet(WalletProtobufSerializer.java:470)
...

A combination of the following events seems to trigger such a behavior:

1. A sees remote commit spent, it is unconfirmed
2. A broadcasts ClaimHtlcTimeoutTx immediately
3. A gets B's HtlcSuccessTx (so there are now two txs which attempt to spend the same utxo present in a wallet: A's CLTV delayed ClaimHtlcTimeoutTx and B's HtlcSuccessTx)

None of this happens if remote commit gets at least 1 confirmation before A's ClaimHtlcTimeoutTx is broadcasted (I've delayed spending HtlcSuccessTx on B's side to achieve this), presumably because B's HtlcSuccessTx gets confirmed in a same block with commit tx so A's later attempt to spend a ClaimHtlcTimeoutTx gets rejected right away.

I have a Bitcoin node setup and an Eclair LN node but I cannot get another one to run. I know I need to change the ports in eclair.conf but I cannot seem to find that files. Inside the directory I am running the eclair node from only contains

• db file
• eclair.log
• seed.dat

Am I looking in the wrong place?

Edit: I am on OSX 10.10.5

If I'm not mistaken, does not picking a keyIndex the way it's done here: https://github.com/ACINQ/eclair/blob/master/eclair-node/src/main/scala/fr/acinq/eclair/io/Peer.scala#L276 may result in a duplicate value for different channels, especially for a busy node which would be opening a lot of channels, thus allowing peer to know sha preimages in advance and spend a favorable commit?

Would not it be safer to use a unix timestamp for example?

It appears that Eclair currently serializes the number of elements in the node_announcement.addr array, e.g., if we have asingle IPv4 address then the value will be 1. It should however be the number of bytes of the serialized addr array (see spec).

This is important because it allows us to append new fields to the end of the node_announcement message even if we add custom addresses. Having the length of the addr field allows us to skip that field should it contain unknown addresses and continue parsing after it.

How to reproduce:

1. Create a new channel between A and B

2. Send an A -> B HTLC and disconnect B, more precisely:

• A -> B: UpdateAddHtlc
• A -> B: CommitSig
• B disconnectes without receiving a CommitSig

3. On reconnect B expects commitments.remoteNextHtlcId == 0 but A's localNextHtlcId == 1 so the next A's outgoing HTLC will cause UnexpectedHtlcId from B

This seems to be happening because of a special if/else case in channel reestablishment code:

case Event(channelReestablish: ChannelReestablish, d: DATA_NORMAL) =>

      val commitments1 = if (channelReestablish.nextLocalCommitmentNumber == 1 && d.commitments.localCommit.index == 0) {
        // no new commitment was exchanged after NORMAL state was reached
        log.info(s"re-sending fundingLocked")
        val nextPerCommitmentPoint = Generators.perCommitPoint(d.commitments.localParams.shaSeed, 1)
        val fundingLocked = FundingLocked(d.commitments.channelId, nextPerCommitmentPoint)
        forwarder ! fundingLocked
        d.commitments
      } else {
        handleSync(channelReestablish, d)
      }

It does not take into account that node A may already have a first locally signed HTLC which needs handleSync to be executed on A's side anyway.

In some use cases like with container clusters, they don't need JavaFX frontend.
So I hope Eclair supports headless only also.

There is currently no way to retrieve known, non-local, channels through the RPC interface, while there is a way to enumerate the nodes in the network. It would be great if there was a simple way to list all channels.

That would allow me to check gossip integration in my integration tests and verify that we agree on known channels. My proposal is to either add a listing of endpointid-tuples to the network call, or a list of channelids that can be used to drill down with the channel RPC call.

I got the following error in the console while running eclair-node_2.11-0.2-alpha4-c85823f-capsule-fat.jar under Ubuntu 16.04:

UnsatisfiedLinkError: java.lang.UnsatisfiedLinkError: no secp256k1 in java.library.path

Logfile says:

2017-07-21 16:22:44,302 INFO akka.event.slf4j.Slf4jLogger - Slf4jLogger started
2017-07-21 16:22:44,318 INFO fr.acinq.eclair.Setup - hello!
2017-07-21 16:22:44,318 INFO fr.acinq.eclair.Setup - version=0.2-alpha4 commit=c85823f5b462c2e57070e16d384d8ecac995c4cf
2017-07-21 16:22:44,323 INFO fr.acinq.eclair.Setup - initializing secure random generator
2017-07-21 16:22:45,833 WARN akka.actor.ActorSystemImpl akka.actor.ActorSystemImpl(default) - Illegal response header: Illegal 'date' header: Invalid input 'P', expected IMF-fixdate, asctime-date or '0' (line 1, column 1): Pi, 21 júl 2017 14:22:45 GMT
^
2017-07-21 16:22:45,912 INFO fr.acinq.eclair.Setup - using chain=test chainHash=000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
2017-07-21 16:22:46,027 WARN akka.actor.ActorSystemImpl akka.actor.ActorSystemImpl(default) - Illegal response header: Illegal 'date' header: Invalid input 'P', expected IMF-fixdate, asctime-date or '0' (line 1, column 1): Pi, 21 júl 2017 14:22:46 GMT
^
2017-07-21 16:22:46,029 INFO fr.acinq.eclair.Setup - finaladdress=mfiwi3ixwRQrDyntBnx4h7JH7jeJaVrmhW
2017-07-21 16:22:46,362 INFO fr.acinq.eclair.Setup - nodeid=031d34ff8985eea856262506976e9d5c069de06dd901f8d97157787c202d490171 alias=eclair
2017-07-21 16:22:46,370 INFO fr.acinq.eclair.Setup - initial feeratePerKw=10000
2017-07-21 16:22:46,402 INFO fr.acinq.eclair.router.Router akka://default/user/$f/router - current status channels=0 nodes=0 updates=0
2017-07-21 16:22:46,404 INFO fr.acinq.eclair.io.Server akka://default/user/$i/server - bound on /0:0:0:0:0:0:0:0:9735
2017-07-21 16:22:47,427 INFO f.a.eclair.blockchain.zmq.ZMQActor akka://default/user/$a/zmq - connected to tcp://127.0.0.1:29000

No gui is visible at all.

eclair improperly includes HTLCs (sent or received) that have been failed with an update_fail_malformed message in its commit signature.

see cdecker/lightning-integration#2

I might be missing some tiny detail once again but it seems there's a bug here: https://github.com/ACINQ/eclair/blob/master/eclair-core/src/main/scala/fr/acinq/eclair/channel/Commitments.scala#L493

Instead of localParams.dustLimitSatoshis a remoteParams.dustLimitSatoshis should be used since otherwise there might be disparity in number of sent/received timeout and success transactions.

Sending outgoing HTLC was resulting in "htlc sig count mismatch" error here: https://github.com/ACINQ/eclair/blob/master/eclair-core/src/main/scala/fr/acinq/eclair/channel/Commitments.scala#L401 when my client had dustLimitSatoshis = 100000 while Eclair had it set to 542. Changing localParams to remoteParams fixed an issue.

Eclair currently uses DefaultDirectedGraph which has a restriction of single edge between two vertexes so on a topology like this:

       ->
A -> B -> C
       ->

there are three possible routes but DefaultDirectedGraph will only find one. Changing DefaultDirectedGraph to DirectedMultigraph results in all possible routes being found.

A service I'm working on needs to be able to query Eclair if certain payment request has been fulfilled or not (some basic related work can be seen here: https://github.com/btcontract/eclair/commit/42fb4dd2b7a9fde6c1a12498eccd53fe9dc4c19a), eventually this will have to be stored in a db for better reliability.

I could go on and add a database of my choice but before doing that I'd like to ask if there are any plans to use some particular kind of database? If there are I'd use it for consistency sake.

I set up Eclair on my phone, did a test transaction, and that works well so far. I then created a second channel, and made a second transaction.

What I noticed was that at no point was I asked which of the two active channels do I want to use. It just automatically assumed I want to use the last one.

Could the payment screen get a new field asking which channel do I want to use, if multiple are available?

On the and note, I think channel labels could come in handy as well

I'm really excited to test LN with Eclair, I've already setup channel between eclair wallet and eclair node. But when trying to create an request for payment via JSON RPC because i'm doing this everything via terminal; i'm getting "Method not found" as return.

I'm using the following commands:
curl --data-binary '{"jsonrpc":"2.0", "id": "0", "method": "receive", "params": ["5000"]}'
-H 'content-type:application/json'
http://localhost:8081

I tried ["5000"], [{"5000"}], [{"amountMsat","5000"}], and so on. Still getting the same "method not found" message.

Hope the issue is clear and thank you for your time already.

Can you please provide an instruction on how to build a jar?

Think I've discovered a bug in channel reestablish as of eclair-node-javafx_2.11-0.2-alpha4-c85823f-capsule-fat but the reestablish code has changed substantially since then so I'd like to build a current master jar capsule to launch multiple instances and do some proper tests.

$ cd ecliar-master
$ mvn package capsule:build

results in

[ERROR] Failed to execute goal on project eclair-node-gui_2.11: Could not resolve dependencies for project fr.acinq.eclair:eclair-node-gui_2.11:jar:0.2-SNAPSHOT: Could not find artifact fr.acinq.eclair:eclair-node_2.11:jar:0.2-SNAPSHOT in sonatype snapshots (https://oss.sonatype.org/content/repositories/snapshots/) -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException

Currently a channel only subscribes to CurrentBlockCount once on receiving a FundingLocked message in WAIT_FOR_FUNDING_LOCKED state.

It does not re-enter this state after application restart and does not get CurrentBlockCount ever again which prevents node from closing a channel unilaterally if there are outdated outgoing HTLCs.

Channel opened from Android wallet to desktop eclair goes to closed status shortly after creation attempt.

eclair.log.txt

Node A has localFeatures = 00, node B has localFeatures = 08.
Restarting B makes it send full current routing state to A after re-connection.
In turn, restarting A has no such effect (B does not send a full current routing state after re-connection).

I've opened up lightning and connected it to my core. My friend also did the same but with his encrypted wallet. I try to open a channel to him and it's just stuck forever. I can't even close the connection anymore.

Looks like seconds value of ExpiryTag is calculated wrong? Or do I miss something?

test("expiry") {
    val pr = PaymentRequest(Block.RegtestGenesisBlock.hash, Some(MilliSatoshi(100000L)), BinaryData("0001020304050607080900010203040506070809000102030405060708090102"),
      priv, "test", fallbackAddress = None, expirySeconds = Some(21600), timestamp = System.currentTimeMillis() / 1000L)

    val serialzied = PaymentRequest write pr
    val pr1 = PaymentRequest read serialzied
    val expiry = pr1.tags.collectFirst { case exprity: PaymentRequest.ExpiryTag => exprity.seconds }.get
    assert(expiry == 21600) // org.scalatest.exceptions.TestFailedException: 96 did not equal 21600
  }

I'm not sure if this is an issue on Eclair's end or on the other end, but I thought I'd bring it up here. It seems like this issue has been discussed here: cdecker/lightning-integration#3

An HTLC may have a borderline amount which will be sufficient for HtlcTimeoutTx/HtlcSuccessTx to be part of a local commit but respected ClaimHtlcTimeoutTx/ClaimHtlcSuccessTx amounts will be so small that applying fees to them would render their output values negative or below dust levels.

This will result in a dangling utxo which is created by 1st tier tx but is unable to be spent by a 2nd tier tx in a case of uncooperative local commit spend.

Perhaps this can be improved using two additional checks:

1. When creating a ClaimHtlcTimeoutTx/ClaimHtlcSuccessTx, if tx output.value - fee < dust, then fee might be set to something like output.value / 2?

2. In claimCurrentLocalCommitTxOutputs, if 2nd tier tx output.value <= dust, then spend neighter that 2nd tier nor related 1st tier tx. HTLC output will thus be unused and blockchain won't be burdened with a useless tx.

I try the regtest it work.
In testnet my friend is another computer. I in my computer.
We both have testnet3. Can we send to each other? Or is eclair send only locally to computer?
Also is bitfury lightning routing algorithm in eclair?

$ uname -a
Linux ubuntu 4.4.0-36-generic #55-Ubuntu SMP Thu Aug 11 18:01:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

$ jre1.8.0_121/bin/java -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

eclair.log.gz

Java version:

openjdk version "9-Ubuntu"
OpenJDK Runtime Environment (build 9-Ubuntu+0-9b134-2ubuntu1)
OpenJDK 64-Bit Server VM (build 9-Ubuntu+0-9b134-2ubuntu1, mixed mode)

Output:

>java -jar eclair-node_2.11-0.2-alpha1-05607a0-capsule-fat.jar 
CAPSULE EXCEPTION: class Capsule (in unnamed module @0x32cf48b7) cannot access class com.sun.jmx.mbeanserver.JmxMBeanServer (in module java.management) because module java.management does not export com.sun.jmx.mbeanserver to unnamed module @0x32cf48b7 (for stack trace, run with -Dcapsule.log=verbose)

Currently Eclair won't accept a payment with used preimage (since related hash is deleted from PaymentHandler which results in UnknownPaymentHash on a second try) but it's possible to send the same payment twice by using the same payment request for example.

Isn't this problematic? For example, in a payment between nodes A -> B -> C, B may remember a preimage on a first pass and then immediately fulfill a second identical payment without propagating it further.

Mempool transactions should be detectable right?

According to the specification, max_htlc_value_in_flight_msat is an unsigned 8 byte integer. While testing against c-Lightning, which sets that value to 0xFFFFFFFFFFFFFFFF, eclair parses this as -1, i.e., as a signed int64. This currently kills the opening of a channel unless the other end is manually set to a lower limit.

Eclair Wallet, version 0.1.4.

I sent some coins to the P2SH wallet it showed, and sent the change to the same hash but formatted as P2PKH (totally not a bug in my own code. totally...). This got the wallet confused - it counted both outputs as being sent to it, however the second one is unspendable. TXID in question: 72f7106927e1d38cbdc8ffd7e9c2b3ef4a28fb4672eafad0dddf6ac5cd0965d7

The bad part is that now it can't send anything anywhere or open a channel - apparently all transactions being sent out by the wallet try to use the malformed output, and the "open in explorer": returns a "transaction not found" error.

While this is a rather unnatural thing to happen in regular use, it does present a critical attack vector where someone can disable your wallet by a malformed transaction, and with no way to recover your private keys (at least for now only, i hope) this means you are locked out of your funds.

Currently, when doing checks in sendAdd on HTLC sender side and receiveAdd on receiver side, a number of respected commitments1.remoteCommit.spec.htlcs.size and commitments1.localCommit.spec.htlcs.size sometimes differ, is this an expected behavior?

This happens when nodes A and B constantly send a lot of HTLCs to each other.

In lnwallet/Eclair case this often becomes severe and leads to channel close when lnwallet arrives at negative val missing = reduced.toRemoteMsat / 1000 - commitments1.localParams.channelReserveSatoshis - fees while Ecliair thinks it's still positive.

In Eclair/Eclair case HTLC number disparities also appear sometimes which yields different missing values. But a channel close did not yet happen because so far a missing value on sender side has been strictly equal or lower than on receiver side.

Trying to execute eclair-node_2.11-0.2-SNAPSHOT-6d7717c-capsule-fat.jar throws an error in Ubuntu 16.10 - KDE Plasma after "mvn package -DskipTests" build OK even in Travis-ci;

java -jar eclair-node_2.11-0.2-SNAPSHOT-6d7717c-capsule-fat.jar
cassini 2016-11-13 00:31:08,358 INFO fr.acinq.eclair.Setup - hello!
cassini 2016-11-13 00:31:18,225 INFO fr.acinq.eclair.Setup - nodeid=03befb4f8ad1d87d4c41acbb316791fe157f305caf2123c848f448975aaf85c1bb
cassini 2016-11-13 00:31:20,856 INFO akka.event.slf4j.Slf4jLogger - Slf4jLogger started
cassini 2016-11-13 00:31:23,640 ERROR fr.acinq.eclair.gui.FxApp - Something wrong happened: akka.http.scaladsl.unmarshalling.Unmarshaller$UnsupportedContentTypeException: Unsupported Content-Type, supported: application/json
at akka.http.scaladsl.unmarshalling.Unmarshaller$UnsupportedContentTypeException$.apply(Unmarshaller.scala:155)
at akka.http.scaladsl.unmarshalling.Unmarshaller$EnhancedFromEntityUnmarshaller$$anonfun$forContentTypes$extension$1$$anonfun$apply$22$$anonfun$apply$23.apply(Unmarshaller.scala:111)
at akka.http.scaladsl.unmarshalling.Unmarshaller$EnhancedFromEntityUnmarshaller$$anonfun$forContentTypes$extension$1$$anonfun$apply$22$$anonfun$apply$23.apply(Unmarshaller.scala:108)
at akka.http.scaladsl.unmarshalling.Unmarshaller$$anon$1.apply(Unmarshaller.scala:55)
at akka.http.scaladsl.unmarshalling.Unmarshaller$EnhancedUnmarshaller$$anonfun$mapWithInput$extension$1$$anonfun$apply$16$$anonfun$apply$17.apply(Unmarshaller.scala:88)
at akka.http.scaladsl.unmarshalling.Unmarshaller$EnhancedUnmarshaller$$anonfun$mapWithInput$extension$1$$anonfun$apply$16$$anonfun$apply$17.apply(Unmarshaller.scala:88)
at akka.http.scaladsl.unmarshalling.Unmarshaller$$anon$1.apply(Unmarshaller.scala:55)
at akka.http.scaladsl.unmarshalling.Unmarshaller$$anonfun$transform$1$$anonfun$apply$2$$anonfun$apply$3.apply(Unmarshaller.scala:23)
at akka.http.scaladsl.unmarshalling.Unmarshaller$$anonfun$transform$1$$anonfun$apply$2$$anonfun$apply$3.apply(Unmarshaller.scala:23)
at akka.http.scaladsl.unmarshalling.Unmarshaller$$anon$1.apply(Unmarshaller.scala:55)
at akka.http.scaladsl.unmarshalling.Unmarshaller$$anonfun$transform$1$$anonfun$apply$2$$anonfun$apply$3.apply(Unmarshaller.scala:23)
at akka.http.scaladsl.unmarshalling.Unmarshaller$$anonfun$transform$1$$anonfun$apply$2$$anonfun$apply$3.apply(Unmarshaller.scala:23)

Normally a funder can find out once fundee closes a channel unilaterally because a spending tx(s) would appear on the blockchain.

However, when fundee closes a channel in WAIT_FOR_FUNDING_CONFIRMED state there are no transactions to publish yet and currently no messages are sent to funder either so funder has no way to know a channel has been cancelled.

BOLT 2 does specify that a funder should cancel such a channel eventually after a "reasonable timeout" but this does not work very well in a context of end-user application I'm working on because as far as I understand "reasonable timeout" implies a couple of extra blocks which can take a lot of time.

Is it possible for a fundee to send some kind of Error mesage in such a case so funder could close a channel right away?

If you try to send money from the testnet Eclair wallet to a mainnet, it would happily accept it and generate a transaction using the hash of that address, essentially sending coins to the testnet equivalent of the mainnet address.

This have caused some confusion on at least one occasion: https://www.reddit.com/r/Bitcoin/comments/6pnbwc/im_using_the_lighning_network_enabled_eclair/dkqni2z/

In general, it's a good idea to check for such things - many people won't be able to recognize what happened and how to fix it.

Rather than going to an api call that just spits out json

Currently Eclair would immediately initiate an uncooperative channel closing once an HTLC with already too small expiry is received. As far as I see, spec says nothing decisive about this (sorry if it's there but I've overlooked it!). Maybe this is too strong a reaction? A receiving node seems to risk nothing if it will accept such an HTLC and then fail it like it currently does for HTLCs with >2x requested amount for example.

Rationale is I think any client may fall behind the best blockchain height (due to network conditions for example) without knowing it and may send an HTLC while in that state.

As far as I understand there should be a possibility to specify a custom amount to be paid which does not necessarily equals the one specified in payment request (can be up to 2x higher according to spec).

Currently there's no way to do that in Eclair. And also payment requests without amount can't be processed at all.

i can't seem to generate receive payment. At every value I put into it it's either "the payment request can not be generated" or once I hit too big of a number it says my amount has to be below x amount of msat.

I've tried it on all 3 settings mili, satoshi, milisatoshi.

I've connected my 3 local instances to each other. I think I'm running the most current eclair code.

last commit was d2d3b58fe77da5b8242e646ad5c1fa4eea47a0c0, aug 17th

When pasting in a payment request that starts with "lighting://" (eg a request from lightning labs' lightning app ), using "Paste a payment ...", it fails to read it correctly. If I remove the prefix, it reads it correctly.

It's currently possible to create a channel with capacity large enough to make a first commit tx but too small to make a valid closing tx.

An example is balance of 8000 SAT with feeRatePerKw = 10000 for which Eclair produced a first remote commit tx with a 760 SAT output and later a mutual closing tx which has no outputs.

One negative effect of this is a channel with such a balance stays in CLOSING state forever. This happens in both cooperative and uncooperative close cases.

When testing receiving some transactions with eclair javafx GUI, noticed a couple of display bugs in the "Received" section of the "Activity" tab.

1. For every new transaction received, the date for all prior transactions is updated to the date of the last transaction received.

2. Upon receiving my 4th transaction, all the transactions values were duplicated into new rows in the table.

State with 3 transactions recieved:

State after 4th transaction:

Here's an actual channel amount:

val canReceiveAmount = d.commitments.localCommit.spec.toRemoteMsat
val canSendAmount = d.commitments.localCommit.spec.toLocalMsat
println(s"canReceiveAmount: $canReceiveAmount, canSendAmount: $canSendAmount")
// output: canReceiveAmount: 5611755950, canSendAmount: 4388244050

Last 50 msat are lost in UI:

This happens because UI uses millisatoshi2millibtc method which converts msat to sat and thus -milli part is always lost.

This happens in both eclair-node-javafx_2.11-0.2-alpha4-c85823f-capsule-fat and current master.

I've made some changes to the code:
In Forwarder.scala:

case msg: LightningMessage => destination forward msg
case 'kill => destination ! PoisonPill // to be able to kill it from channel and simulate a disconnect

In Channel.scala:

case Event(commit: CommitSig, d: DATA_NORMAL) =>
      Try(Commitments.receiveCommit(d.commitments, commit)) match {
        case Success((commitments1, revocation)) =>
          log.debug(s"received a new sig, spec:\n${Commitments.specs2String(commitments1)}")
          if (Commitments.localHasChanges(commitments1)) {
            // if we have newly acknowledged changes let's sign them
            self ! CMD_SIGN
          }
          context.system.eventStream.publish(ChannelSignatureReceived(self, commitments1))
          val x = stay using store(d.copy(commitments = commitments1)) sending revocation
          forwarder ! 'kill // sending a revocation and disconnecting
          x

        case Failure(cause) => handleLocalError(cause, d)
      }

Setup is as follows:

Channel A -> B: 10,000,000 / 0 SAT
Channel B -> C: 10,000,000 / 0 SAT

A -> B: UpdateAddHtlc (route A -> B -> C) 1,000,000 SAT
A -> B: CommitSig
B -> A: RevokeAndAck
B -> A: CommitSig
A -> B: RevokeAndAck
A -> B: disconnect
A -> B: automatic reconnect in a few seconds

Channel A -> B as seen in node A now has A = 8,999,444 / B = 1,000,556 SAT
Channel A -> B as seen in node B now has A = 10,000,000 / B = 0 SAT
Channel B -> C now has B = 9,000,000 / C = 1,000,000 SAT

After restarting A, it always has an unresolved in-flight HTLC in it's local commitments which also prevents cooperative closing: A -> B state becomes SHUTDOWN without further progress.

After restarting B it fails an in-flight HTLC so

Channel A -> B as seen in node A now has A = 10,000,000 / B = 0 SAT
Channel A -> B as seen in node B now has A = 10,000,000 / B = 0 SAT
Channel B -> C as seen in node B now has B = 9,000,000 / C = 1,000,000 SAT
Channel B -> C as seen in node C now has B = 9,000,000 / C = 1,000,000 SAT

so it looks like payment has been routed but node B did not withdraw anything from it's A -> B channel

I noticed the Eclair-CLI is outdated, for example the node doesnt accept POST header anymore and requires only application/json content-type.

The methods should be adjusted too.

https://github.com/ACINQ/eclair/blob/master/eclair-core/eclair-cli

There seems to be no good way of retrieving node information such as the node's ID and listening port. It would be nice if there was an info method that'd return those values, similar to the getinfo method in c-lightning and the GetInfo method in lnd.