Privacy: How should I handle UTXO’s?

We know that, for security and anonymity, we shouldn’t reuse addresses. Also, there is the idea of change avoidance to protect ourselves from any number of change detection heuristics.

But I find that unspent change addresses (“UTXO’s”) are often unavoidable. Especially when using other privacy-enhancing techniques, such as equal-output CoinJoins, where you end up with many source addresses.

Is there a good technique to be able to spend these UTXO’s without compromising privacy?

how can I recover my private key from my passphrase and password

I decided recently to get some BTC and bitcoin core was the storage solution I decided on.

I downloaded the software, and all seemed good. No messages about storage or such.

Around a month later I purchased BTC from an atm and sent it to the Core address.

Upon returning home, I found it was “out of sync”. I literally wiped everything off my 250gb Mac in order to accommodate it. Still nothing.

I attempted to reduce the cache size, however Core told me I should reset, and so I did. However, this too didn’t help.

I am trying to find how I can recover my private key from my passphrase and password.

Bitcoin LND Lightning Network Daemon, pending open channel, opening transaction never confirmed

I’m running LND 0.7.0-beta on top of Bitcoind 0.18.0 and have a channel that has been pending on opening for more than a month now.
It tried to open when I was still running LND 0.6.1-beta.

The txid in the channel_point can’t be found through blockexplorers so I must conclude the transaction never got included in a block.

Is there a way to make LND realize this channel does not exist and give me back control of the balance?

I tried using closechannel but that did not work, because the channel is not open.
Here are the relevant log entries and output from pendingchannels and closechannel.
The channel I’m concerned with is the first one in pending channels, the second one is stuck too though.

2019-07-04 21:44:07.716 [WRN] FNDG: ChainNotifier shutting down, cannot complete funding flow for ChannelPoint(4cd80ac2bb753ae11f4de9c5eb273732480fb9d09b7599009b62d26f5199753b:1)
2019-07-04 21:44:56.217 [INF] NTFN: New spend subscription: spend_id=25, outpoint=4cd80ac2bb753ae11f4de9c5eb273732480fb9d09b7599009b62d26f5199753b:1, height_hint=583848           
2019-07-04 21:44:56.272 [INF] CNCT: Close observer for ChannelPoint(4cd80ac2bb753ae11f4de9c5eb273732480fb9d09b7599009b62d26f5199753b:1) active                                     
2019-07-04 21:44:56.715 [INF] CNCT: ChannelArbitrator(4cd80ac2bb753ae11f4de9c5eb273732480fb9d09b7599009b62d26f5199753b:1): starting state=StateDefault                             
2019-07-04 21:44:57.280 [INF] LNWL: Inserting unconfirmed transaction 4cd80ac2bb753ae11f4de9c5eb273732480fb9d09b7599009b62d26f5199753b                                             
2019-07-04 21:44:57.290 [ERR] FNDG: Unable to rebroadcast funding tx for ChannelPoint(4cd80ac2bb753ae11f4de9c5eb273732480fb9d09b7599009b62d26f5199753b:1): Transaction rejected: output already spent
2019-07-04 21:44:57.291 [INF] NTFN: New confirmation subscription: txid=4cd80ac2bb753ae11f4de9c5eb273732480fb9d09b7599009b62d26f5199753b, num_confs=3                              
2019-07-04 21:44:57.291 [INF] NTFN: New confirmation subscription: conf_id=2, txid=4cd80ac2bb753ae11f4de9c5eb273732480fb9d09b7599009b62d26f5199753b, height_hint=583848            
2019-07-04 21:44:57.291 [INF] FNDG: Waiting for funding tx (4cd80ac2bb753ae11f4de9c5eb273732480fb9d09b7599009b62d26f5199753b) to reach 3 confirmations                             
2019-07-04 21:44:58.101 [WRN] PEER: Unable to find our forwarding policy for channel 4cd80ac2bb753ae11f4de9c5eb273732480fb9d09b7599009b62d26f5199753b:1, using default values      
2019-07-04 21:44:58.102 [INF] HSWC: ChannelLink(4cd80ac2bb753ae11f4de9c5eb273732480fb9d09b7599009b62d26f5199753b:1) is starting                                                    
2019-07-04 21:44:58.103 [INF] HSWC: HTLC manager for ChannelPoint(4cd80ac2bb753ae11f4de9c5eb273732480fb9d09b7599009b62d26f5199753b:1) started, bandwidth=879768000 mSAT            
2019-07-04 21:44:58.103 [INF] HSWC: Attempting to re-resynchronize ChannelPoint(4cd80ac2bb753ae11f4de9c5eb273732480fb9d09b7599009b62d26f5199753b:1)                                
2019-07-04 21:45:28.104 [INF] HSWC: ChannelLink(4cd80ac2bb753ae11f4de9c5eb273732480fb9d09b7599009b62d26f5199753b:1) has exited                                                     
2019-07-04 21:45:28.104 [INF] HSWC: ChannelLink(4cd80ac2bb753ae11f4de9c5eb273732480fb9d09b7599009b62d26f5199753b:1) is stopping                                                    

