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

How can I send bitcoin from my bisq wallets?

I feel terrible to ask this question as it is so basic that it makes me feel stupid to ask, but I am searching the web since days and cannot find an answer.

Here is the situation:
I have a Coinbase account and I understand that Coinbase cannot use different/multiple wallets but has one wallet that cannot be changed.
I also use bisq and I bought a bit of bitcoin there without hassle. However, bisq has distributed my bitcoins to multiple wallets for reasons I do not understand. It has generated countless wallets, most of them empty, but there are still 3 wallets having a bit of money each.

Now I want to sell my bitcoins, but bisq has a number of downsides for selling btc:

  • I have a limitation of 0.06 btc. I don’t understand why, because I have bisq installed since ages and I thought the limitation would start with 0.25 and grow over time, but anyway, bisq tells me I cannot offer more at a time.
    Selling all my coins at this rate would take ages!
  • Since I have two small kids now, I cannot have the computer running all the time (shielding it from the kids) and be there when a buyer comes

What I want is to sell all my funds. The easiest way that I see right now would be to transfer all funds (0.49btc) to my coinbase wallet as from coinbase I can sell any amount of btc whenever I want.

But… I found no way to transfer the BTCs in bisq. In Coinbase there is a function “receive bitcoin” but all it gives me is the wallet id. So, what is the best way to merge/transfer (all) funds from the 3 bisq generated wallets to the coinbase wallet?

Of course, if you have another suggestion on how to sell the funds easily other than through coinbase, I’d be open for that, too.

Cheers,
8bitdefender
btw: I tried to include the tag “bisq” but could not as that would be a new tag

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 https://bitcoin.org/bin/bitcoin-core-0.18.1/bitcoin-0.18.1-x86_64-linux-gnu.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=0.0.0.0/0" >> /root/.bitcoin/bitcoin.conf \
    && echo "regtest.rpcbind=127.0.0.1" >> /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 127.0.0.1:18443:18443 <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 127.0.0.1:18443 (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       127.0.0.1:18443->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 127.0.0.1:8332:8332 (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?