bitcoin core – Password before complete transaction

I was about to spend some bitcoins but Bitcoin Core required my password, which I don’t remember, to complete transaction… The wallet is open but cant use bitcoins.

I would like to know if before ANY transaction, you must ALWAYS enter password. This is the first time I try to send bitcoins so I don’t know how this goes…


protocol – Can a Bitcoin transaction have the same address for input and output?

At the protocol level, there is no such thing as “balance of an address”. There are individual unspent outputs (like coins in a wallet), which must be individually spent. You can’t partially spend an output, but you can split/combine it.

So for example, you have a 70 BTC output assigned to an address, and a 80 BTC output assigned to the same address. Some software will show this as 150 BTC balance of that address, but you still need to know the individual outputs to spend them. If you want to send 100 BTC to someone, you would consume those two outputs in a transaction, and create two new outputs using it, a 100 BTC one (to the recipient) and a 50 BTC one (back to yourself).

Whether you use a new address for that 50 BTC “change” output doesn’t matter to the protocol. You can reuse the old one, but will make it obvious to everyone in the world which who was the sender and who was the recipient in the transaction. Using a fresh address improves privacy.

Seen otherwise: reusing the same address may look convenient, as it allows you (and software you use) to more easily distinguish what your balance is, but it does this at the cost of making it obvious to everyone in the world. This hurts Bitcoin’s privacy – not just yours, but that of everyone in the system.

client – Confirm transaction in regtest mode

I’m running bitcoind along with Bitcore-node and I was having the same problem. I sent 250 transactions to myself, but the balance I got from BWC/BWS was:

  "totalAmount": 166250000000,
  "lockedAmount": 0,
  "totalConfirmedAmount": 0,
  "lockedConfirmedAmount": 0,
  "availableAmount": 166250000000,
  "availableConfirmedAmount": 0,
  "byAddress": (
      "address": "mvaTRJ63NJrZ3qaZW1AbfVzMsei5HCiupb",
      "path": "m/0/0",
      "amount": 166250000000

Apparently, bitcoind will hold a cache in memory and it takes some time (or more actions) to release it, passing its contents to the database.

When you close the process (say, with CTRL+C or CMD+C), you’ll see a message like this:

2020-10-22T12:23:57Z FlushStateToDisk: write coins cache to disk (250 coins, 34kB) started 
2020-10-22T12:23:57Z FlushStateToDisk: write coins cache to disk (250 coins, 34kB) completed (0.05s)

Then, Bitcore-node will sync and save everything in MongoDb. So, if you close the
bitcoind process and then restart, your transactions should become confirmed.

Here’s exactly what I did:

  1. Start bitcoind in regtest mode:
    bitcoind -printtoconsole -regtest -fallbackfee=0.00001

  2. Start Bitcore-node. I assume you have it configured to point to your regtest node.
    npm run node

  3. Generate 250 transactions to myself:
    bitcoin-cli -regtest generatetoaddress 250 "mvaTRJ63NJrZ3qaZW1AbfVzMsei5HCiupb"

  4. Wait for Bitcore to sync with bitcoind.

  5. Close bitcoind with CTRL+C (or CMD+C).

  6. Close Bitcore-node with CTRL+C (or CMD+C).

  7. Restart bitcoind and Bitcore-node.

  8. Boom. Using BWC and BWS to fetch the wallet’s balance I now receive this:


wallet – Does number of inputs or outputs affect bitcoin transaction fee?

Format for 1 input 2 outputs (1 to receiver, 1 change to owner). Normal non-seg transaction

P2SH 73 bytes(input) 32×2 (output)

P2PKH about the same as P2SH

To reduce fees reduce

a) no of inputs.

b) Use exact match (with no change output) if possible.

c) when fee is low, use more inputs or consolidate your input to fewer UTXO.(reduction of input for your future tx).

I think fee reduction increases a lot when you use multi-sig using seg-wit.

Output format 2of3 multisignature
Input size Out size

P2SH 297 32

P2SH-P2WSH 140 32 Wrapped Segwit

P2WSH 105 43 Native Segwitness

P2TR 58* 43 Pay to Taproot

P2PKH 148 34

  • means the recovery is more expensive.

To be actually sure of saving then you may want to go through the exercise of manually decoding every different type of bitcoin TX with various no of input and output.

(up to byte level where U can actually count).

electrum – How can I troubleshoot whether an unconfirmed transaction that seems stuck is a problem on my end or just from high volume on mempool?

Never had transaction hang unconfirmed like this before. Granted its only been a few hours but it’s not like I skimped on fees either. I always choose the default electrum fee, but when it got stuck I doubled it using RBF to increase the fee.

But it’s still stuck!

How can I check whether I’m really in the queue being ignored because people are paying higher fees or if there’s something wrong I’m doing on my end?

Regenerating my wallet in electrum at least restored my pre-send balance. So at least I can see my coin even if there’s no movement on this transaction that I’d love to either cancel out of or see confirmed.

lightning network – Why does every HTLC in a commitment transaction require its own signature?

Why isn’t the signature for the entire commitment transaction enough?

Because the htlc_signature field contains the signature for the HTLC transactions spending from the htlc output(s) (either received or offered) of the commitment transaction.

To expand a bit, some paths of the HTLCs scripts (timeout for an offered htlc output and success for a received HTLC output) pays to a 2of2, thus you need the right transaction which spends from this output to be signed before comiting to this (otherwise unspendable by using this script path) output.

EDIT: This question originates from this Github issue, to which Olaoluwa Osuntokun (@Roasbeef) gave today a detailed high-level explanation of why second-stage HTLCs are used in Lightning Network.

The following is the copy paste of his answer that might be of interest to anyone passing by.

