Lightning node with two channels to peer not able to select funded channel

Description

I have two peers: p1 and p2 running lightning-core

p1 opened a channel to p2 and p2 opened another channel to p1.

Now p2 has two channels. One with outbound funding and one with 0. Output of listfunds:

"channels": [      
      {
         "peer_id": "02e7b2196a87513ef322fc2c23d5739ed4ac696a9010a855dbfe7185fe8e133c93",
         "connected": true,
         "state": "CHANNELD_NORMAL",
         "short_channel_id": "2410508x70x0",
         "channel_sat": 0,
         "our_amount_msat": "0msat",
         "channel_total_sat": 113495,
         "amount_msat": "113495000msat",
         "funding_txid": "1f5284dbfcaf76e8a333c1c607465a9474294f43cfbcbbb34504d97aac2189a4",
         "funding_output": 0
      },
      {
         "peer_id": "02e7b2196a87513ef322fc2c23d5739ed4ac696a9010a855dbfe7185fe8e133c93",
         "connected": true,
         "state": "CHANNELD_NORMAL",
         "short_channel_id": "2410509x222x0",
         "channel_sat": 90433,
         "our_amount_msat": "90433000msat",
         "channel_total_sat": 90433,
         "amount_msat": "90433000msat",
         "funding_txid": "befde7cbd4965f21fe9df3a1f06eb1968109a7246457aabed58bfe39f6694b08",
         "funding_output": 0
      }
   ]

Problem

Now I tried to pay a 1000msat p1 invoice from p2 and get the error:

failed: WIRE_TEMPORARY_CHANNEL_FAILURE (WIRE_TEMPORARY_CHANNEL_FAILURE: Capacity exceeded – HTLC fee: 183sat)

I think this is because p2 tries to send using the not funded channel 2410508x70x0. Because if I delete this channel, all works as expected.

Questions

  • Why does p2 does not auto select the funded channel?
  • Is there a way to select the channel? I did not find an option for pay.

Descriptors of potentially fraudulent bitcoin transactions

I’m looking into suspicious bitcoin transactional patterns and I was wondering whether there is someone with experience in that area.

If we consider transactions as iid data, then what descriptors (aka variables, statistics) would we investigate to infer not fraud – as fraud is a judicial decision – but suspicion?

Without KYC (Know-Your-Customer), it’s a tough problem to tackle. KYC provides context according to which a transaction may be totally acceptable. However, without context, the same transaction may be perceived as suspicious, which further means that the inference system relies on guesswork.

does connecting to full node via rpc over the public internet reveal your credentials?

While trying to connect to my full node, I accidentally entered my public ip address in the rpcconnect field of bitcoin.conf. Should I be worried that my password is now out there and anyone can connect to my node via rpc? As a side note, the connection would not be successfull because I specify rpcallowip to only connect with local addresses.

rpcuser=user
rpcpassword=password
rpcconnect=public_ip

Really strange issue when trying to connect Sparrow Wallet to Bitcoin Core

I am really loosing my mind on this. I am actually not a technical noob but also not the very best technican. But things like this should actually be very easy for me.
What I want to do: I just want to connect my freshly set up Sparrow Wallet to my freshly set up Bitcoin Core.

First of all, my setup:

  • Bitcoin Core 23.0 on Windows 10, 64Bit (PC, local network)
  • Sparrow Wallet 1.7.1 on Linux (Laptop, same local network)

I’ve set up Bitcoin Core on my Windows PC as usual and blocks are up to date.
These lines were added to the "bitcoin.conf"-file on my Bitcoin Core Windows node:

rpcuser=user
rpcpassword=password

[main]
rpcbind=127.0.0.1
rpcbind=192.168.178.111
rpcallowip=127.0.0.1
rpcallowip=192.168.178.199/24

Where:

  • "rpcbind" – is the local IP address of the Bitcoin Core node on Windows 10
  • "rpcallowip" – is the local IP address of the laptop where Sparrow Wallet is running on
    The subnet mask is "255.255.255.0" so "/24" should be fine.

I’ve set up a few things like firewall rules and so on. I’ve pressed on "Test connection" hundreds of times and it did not work at all. Somehow, it suddenly worked and I got successfully connected to Bitcoin Core! I was really happy, BUT: After closing the wallet and opening again, it again won’t connect at all.
Again, I am getting the following error message:

Could not connect:
Check if Bitcoin Core is running, and the authentication details are correct.
See https://sparrowwallet.com/docs/connect-node.html

I noticed something really strange as well:
When I click "Test connection" on the laptop in Sparrow Wallet, even when Sparrow Wallet shows the above error, the Bitcoin Core screen changes from "You have no wallet loaded" to a wallet that is named "sparrow" (in Bitcoin Core!) and shows "0.00000000 BTC" (I did not set up any wallet on Sparrow Wallet yet!).

I tried to do some research on this issue but it looks like I am alone with this and feel kinda stupid since I don’t get what I am doing wrong ..
I also tried disabling the Windows firewall before connecting Sparrow Wallet to it without any success.

Then I’ve randomly found this issue on Github.