$ lncli pendingchannels
    "total_limbo_balance": "0",
    "pending_open_channels": [
            "channel": {
                "remote_node_pub": "020f49831fd13556e5b03239df888ca031edaebe5b4efccd52d2f5c6742a743ad6",
                "channel_point": "4cd80ac2bb753ae11f4de9c5eb273732480fb9d09b7599009b62d26f5199753b:1",
                "capacity": "900000",
                "local_balance": "888768",
                "remote_balance": "0"
            "confirmation_height": 0,
            "commit_fee": "11232",
            "commit_weight": "600",
            "fee_per_kw": "15515"
    "pending_closing_channels": [
    "pending_force_closing_channels": [
            "channel": {
                "remote_node_pub": "025a625a9aa3d7c2f9a7eaa6bdb2278200b2871d35d51ab1e5bc8979078e9e1036",
                "channel_point": "5e5c88386aaa1f57b293530f175fa76b28d17fc39cc8ee2eb075ec370a2160b2:1",
                "capacity": "285083",
                "local_balance": "2000",
                "remote_balance": "0"
            "closing_txid": "1f90bf8f7065c3e90fbf72b3268ed57554c5f407e3a13397743e45048e3be546",
            "limbo_balance": "0",
            "maturity_height": 0,
            "blocks_til_maturity": 0,
            "recovered_balance": "0",
            "pending_htlcs": [
    "waiting_close_channels": [

$ lncli closechannel 4cd80ac2bb753ae11f4de9c5eb273732480fb9d09b7599009b62d26f5199753b
[lncli] rpc error: code = Unknown desc = channel not found

Bitcoin API with bech32 support

Since a while, I have been using the insight-api to view bitcoin transactions. However, recently I have found out that bech32 addresses are not supported.

Now I try to fix this issue and I am open for any suggestions.

It there some other suitable api that also supports bech32-addresses? Or, also appreciated, is there some workaround available for the insight-api

Bitcoin Core 0.18.0 in Docker container: Could not connect to the server

This is likely me not understanding how Docker works, but I’ve tried everything I can think of. I’m trying to start bitcoind in regtest mode inside a Docker container, then execute JSON-RPC commands against the container from the host machine. I’m running Bitcoin 0.18.0.

My Dockerfile looks like

FROM ubuntu:18.04

RUN apt -y update && apt -y install curl
RUN curl -o bitcoin.tar.gz
RUN tar xvf bitcoin.tar.gz

RUN mkdir -p /root/.bitcoin
RUN echo "regtest=1" >> /root/.bitcoin/bitcoin.conf \
    && echo "rpcuser=bitcoin" >> /root/.bitcoin/bitcoin.conf \
    && echo "rpcpassword=test" >> /root/.bitcoin/bitcoin.conf \
    && echo "regtest.rpcallowip=" >> /root/.bitcoin/bitcoin.conf \
    && echo "regtest.rpcbind=" >> /root/.bitcoin/bitcoin.conf

EXPOSE 18443

CMD ["/bitcoin-0.18.1/bin/bitcoind", "-printtoconsole"]

After building the image, I start the container by running

docker run -it -p <image>

I can spawn a shell in the running container and run bitcoin-cli commands successfully.

When trying to execute a bitcoin-cli command from the host machine I get this:

error: Could not connect to the server (error code 1 - "EOF reached")

Make sure the bitcoind server is running and that you are connecting to the correct RPC port.

If I run docker ps I see this:

CONTAINER ID        IMAGE               COMMAND                   CREATED             STATUS              PORTS                        NAMES
b815f8810b6b        90ef5856c984        "/bitcoin-0.18.1/bin…"   25 seconds ago      Up 23 seconds>18443/tcp   gallant_rubin

I can run bitcoind on the host machine and successfully execute bitcoin-cli commands against it, so it doesn’t appear to be a misconfiguration with the client.

I’m wondering if I’m running into this from the release notes:

The rpcallowip option can no longer be used to automatically listen on all network interfaces. Instead, the rpcbind parameter must be used to specify the IP addresses to listen on. Listening for RPC commands over a public network connection is insecure and should be disabled, so a warning is now printed if a user selects such a configuration. If you need to expose RPC in order to use a tool like Docker, ensure you only bind RPC to your localhost, e.g. docker run […] -p (this is an extra :8332 over the normal Docker port specification).

Is it even possible run Bitcoin 0.18.0 in a Docker container and use JSON-RPC from the host machine?

Why was giving someone else my 12 word backup a bad idea?

I lost my bitcoin last night when someone on blockchain support asked me to tell them my 12 word backup in order to reverse my bitcoin transaction that was unconfirmed at that time. Finally, my balance remained zero. Can someone explain to me what happened? Is there any chance for me to recover my funds?

Searching for old bitcoin “accounts “

I recall accepting bitcoin payment several years ago when the concept was fairly new. My trouble is, I don’t know what happened to the bitcoin after the receipt. What methods are available to search for “lost or abandoned “ bitcoin?
Thanks in advance