Here’s my attempt at a high level explanation:

We use something called two-stage HTLCs in the system. This allows us to decouple the CLTV (absolute timelock for HTLCs) from the CSV (commitment delay to allow for breach retribution). To see why this is an issue, consider if we had both of these in the top-level HTLC script. From here, one can imagine a scenario where we have an HTLC that can be timed out (absolute block height passed), but we can’t spend it (timing it out) until our CSV period has also expired. Therefore, one needs to set their CSV values taking into account the absolute timelock (CLTV) value as well. Critically, before a user can cancel their incoming off-chain HTLC (timing out the outgoing on-chain), they need to wait for this CSV period. However, if the CSV is greater than the time lock delta (diff between incoming and outgoing HTLCs), they’ve created a race and could possibly lose money.

Without HTLCs, the dependency between the CLTV delta value and the CSV value means that if one wants to have a higher CSV value (more time to punish malicious channel peers), then they also need to have a longer CLTV delta value. As an example, a common set up with lnd is that for super higher value channels we have a CSV value of 2016 blocks (two weeks). Without second-level HTLCs, we would need to also make our CTLV delta value (40 blocks default atm), greater than 2016 blocks. This change would then propagate through the entire network, resulting in very long time lock values. The sender of an HTLC eats the full time lock delay, meaning that know their absolute worst case is much higher, trading off for better multi-hop HTLC security.

Thankfully, we figured out a solution to this: two-stage HTLCs. Note that the HTLC scripts I described above were never actually deployed. Two-stage HTLCs are actually used in the original LN white paper for a similar reason. The defective design described above was created when developers were trying to compress down the scripts and on-chain footprint a bit.

A two-stage HTLC decouples the CSV period from one’s CTLV time-lock delta. To do this, we now require the party that forced closed to spend their HTLC with a special transaction. This transaction spends a CLTV clause in the script, and itself includes a nLocktime value as well. The output of this special transaction then pays to the party timing our or redeeming the HTLC, but then enforces a CSV period. We call them two stage as we enforce two states in the claim: wait for absolute timeout value, then wait for CSV value. Note that once the absolute timeout value passes, the party can spend the original HTLC output, transitioning the HTLC claim state machine to the CSV waiting period. At this point, they can safely cancel back any off-chain HTLCs, as the other party isn’t able to settle it with a pre-image at this point.

The way we enforce this spend, is that we make any HTLC spends from one’s commitment transaction (which you broadcast during a force close) actually be a multi-sig output. We use this output to create what’s essentially an “off-chain multi-sig covenant”. Since they require our signature to spend this output, we force them into a particular type of spend using pre-signed transactions. As a result, each time we want to give them a new commitment, in addition to the commitment signature (multi-sig spending teh funding output), we also send a series of signatures, one for each HTLC, that blesses their spend of the HTLC output.

blockchain – How to automatically get transaction while sending BTC?

Here is my SendBTC method. I do not want to pass fundingTransaction variable each time I call this method. Currently, I pass fundingTransaction value by looking up to I want to get this funding transaction in this method only. How can I do this?

public static bool SendBTC(string secret, string toAddress, decimal amount, string fundingTransaction)
        Network bitcoinNetwork = Network.TestNet;
        var bitcoinPrivateKey = new BitcoinSecret(secret, bitcoinNetwork);
        var address = bitcoinPrivateKey.GetAddress(ScriptPubKeyType.Legacy);

        var client = new QBitNinjaClient(bitcoinNetwork);
        var transactionId = uint256.Parse(fundingTransaction);
        var transactionResponse = client.GetTransaction(transactionId).Result;

        var receivedCoins = transactionResponse.ReceivedCoins;

        OutPoint outPointToSpend = null;
        foreach (var coin in receivedCoins)
            if (coin.TxOut.ScriptPubKey == bitcoinPrivateKey.GetAddress(ScriptPubKeyType.Legacy).ScriptPubKey)
                outPointToSpend = coin.Outpoint;

        var transaction = Transaction.Create(bitcoinNetwork);
        transaction.Inputs.Add(new TxIn()
            PrevOut = outPointToSpend

        var receiverAddress = BitcoinAddress.Create(toAddress, bitcoinNetwork);

        var txOutAmount = new Money(amount, MoneyUnit.BTC);

        var minerFee = new Money(0.0005m, MoneyUnit.BTC);

        var txInAmount = (Money)receivedCoins((int)outPointToSpend.N).Amount;
        var changeAmount = txInAmount - txOutAmount - minerFee;

        transaction.Outputs.Add(txOutAmount, receiverAddress.ScriptPubKey);
        transaction.Outputs.Add(changeAmount, bitcoinPrivateKey.GetAddress(ScriptPubKeyType.Legacy).ScriptPubKey);

        transaction.Inputs(0).ScriptSig = address.ScriptPubKey;

        transaction.Sign(bitcoinPrivateKey, receivedCoins.ToArray());

        BroadcastResponse broadcastResponse = client.Broadcast(transaction).Result;

        return broadcastResponse.Success;

magento2.3 – Transaction Fails From Admin Order first time then works second time

I currently have Magento 2.3 installed and I ran across this issue ( that is similar to mine but I can’t seem to take conceptually what was done and get it to work for my case. I currently have

    function(Authorizenet, $) {
        $(document).on('test', 'body', function() {
            var config = <?= /* @noEscape */ $block->getPaymentConfig() ?>,
                form = "#payment_form_<?= $block->escapeJs($block->escapeHtml($block->getMethodCode())) ?>";
            new Authorizenet(config, form);
    function($) {

but no matter what I do this ends up making it worse causing the transaction to fail over and over again instead of just on the first try. What am I doing wrong?