I’ve tried the following workaround stated on the Github issue page:

  • Shutting down Bitcoin Core on Windows
  • Shutting down Sparrow Wallet on Linux
  • Deleting a folder called "sparrow" in the Bitcoin Core directory
  • Starting up Bitcoin Core again
  • Starting up Sparrow Wallet again
    And TADA: It works! It says "Connected to "192.168.178.111:8332". But only one time! When I close Bitcoin Core or Sparrow Wallet again, it won’t connect afterwards. It gives me the above mentioned error again. BUT: When I follow the workaround that I’ve stated above again, it works again (until I close Bitcoin Core or Sparrow Wallet and open it again). So it only works for a while when I delete the "sparrow" folder in the Bitcoin Core directory.
    But only until none of both applications get closed. If I do so, I have to re-apply the stated workaround.

Other strange things I’ve noticed:

  • When I do the workaround and are able to connect Sparrow Wallet to Bitcoin Core, it does NOT show any inbound connection (but Sparrow Wallet says "Connected to..")
  • When I add "disablewallet=1" to bitcoin.conf, it does NOT even work with the mentioned workaround (even if it should as far as my understanding is correct)
  • When entering wrong authentication credentials on purpose, it takes some time until I get the error message "Could not connect" – when I enter them correctly, it shows this error message INSTANTLY! I got the feeling that it actually CAN connect (since the time until the error message shows up is less than a second, compared to when I enter credentials wrong which takes 10-15 seconds until the error message shows up)

Can anyone tell me what the actual heck is happening here? That’s one of the strangest thing I’ve ever seen in my 20 year computer carreer. Sure I could just to this workaround every time but I feel kinda uncomfortable to connect/create any wallet with this strange issue being present.

I should mention that a VPN software is running on both machines. Anyways, it works when applying the workaround even with VPNs on (I’ve enabled the "Local Connections" options within both VPN GUIs). But it also does not work without following the workaround when both VPN softwares are completely closed and shut down. So the VPN can’t be the cause of this issue I think.

I really appreciate any kind of help!
Is there any possibility that this is a serious issue by Sparrow Wallet and not my fault at all?

Thanks for any help in advance!

Is it possible to check latency of already approved transactions?

I am running a BTC core node and I would like to perform some experiments and analysis on Bitcoin transaction latency. However, I see that the method getrwatransaction returns an object with:

"blocktime" : xxx, (numeric) The block time expressed in UNIX epoch time

"time" : n, (numeric) Same as "blocktime"

As I would like to get information on transaction latency, in a way that I can subtract the first appearance of such transaction in the mempool with the block creation epoch, those two parameters should not be the same, otherwise I only see it as a redundant and useless information.

Is there a way to get such piece of information? I see that mempool does not store (obviously) all the record of received transactions, so I was wondering whether such information is stored in the transaction itself, or if it is possible to get it somehow.

Parsing blk.dat file fails, is this block legitimate?

I’m parsing in blocks from my local blk*.dat files, using this excellent website as a guide.

All goes well until file blk00976.dat, block 000000000000000000daf7a26d903543377d5cdddb962077e58fd11212479eea

In my copy of the file, when the parser reaches byte 27871335, it is about to iterate through a set of 64 transaction outputs.

When it reaches the 48th of these, it gets the value c4f1c2b3b69c42c5 and then reads a VarInt of fe80ffffff. This is the number of bytes to read for the next scriptPubKey.

The integer value of the VarInt is 2164260863 bytes (larger than the blk.dat file of 133768162 bytes).

Note the transaction begins with ffffffff58. Implying a version of ffffffff.

A hexdump of the block in question can be found here: https://blockchain.info/rawblock/000000000000000000daf7a26d903543377d5cdddb962077e58fd11212479eea?format=hex (Find "fe80ffffff" to see where I am looking)

A. Is this transaction and/or the block legitimate?

B. If not, why is it in my blk.dat archive?

C. What does a transaction version of ffffffff imply?

D. Is the scriptPubKey size VarInt fe80ffffff correct?

E. What is the story behind this block?

Difference between 2 way of serialization in the Bitcoin Core

This answer, explains what are SERIALIZE_METHODS and DESERIALIZE_METHODS macros in the Bitcoin Core. They prevent duplicate code for implementing the serialization and deserialization logic. But I’ve seen some classes in the Bitcoin Core which do the serialization differently. Here’s an example:

/**
 * A UTXO entry.
 *
 * Serialized format:
 * - VARINT((coinbase ? 1 : 0) | (height << 1))
 * - the non-spent CTxOut (via TxOutCompression)
 */
class Coin
{

    ...

    template<typename Stream>
    void Serialize(Stream &s) const {
        assert(!IsSpent());
        uint32_t code = nHeight * uint32_t{2} + fCoinBase;
        ::Serialize(s, VARINT(code));
        ::Serialize(s, Using<TxOutCompression>(out));
    }

    template<typename Stream>
    void Unserialize(Stream &s) {
        uint32_t code = 0;
        ::Unserialize(s, VARINT(code));
        nHeight = code >> 1;
        fCoinBase = code & 1;
        ::Unserialize(s, Using<TxOutCompression>(out));
    }

So, what’s the difference between these two way of implementing serializing and deserializing methods?