text:
How can I efficiently build a near-full block in regtest?
I want to build near-full blocks in regtest.
I have written a script that does the job (on bitcoin core v24.0rc3), but it's too slow to be practical for my use case:
#!/usr/bin/env bash

BCLI="./bitcoin-cli -regtest"
DAEMON="./bitcoind -regtest"

# Start from a clean node
$BCLI stop
sleep 2
rm -rf ~/.bitcoin/regtest
$DAEMON
sleep 2

set -eo pipefail

$BCLI -named createwallet wallet_name="miner" load_on_startup=false
mineraddress=$($BCLI getnewaddress)
$BCLI generatetoaddress 1000 $mineraddress
i=0
time while [ $i -lt 100 ]
do
    newaddress=$($BCLI getnewaddress)
    $BCLI sendtoaddress $newaddress 1
    i=$((i+1))
done
$BCLI generatetoaddress 1 "$mineraddress"

There are a number of problems with this script:

It's very slow, creating just ~10 transactions per second
It's getting slower as more txs are created
I have to generate lots of blocks (1000 instead of eg 101) to avoid hitting the limit of 25 chained mempool transactions, which further slows down the script.
The above script creates just 100 txs for now just to measure its performance, but in reality I'd like to make ~7000 txs or more.

Can I improve this more than by just a constant factor?

Ideally you want to create the maximum number of UTXOs you can in each block so you can spend from each of them and create multiple UTXOs for each spent TXO in the next block right? A tree of UTXO spends. A chain of 25 transactions resulting in only one UTXO doesn't help much as you say.


text:
how to run multiple bitcoind node on one server?
I have created one full node bitcoind on my VPS, that one is serving application A.
Now I want to create application B that has another node but on same VPS.
is that possible to install multiple bitcoind on one server using different wallet?
let's asume that I want application A connect to wallet.dat, application B to wallet_new.dat, with different bitcoin.conf configuration.

We can run 2 bitcoind nodes on a single server without installing it multiple times.
 We just have to create 2 data directory with a different configuration file (bitcoin.conf) for the 2 nodes. This configuration file should have different port numbers, user name and password specified.
Node1:
bitcoind -regtest -datadir=./bitcoinNode1/ -conf=./bitcoinNode1/bitcoin.conf -rpcport=19001 -port=19000

Node2:
bitcoind -regtest -datadir=./bitcoinNode2/ -conf=./bitcoinNode2/bitcoin.conf -rpcport=19011 -port=19010

You can also make the 2 nodes to connect each other by specifying the connect command while starting node2 as mentioned below.
bitcoind -regtest -datadir=./bitcoinNode2/ -conf=./bitcoinNode2/bitcoin.conf -rpcport=19011 -port=19010 -listen=0 -connect=127.0.0.1:19000

All you need to do is update the bitcoin.conf for the second port to point to a different datadir, and use a different RPC port.
Do keep in mind that this will result in double the resource use for everything. Additionally, depending on your VPS, running multiple nodes on a single machine might not be feasible.
Usually, multiple applications should be able to use a single node, and differentiate addresses etc. at an application level.

how about wallet ? how to point that port a (e.g 8331) is for wallet a, and port b (e.g 8332) is for wallet b ? The point is I just want using different wallet for different app, in case something bad happed to one wallet doesn't affect another app ..

The wallet is controlled via the rpc, so simply changing the rpc port is enough. Changing the datadir ensures the second node will use a separate wallet file.

Yes it's possible, you must run each bitcoind in different port and different datadir, take a look here  https://en.bitcoin.it/wiki/Running_Bitcoin

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
How to create, sign, and send a transaction using electrum wallet RPC
How to create, sign, and send a transaction using electrum wallet RPC ?
I have experience create/sign/send a transaction using bitcoind wallet since I just have to using bitcoind RPC. But on electrum I couldn’t find that the RPC command to do that.
The only thing I want is send bitcoin from electrum wallet but from specific addresses.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
How to stop another bitcoind service?
I created two bitcoind service in my server.
First using default configuration, and second use new configuration.
I am able to stop first bitcoind using bitcoin-cli stop, but the second bitcoind still running. How to safely stop the second bitcoind without forcing to kill it ?

Not an answer, but a SIGTERM or SiGINT will cause a graceful shutdown of bitcoind.

bitcoin-cli has a -datadir option so you can specify the data directory of your other bitcoind instance. It will use that parameter to read the bitcoin.conf and .cookie files in the other data directory so that it can connect to the other bitcoind instance. With that parameter, you can send RPC commands to it, including the stop command.
Alternatively, you can stop bitcoind by finding its PID (using ps) and the kill command. kill be default uses SIGTERM so bitcoind will actually safely shutdown by going through its shutdown process.

bitcoin-cli accepts a -conf parameter. Use that to point to the config of the second bitcoind client (which would contain the rpc details), and then shut it down as normal.
You can also use -rpcpassword, -rpcport, and -rpcuser to supply the details manually.


text:
How to retrieve unclaimed BTC for wallets whose private key is lost
How to retrieve unclaimed BTC for wallets whose private key is lost
Kindly share details

You need a private key to send the coins away. If you don't have the private key, you can't send the coins.

If you lose the private key for some address that contains bitcoins, then you will never be able to spend those bitcoins. The private key is required in order to spend, and there is no known way to work backwards to discover the private key for an account.
If the private key is lost, the bitcoins become un-spendable.

Bitcoins are unspendable without the private key (as chytrik already stated). That being said, several wallets implement BIP032 which allows you to recover those private keys. It uses a "seed" (usually shown as several words) to initialize the wallet. Then the creation of the private keys is deterministic.
With this seed you would be able to "recover" your private key and therefore the unspent BTC.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
which wallets/softwares utilize taproot capabilites?
this question is not about being able to pay/receive to taproot addresses as I know there's a list for that here. I'm curious to see if anyone knows about wallets/software that utilize taproot capabilities for multi-sig, lightning, MAST capabilites, etc..


text:
Why Schnorr was added to secp256k1 library instead of a separate library?
Schnorr signatures are often compared as superior to the Elliptic Curve ones. Then why developers added Schnorr  into libsecp256k1 library which is, as the name suggests, an Elliptic Curve library?
Why not create a separate C library? Or is Schnorr signature part of Elliptic Curve signature group?
Thanks

Yes, the BIP340 signature scheme that was added to libsecp256k1 is an Elliptic Curve based variant of Schnorr signatures. Traditionally Schnorr signatures use a group of integer multiplication modulo a large prime, but that's not what is used here. It's integrated into libsecp256k1, because it is a Schnorr scheme over the secp256k1 group, so lots of code is shared between ECDSA and Schnorr.

Do all the advantages of Schnorr still hold even if it uses a non-traditional Elliptic Curve implementation?

"Schnorr signatures" isn't a fully specified scheme; it's a general class of digital signature algorithms with many possible variations. All the advantages of the BIP340 scheme over ECDSA obviously apply - the scheme was specifically designed to have those!

@PieterWuille whats the advantages of doing that over secp256k1 instead of the regular large prime"?

@Ron You mean using Schnorr over an integer multiplication group? That has all the disadvantages such groups have: you need around 3000-bit keys and signatures for a similar security level, they're much slower, and they need a very different security assuption than the one Bitcoin already relies on (secp256k1's DL hardness).


text:
Restoring from old paper Mycelium Wallet Backup
I have an old Mycelium Wallet Backup on paper, created July 2014, Mycelium Wallet 1.2.12., Backup Format Mycelium Backup 1.0. It used a 15-character password + checksum character, which I have.
It also lists Bitcoin address, and Encrypted Private Key - both in QR-code and in string of characters.
How do I go about restoring this wallet to a current wallet, be it Mycelium or some other one?

Answering to myself: at least MyCelium can scan the Mycelium Backup 1.0 PDF paper wallet. However, one must tap the QR code symbol to change to "Legacy (P2PKH)". After scanning the paper wallet QR-code, Mycelium then asks for the 15-character password + checksum character.

In Mycelium there should be an option to restore a backup. Inside this restoration feature there should be an option to recover legacy backups (the one you have) once you have selected that you scan the qr code of the encrypted private key. The next thing you get presented with is the prompt to enter your passcode (the 15 digit one). I believe though, you need to enter 16 characters. All of those characters are alphabetical ones. the 16th digit is the checksum character (this is also a character ranging from A-Z if you have not written that down). It should be succesful after the correct passphrase was entered.

I would suggest asking this question on the mycelium issue topic. Either for android or ios. Generally for the backups in that time bip39 was a main standard as per https://walletsrecovery.org/ - mycelium was supporting WIF (wallet import format). Knowing the derivation paths, one can recover from it in the wallet that supports WIF (like electrum?).

It would seem this is not WIF, which seems to be a 64 character string. Rather, this is a 62 character encrypted private key.

I do have the 15-character password for the encrypted key, but I do not understand how to go about decrypting it as per the second page of the paper wallet instructions.
(Parsing the QR Code, Decoding the 3 Header Bytes, AES Key Derivation, Decrypting the Private Key, Generating the Bitcoin Address, Verifying the Checksum"
I do have the Bitcoin Address related to this Private Key, and therefore know there is some bitcoin there.


text:
Adroid Blockchain wallet ver 4.0.12 recovery
Just repaired my old Android phone, with Blockchain wallet version 4.0.12. It is asking for either the four digit PIN or the password, which I have both forgotten.
Is there any way to recover this now seven years old wallet?

Do you have your recovery phrase

Not sure if recovery phrase was even asked for at the time of opening this wallet, back in 2014.

Is there any way to recover this now seven years old wallet?

No.
This is because you probably ignored any advice to

keep somewhere safe a separate written note of your recovery phrase (seed phrase, backup phrase) or private key.

Make regular backups of important data on your computers (including on your phones)

Practise recovery from those notes and backups.

It is also because Android phones protected by PINs and passwords take measures to prevent thieves accessing your private data. As an inevitable side-effect, those measures also prevent you accessing that data if you forget your phone's PIN and Password and didn't make a written note kept somewhere safe.

I can open the phone, that PIN code I can remember. However, I do not remember the PIN code for the Blockchain wallet.

If you have access to the phone, and have some idea of what your wallet password might have been like, there are tools that may help you to sucessfully guess the password. These tools may take a very long time and not succeed.
For example https://github.com/gurnec/btcrecover says

Bitcoin wallet password recovery support for:
[...]

Blockchain.info

[...]

The screen of this phone was broken for years and I just managed to change it.I can open the phone, that PIN code I can remember. However, I do not remember the PIN code for the Blockchain wallet.

The Blockchain wallet is described as "You’re the custodian, you have control.". That means if you forget the PIN etc, and didnt make backups or write down the recovery phrase, you can no longer use that money.


text:
understand bitcoin transaction json extracted from blockchain
i'm trying to understand bitcoin transaction extract from bitcoin core with RPC,
with an example this block hash : 00000000d14f2e97678951ad004d6699babd27e07ca722c46b30dc24c67eed7a
{"method": 'getblock', "params": ["00000000d14f2e97678951ad004d6699babd27e07ca722c46b30dc24c67eed7a", 2], "jsonrpc": "2.0"}

json block from getblock
{
    'hash': '00000000d14f2e97678951ad004d6699babd27e07ca722c46b30dc24c67eed7a',
    'confirmations': 677712,
    'strippedsize': 489,
    'size': 489,
    'weight': 1956,
    'height': 728,
    'version': 1,
    'versionHex': '00000001',
    'merkleroot': '1f7fd770697c167ca75e3d742f3b1b81244165e0fee87310cd20b15f6975b961',
    'tx': [{
        'txid': '5fe6030e8a649b3b3fb257303e89a06d6556226e24118b494f9ccbba06e96254',
        'hash': '5fe6030e8a649b3b3fb257303e89a06d6556226e24118b494f9ccbba06e96254',
        'version': 1,
        'size': 134,
        'vsize': 134,
        'weight': 536,
        'locktime': 0,
        'vin': [{
            'coinbase': '04ffff001d0164',
            'sequence': 4294967295
        }],
        'vout': [{
            'value': 50.0,
            'n': 0,
            'scriptPubKey': {
                'asm': '04fa4b30422c7820c4ef979eaa39f770b32dcddc433cfd4d3040d3f2dc337e445dfd80fd4a3afbabe11e861fe30a28c5acc0f59915d9e419ffecd8ce374d46ddf5 OP_CHECKSIG',
                'hex': '4104fa4b30422c7820c4ef979eaa39f770b32dcddc433cfd4d3040d3f2dc337e445dfd80fd4a3afbabe11e861fe30a28c5acc0f59915d9e419ffecd8ce374d46ddf5ac',
                'type': 'pubkey'
            }
        }],
        'hex': '01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0704ffff001d0164ffffffff0100f2052a01000000434104fa4b30422c7820c4ef979eaa39f770b32dcddc433cfd4d3040d3f2dc337e445dfd80fd4a3afbabe11e861fe30a28c5acc0f59915d9e419ffecd8ce374d46ddf5ac00000000'
    }, {
        'txid': '6f7cf9580f1c2dfb3c4d5d043cdbb128c640e3f20161245aa7372e9666168516',
        'hash': '6f7cf9580f1c2dfb3c4d5d043cdbb128c640e3f20161245aa7372e9666168516',
        'version': 1,
        'size': 274,
        'vsize': 274,
        'weight': 1096,
        'locktime': 0,
        'vin': [{
            'txid': 'ff3dc8b461305acc5900d31602f2dafebfc406e5b050b14a352294f0965e0bf6',
            'vout': 0,
            'scriptSig': {
                'asm': '3046022100e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b022100b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d[ALL]',
                'hex': '493046022100e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b022100b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d01'
            },
            'sequence': 4294967295
        }, {
            'txid': '2db69558056d0132d9848851fd20329be9cd590fa5ae2b3c55f58931f42e27f7',
            'vout': 0,
            'scriptSig': {
                'asm': '3046022100a2ab7cdc5b67aca032899ea1b262f6e8181060f5a34ee667a82dac9c7b7db4c3022100911bc945c4b435df8227466433e56899fbb65833e4853683ecaa12ee840d16bf[ALL]',
                'hex': '493046022100a2ab7cdc5b67aca032899ea1b262f6e8181060f5a34ee667a82dac9c7b7db4c3022100911bc945c4b435df8227466433e56899fbb65833e4853683ecaa12ee840d16bf01'
            },
            'sequence': 4294967295
        }],
        'vout': [{
            'value': 100.0,
            'n': 0,
            'scriptPubKey': {
                'asm': 'OP_DUP OP_HASH160 12ab8dc588ca9d5787dde7eb29569da63c3a238c OP_EQUALVERIFY OP_CHECKSIG',
                'hex': '76a91412ab8dc588ca9d5787dde7eb29569da63c3a238c88ac',
                'reqSigs': 1,
                'type': 'pubkeyhash',
                'addresses': ['12higDjoCCNXSA95xZMWUdPvXNmkAduhWv']
            }
        }],
        'hex': '0100000002f60b5e96f09422354ab150b0e506c4bffedaf20216d30059cc5a3061b4c83dff000000004a493046022100e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b022100b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d01fffffffff7272ef43189f5553c2baea50f59cde99b3220fd518884d932016d055895b62d000000004a493046022100a2ab7cdc5b67aca032899ea1b262f6e8181060f5a34ee667a82dac9c7b7db4c3022100911bc945c4b435df8227466433e56899fbb65833e4853683ecaa12ee840d16bf01ffffffff0100e40b54020000001976a91412ab8dc588ca9d5787dde7eb29569da63c3a238c88ac00000000'
    }],
    'time': 1232133515,
    'mediantime': 1232128717,
    'nonce': 95106676,
    'bits': '1d00ffff',
    'difficulty': 1,
    'chainwork': '000000000000000000000000000000000000000000000000000002d902d902d9',
    'nTx': 2,
    'previousblockhash': '000000001c7eb6ab129cf14659aea1f77f6e116ea8da2193182b08eae6ecf5f7',
    'nextblockhash': '00000000ce8f753a6df03ffba3ed05db6cf79013e79b7d20c87e0e88b7672fbf'
}

in "tx" i can see multiple transaction stored inside block, what's difference between, i supposed "vin" is for incoming transaction but whey they dont have similar architectur ?
Thanks
'vin': [{
            'coinbase': '04ffff001d0164',
            'sequence': 4294967295
        }],

# is not similar to

'vin': [{
            'txid': 'ff3dc8b461305acc5900d31602f2dafebfc406e5b050b14a352294f0965e0bf6',
            'vout': 0,
            'scriptSig': {
                'asm': '3046022100e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b022100b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d[ALL]',
                'hex': '493046022100e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b022100b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d01'
            },
            'sequence': 4294967295
        }, {
            'txid': '2db69558056d0132d9848851fd20329be9cd590fa5ae2b3c55f58931f42e27f7',
            'vout': 0,
            'scriptSig': {
                'asm': '3046022100a2ab7cdc5b67aca032899ea1b262f6e8181060f5a34ee667a82dac9c7b7db4c3022100911bc945c4b435df8227466433e56899fbb65833e4853683ecaa12ee840d16bf[ALL]',
                'hex': '493046022100a2ab7cdc5b67aca032899ea1b262f6e8181060f5a34ee667a82dac9c7b7db4c3022100911bc945c4b435df8227466433e56899fbb65833e4853683ecaa12ee840d16bf01'
            },
            'sequence': 4294967295
        }],

do you have a link who help me to understand every title of a raw
block transaction ? (i didn't found)
vin is for incoming fund, and vout is for outgoing fund ? correct ?

thanks


text:
Why does Electrum include seemingly unnecessary inputs in a transaction?
I want to make a payment of x BTC.
My Electrum wallet shows two "output points" in the Coins tab (with the same address). Both of these show an amount much larger than x BTC.
If go to the Send tab and start to make a payment to an address, then click "Pay..." and then "Advanced", I can see two inputs, which seem to correspond to the two "output points" in the Coins tab and show the same amounts. The transaction size is 447 bytes. I abandon this transaction.
If I go to the Coins tab, right click on one of the two "output points" and choose "Spend", Electrum shows a green banner saying "Coin control active". If I start to make the same payment, the "Advanced" dialog now only shows one input and the transaction size is 226 bytes.
This looks to me as though I can make the same transaction and incur a smaller fee by using "coin control". Am I missing something? Is there a disadvantage or risk to doing this? I'm thinking there must be, otherwise Electrum would just do it automatically.
I could understand needing two inputs to the transaction if x was more than the amount associated with each one of my two "output points", but it isn't.
Thanks!

Electrum used both UTXO, even if only one was needed, to protect your privacy albeit at the expense of higher fee.
This is from the Electrum source code and explain this choice:
Attempts to better preserve user privacy.
First, if any coin is spent from a user address, all coins are.
Compared to spending from other addresses to make up an amount, this reduces
information leakage about sender holdings.  It also helps to
reduce blockchain UTXO bloat, and reduce future privacy loss that
would come from reusing that address' remaining UTXOs.
Second, it penalizes change that is quite different to the sent amount.
Third, it penalizes change that is too big.

This looks to me as though I can make the same transaction and incur a
smaller fee by using "coin control". Am I missing something?

No, you are right, if you wish focus more on fee minimization instead of privacy, you can achieve better result doing so manually than rely on the Electrum coin control policy.

Is there a disadvantage or risk to doing this? I'm thinking there must
be, otherwise Electrum would just do it automatically

There are multiple goal you may want achieve with a coin selection strategy and there is no one strategy that solves all problems, so wallets adopt different strategies depending on their priorities; but these strategy are meant for unskilled user or user that don't care these things (eg. the Coins tab is hidden by default on Electrum)... If you know how bitcoin transactions works and what UTXO are, probably you prefer do your own coin selection manually based on the needs of a specific transaction.

Thank you! This makes sense. I've been reading around a bit more and it looks like a) I re-used addresses in the past, which I now realise I shouldn't have done b) Electrum is making this more expensive transaction to fix that. My current inclination is to let Electrum use a two input transaction and accept the larger fee this time, then my next transaction will automatically be a one-input transaction anyway as I will no longer have multiple coins sharing an address. Does that seem reasonable/correct?

yes, you got the point ... but keep in mind that Electrum can choose a sub optimal UTXOs group (from the fees side) in other cases as well, so if you care, take a look on "advanced tab" anyway.


text:
P2sh redeem script hash
What are the contents of a redeem script hash in a p2sh transaction?
From what i read it's similar to the pubkey script but does it only contain the receiver's address?

1. Bitcoin single signature P2SH:
RedeemScript Template = “[PubKey] OP_CHECKSIG”
Working Examples:
% echo "[020ae29f86f404e4b302cfa17ff15d93149af6a54c80a4172d47e41f55f6a78d73] checksig" | bx script-encode
21020ae29f86f404e4b302cfa17ff15d93149af6a54c80a4172d47e41f55f6a78d73ac (Script)
% echo "[020ae29f86f404e4b302cfa17ff15d93149af6a54c80a4172d47e41f55f6a78d73] checksig" | bx script-encode | bx sha256 | bx ripemd160
49e266a68641d2caa6696b00696f00f0a5706350   (Hash Answer)
% echo "[020ae29f86f404e4b302cfa17ff15d93149af6a54c80a4172d47e41f55f6a78d73] checksig" | bx script-encode | bx sha256 | bx ripemd160 | bx base58check-encode -v 5
38RgUAR367PFbFFgS57BYcERHkpqHEMBvA  (Address)
or more simply,
% echo "[020ae29f86f404e4b302cfa17ff15d93149af6a54c80a4172d47e41f55f6a78d73] checksig" | bx script-to-address -v 5
38RgUAR367PFbFFgS57BYcERHkpqHEMBvA
2. Bitcoin BIP16 multisig:
2 of 3 RedeemScript Template = "OP_2 [PubKey1] [PubKey2] [PubKey3] OP_3 OP_CHECKMULTISIG"
Working Examples:
% echo "2 [020ae29f86f404e4b302cfa17ff15d93149af6a54c80a4172d47e41f55f6a78d73] [03664d528eb80096671ef9011c533ceb5df133238e3690d88f2960c786398b86b1] [029a449ea4a2155ea10002d704604bb3e8606631d35af20889a74b82b2dab572f6] 3 checkmultisig" | bx script-encode
5221020ae29f86f404e4b302cfa17ff15d93149af6a54c80a4172d47e41f55f6a78d732103664d528eb80096671ef9011c533ceb5df133238e3690d88f2960c786398b86b121029a449ea4a2155ea10002d704604bb3e8606631d35af20889a74b82b2dab572f653ae (Script)
%  echo "2 [020ae29f86f404e4b302cfa17ff15d93149af6a54c80a4172d47e41f55f6a78d73] [03664d528eb80096671ef9011c533ceb5df133238e3690d88f2960c786398b86b1] [029a449ea4a2155ea10002d704604bb3e8606631d35af20889a74b82b2dab572f6] 3 checkmultisig" | bx script-encode | bx bitcoin160
7e580c3a86432d96dd60784e99f5a94e463414fe   (Hash Answer)
% echo "2 [020ae29f86f404e4b302cfa17ff15d93149af6a54c80a4172d47e41f55f6a78d73] [03664d528eb80096671ef9011c533ceb5df133238e3690d88f2960c786398b86b1] [029a449ea4a2155ea10002d704604bb3e8606631d35af20889a74b82b2dab572f6] 3 checkmultisig" | bx script-to-address -v 5
3DD4YP2T75TQtf84KrHzYVLYgNAeaHWqxq (Address)
3. Bitcoin P2WPKH-nested-in-P2SH:
RedeemScript Template = "0 [PubKey]"
Working Examples:
% echo "0 [020ae29f86f404e4b302cfa17ff15d93149af6a54c80a4172d47e41f55f6a78d73]" | bx script-encode
0021020ae29f86f404e4b302cfa17ff15d93149af6a54c80a4172d47e41f55f6a78d73 (Script)
% echo "0 [020ae29f86f404e4b302cfa17ff15d93149af6a54c80a4172d47e41f55f6a78d73]" | bx script-encode | bx bitcoin160
7138cbb443e9ed635d3dd02a3e450884e3f9f0c8  (Hash Answer)
% echo "0 [020ae29f86f404e4b302cfa17ff15d93149af6a54c80a4172d47e41f55f6a78d73]" | bx script-to-address -v 5
3C1gKTRSAwSLj8Ft1eYooLkWxwJ5cqDdpb  (Address)

currently the most use case for P2SH tx are multisig constructions. They usually contain s.th. like this:
OP_2 <Pubkey1> <Pubkey2> <Pubkey3> OP_3 OP_CHECKMULTISIG

This is a 2-of-3 multisig redeemscript, which is then hashed, and returns on mainnet an address starting with "3". It does not contain the receiver address, it contains the public keys.
Looking a bit in the forum on P2SH and multisig, you find useful info, and of course multisig is not the only use case for P2SH. Smart contracts are also a common usage. I recommend reading the developer examples and references for multisig p2sh, and also Andreas' book "Mastering Bitcoin". Here especially chapter 7 on advanced transactions. It is an amazing book that'll definitely get you started. It's freely available online here.

Another example is for BIP 49 P2WPKH-nested-in-P2SH redemptions (currently used by Trezor segwit-enabled devices), i.e. OP_0 <HASH160(Pubkey)>


text:
Linking bitcoin addresses
Is it possible to link multiple bitcoin addresses under one private key?
This would make signing raw transactions easier.

Is it possible to link multiple bitcoin addresses under one private key?

It is possible to derive different addresses from a single private key, namely one address from the private key's compressed public key, and one from the private key's uncompressed public key.
If you sent bitcoins to each of these two addresses, they would exist as separate UTXOs, even though the same private key could sign to spend the funds in either address.

This would make signing raw transactions easier.

I'm not sure what is meant by 'easier' here, but in general, it is advised that users do not handle keys themselves, rather let the software take care of this.
Perhaps also worth mentioning: BIP 32 HD wallets allow many keypairs/addresses to be generated from a single seed/extended key. However each address generated in the HD wallet can only be spent by signing with the private key associated with that address. A parent extended private key cannot sign for child address transactions (it is instead used to derive the child private keys, which can then be used to sign transactions).


text:
Create a transaction which sends bitcoin to the address it's being sent from?
Let's say address X has 1 btc. Can you create a transaction which would send the 1 btc from X back to X and broadcast it without having to sign it, since the 1 btc is going back into the address it is being sent from?

Transactions don't send from address to address.
Transactions spend specific coins ("transaction outputs") and create new coins as a result. Every coin has an amount and an owner (identified by its address).
While it's possible to define the "balance" of an address as the sum of the values of all coins with that address as owner, this is not how the system works internally. Addresses are just an authentication mechanism to make sure coins can't be spent without proving ownership. In particular, a transaction that sends coins "back to the same address" is in no way different from one that doesn't. It's still spending a coin and creating a new one - just one that happens to have the same owner. In order to spend a coin you need to prove you own it.

Unsigned transactions are invalid and will be rejected by all miners and other nodes.


text:
Mining pools like eligius
Can someone provide a list of mining pools like eligius who will accept non standard transactions directly and mine them?

No pool today includes non-standard transactions in blocks.
To be correct, there are a number of conditions and pool options. Some pools have strict rules, some pools - no. But all pools today have their own policy rules for accepting or rejecting transactions to a mempool.
There is no correct answer to your question without knowledge what kind of standardness do you mean. The only thing you can do is connecting to all nodes and broadcasing your transaction hoping someone will accept it.

I mean a transaction like: https://blockchain.info/tx/91c8b08f305d895d6bc8f43bbdd36dcbc7f1d998e3df5e8f13dd9cdeebf15cb5?show_adv=true

this transaction is standard today. every pool will accept it


text:
Clients without Isstandard() function
Are there any bitcoin clients without the Isstandard () function which would allow non standard transactions to be broadcast?

I don't know about any client that removed standardness checks altogether. However there exists some alternate clients with different default policy settings, such as Bitcoin Knots.


text:
Bitcoin Debit Card without a phone (number)
Where can I signup for a bitcoin debit card without a phone?
There are a number of "bitcoin debit card" providers -- services that issue you a traditional visa/mastercard/etc debit card that allows you to pay for purchases in fiat, but where the balance of the card is automatically converted from your cryptocurrency balance stored on their custodial wallet.

Note that a "bitcoin debit card" is distinct from gift cards in that the balance lives in an account below the debit card, not on the card itself. This is important because otherwise you may end-up with tons of different cards with low balances. It's important for my business that I can pay invoices with a single card, and if that card expires then the balance can simply be spent on the card's replacement.

Unfortunately, I've been unable to find any providers that do not require a phone to be linked to the account.
For security reasons, I do not mix insecure devices like my phone with high-risk accounts like financial services. Therefore, it's important that I find financial services that don't require a phone number to be linked to the account (shudder at the thought of implementing 2FA over SMS) or an app.
Coinsbank requires a phone number. Wirex requires a phone number. Cryptopay requires an app (which grants access to the account to a phone). Unbanked (Ternio) is dead.
Where can I get a "bitoin debit card" without a phone?

Hi Michael, unfortunately any requests for service recommendations or reviews are off-topic here. Those sort of topics tend to outdate quickly, tend to get poorly argued answers, and attract a lot of spam, so we no longer collect them.

@Murch can you at least recommend an alternative forum where such a question is appropriate and will likely yield useful answers?

You could perhaps try /r/bitcoin or Stacker.news?


text:
fund stolen from my blockchain wallet
I am Ashish jaiswal from India. I logged in to my blockchain wallet today and i received the approval email from blockchain. I approved the email and in next minute I see 8.43 btc has been taken out of my wallet. what shall I do?

Sorry to hear about your loss, unfortunately there is likely nothing that anyone here can do to help you. Without a lot more information, it isn't possible to say how you were hacked. You could attempt to contact blockchain(dot)com's customer service team for more help.

What "approval email" are you talking about exactly?

It seems possible the "approval email" was a fake and that you clicked a link in that email which led to a fake website that tricked you into giving your account credentials to a thief.

what shall I do?

Report the theft to blockchain.com and ask for their help.
Report the theft to your local police.
Accept that your money is gone and almost certainly will never be recovered.
Perhaps do some research on the differences between custodial-wallets and non-custodial wallets and on the differences between hot-wallets and cold-wallets. Investigate the prices and availability of hardware wallets.
Do not respond to unsolicited messages from people saying they can recover your money - they are conmen who will later invent false fees you need to pay them.


text:
Need Help about Console in Bitcoin Core
I would like to ask the following. I've downloaded Bitcoin Core and just start using their "Console". Before I can createrawtransaction, I need to first set up a node in Bitcoin Core, right? If yes, I did follow the instruction in https://developer.bitcoin.org/reference/rpc/index.html.
However, when I want to apply a node for myself that is using --> addnode "167.172.250.161:8333" "onetry"
but end up is Null although I have requested for "getnodeaddresses" as per the screenshot:

Please advise as I need to "importprivkey" in order to perform the createrawtransaction.
Also, my apology I would like to ask this as well. Why when I send createrawtransaction in the Bitcoin Core Console, the error it states here that the error - Method not found (code -32601). Anyone can advise or provide guidance to me? I'm no expert in this. Thanks in advance.

Running Bitcoin Core (bitcoind or bitcoin-qt) already means running a node.
You don't need to set it up.
The addnode function is used to manually add a connection to another node.
This is not something necessary, unless you have specific reasons to connect to a particular node (e.g. a node you trust).
This function does not return any object (although executed successfully), which is why get null in return.
getnodeaddresses returns a random subset of node addresses known to your node.
As for the RPC methods, generateprivkey does not exist, while the error for createrawtransaction is probably due to a wrong input format (you are missing the squared brackets in the second object)
The correct format is:
[{"txid":"id","vout":n},...] [{"address":amount},{"data":"hex"},...]

Also note that you won't be able to create a transaction without having the corresponding keys in your wallet.

Thanks for correcting my mistakes and explain that I don't need to set up a node in it. As for the createrawtransaction format, I would like to ask the following:
createrawtransaction [{"txid":"hex","vout":n,"sequence":n},...] [{"address":amount},{"data":"hex"},...]
Okay, as for the "sequence" is the private key right? (this one I'm stuck with error in the command line in Console using "importprivkey") and the "data" --> it said as "key-value pair" where can I get this?

A basic transaction has 1 or more inputs of the type (txid:vout), corresponding to unspent outputs from previous transactions sent to your address, and 1 or more outputs of the type (address:amount). The correct sequence of actions you need is: 1. create the raw transaction, 2. sign it, 3. broadcast it.
You might want to take a look at some step-by-step guide, like this one: https://medium.com/coinmonks/how-to-create-a-raw-bitcoin-transaction-step-by-step-239b888e87f2 . You will find many on the Internet.

When you import a private key, the client should rescan the blockchain to see what transactions are spendable with such a key.  You can then check the list of unspent outputs to create a new transaction.
Please consider using testnet to learn, instead of mainnet. You can obtain testnet coins for free from any "faucet" on the internet

thanks for the clear explanation. I have checked out on the link https://medium.com/coinmonks/how-to-create-a-raw-bitcoin-transaction-step-by-step-239b888e87f2 sorry as I'm no expert and non-developer. those script of Create a raw transaction, where can I run it? Like Atom Editor? Command Prompt? But I don't think I can run that script in Bitcoin Core right? Correct me and guide me, many thanks.

Those are command line instructions (so from the prompt). I don't know the console, I guess it works the same way. But if you are no expert and you do not need to use the console to send transactions. Just look for the corresponding function in the software interface.

thanks for your reply. I can use the Console provided with the right command line. Sorry, you mentioned the software interface with the corresponding function-which one are you referring to?

I refer to the "Send" function of the Bitcoin-qt interface


text:
What was the reason when Bitcoin was $33,000, GBTC was about $33, but now Bitcoin is $54,000, and GBTC is $43?
I did see the question Why does GBTC frequently not track Bitcoin's price?, but exactly what happened when Jan 2021, Bitcoin was about $33,000 and GBTC was $33, and now (Apr 30, 2021) Bitcoin is $54,000, and GBTC is $43?

no answer, no comment, just closed. I think there are lots of intellectually curious people out there


text:
Balance in bitcoin-qt suddenly significantly diminished after a small transaction?
I had my wallet stored on a storage provider for a while, and recently got a new computer and installed bitcoin-qt and imported my wallet.
It said I had about 2 BTC and showed INGOING transactions from 2013, which I had not touched since.
I recently then transferred 0.33 BTC to another recipient, and then immediately the bitcoin balance dropped to 0.07 BTC.
I have no recollection if I have used my wallet on other computers in the time between 2013 and now, but I thought the blockchain had a perfect copy of all transactions from my wallet.
Any idea what could have happend? Can I have spend bitcoin on my wallet on another computer in say, 2015, that never got relayed to my wallet stored on cloud storage? Are the transactions stored in the wallet.dat and not on the blockchain only?
Sorry, I am confused.

The balance that you see is the confirmed balance. This is the sum of the unspent transaction outputs controlled by your wallet that are in transactions that have been confirmed. The confirmed balance can temporarily decrease more than the amount that you actually want to send due to change outputs. However once the transactions confirm, it should be what you expect it to be.
When you make a Bitcoin transaction, it has to spend transaction outputs that were created previously. Because an output can only be spent in full, the transactions that your wallet makes typically create another output called a change output. This is a transaction output that your wallet can spend; it is sending the change back to itself.
When this happens, because the change output is a new output in an unconfirmed transaction, the value in that change output no longer counts towards the confirmed balance. It counts as part of the unconfirmed balance which is shown in the GUI as the Pending Balance. Once the transaction confirms, it will be counted as the confirmed balance.

Not sure I understood anything of that. Does that mean in other words, that after the 0.33 btc has been confirmed, the balance should shift back to the 2btc - 0.33btc?

Yes, once that transaction has confirmed, your balance should go to what you expect it to be (it might be a bit lower due to having to pay transaction fees).


text:
Is bitcoin client really downloads the full transaction info?
I started learning bitcoin and found this wiki: https://learnmeabitcoin.com/beginners/network
And there is this statement:
When you run the client it will connect to other nodes and start downloading a full copy of the blockchain (the file that contains all the verified transactions). After that, your client will start receiving transactions from other nodes and relaying them around the network.
Is it really true that each bitcoin client downloads the full transaction history?
Unsure if that scales...
And if someone could provide a good official doc about explaining how bitcoin works?


text:
Is it possible to spend the unspent outputs of a burn address?
If a burn address is created without a private key to prevent access to the bitcoin there, is not possible to create a transaction which would spend the utxos since there is no private key to sign the transaction?

not possible to create a transaction which would spend the utxos since there is no private key to sign the transaction?

Yes. That's the whole point of a burn address - to have an address where no one is able to spend the coins.
Of course, in theory, someone could find a private key that corresponds to a burn address, but the probability is so small that it is effectively 0.


text:
Off chain transactions
How can you create an off chain transaction and broadcast it?  Is it the same as creating a non standard transaction or different?

An off chain transaction is a change in BTC ownership (a payment) that is not a Bitcoin transaction (not just an invalid or non-standard one; it's something unrelated entirely).
If I hand you a private key, or a wallet file, or a physical coin, that is an off chain transaction.
If you and I both have accounts on a USDBTC exchange, and you're buying BTC and I'm selling BTC, the exchange engine may match up our trades, and deduct my BTC balance (and increase my USD balance) while simultaneously incrementing your BTC balance (while decreasing your USD balance). Your total BTC ownership increased, but not transaction was visible on the chain (it's all internally inside the exchange's account database). This is an off chain transaction.
Layer 2 payment channel systems like Lightning work by having a pre-negotiated but unbroadcast Bitcoin transaction that pays two participants. These two participants can choose to renegotiate how much goes to each, which mechanisms built in to prevent either from broadcasting an old version. The updating of that transaction as an off-chain transaction. The result of many combined payments may end up on the chain as an on-chain transaction, but the individual payments are not. This makes it an off chain transactions.
Arguably, if I hand you a signed piece of paper saying I owe you 0.01 BTC, that too is an off chain transaction.
The name is confusing, as it conflates the word "transaction" (in the sense of blockchain transaction) with "transaction" (in the general financial meaning of a transfer of ownership).

An off chain transaction is not the same as a nonstandard transaction.
An off chain transaction implies ownership of a coin being changed, without publishing a transaction to the bitcoin blockchain. There are a couple of ways to accomplish this, such as using a trusted third party to store and distribute funds (eg an exchange service), or by using a product such as the OpenDime (which allows you to transfer ownership of private keys, which are provably not backed up).
To contrast, a nonstandard transaction is a transaction that is valid, but does not follow the 'standard' rules imposed by most full nodes. Nonstandard transactions are published to the blockchain.
You may be interested in this question, my answer there highlights different ways that bitcoin ownership can change without publishing a transaction to the blockchain.


text:
How was a pay to ip transaction created?
How can you create a pay to ip transaction or is this not possible with the current client?
If so why was it disabled?

Pay-to-IP transactions were removed in 0.8.0.
Such transactions worked by essentially contacting the IP address you were sending to, seeing if it was running Bitcoin, and receiving a public key from the Bitcoin node there to pay to.
However, this wasn't very secure. There was no way to prove that the response was coming from the IP address you tried to contact - It was trivial for a man-in-the-middle attack to simply hijack your request and reply with their own bitcoin public key, effectively stealing the payment.
Here is the BitcoinTalk discussion discussing the PR linked above and the removal, with the thought process at play.


text:
Can you broadcast a segwit transaction using a non segwit node?
If non segwit nodes view segwit transactions as anyone can spend ,why can't you broadcast a segwit transaction using them?

Segwit was designed in such a way that segwit transactions, after removing the witness, are valid but non-standard to old nodes.
This guarantees that old nodes won't reject such transactions when they're seen in blocks, but still won't be relayed or mined by old software.

Does this apply to all SegWit transactions, including P2SH-nested types?

@ChrisChen Indeed. All segwit spends violate the "clean stack" standardness rule implemented by most pre-segwit Bitcoin Core versions.


text:
Does bitcoin still concatenate the locking and unlocking script and execute?
Does bitcoin still concatenate the locking and unlocking scripts and execute in order to validate transaction or is validation done another way?

Does bitcoin still concatenate the locking and unlocking scripts

No. This bug was fixed many years ago. ScriptSig and ScriptPubkey executed separately, not concatenated to each other

Does any cryptocurrency still do it besides bitcoin?

No, but you are welcome to create such bogus coin :) There are millions of bugs you can do yourself and/or find on github


text:
How do exchanges automatically forward deposited bitcoin?
Most crypto exchanges have some sort of buffer address (unique for every person) where you deposit your bitcoin and then this is sent over to their main wallet and your account is credited with the amount you deposited. How does this work?

Generally, the exchange will use a full node that is continuously checking the network for received transactions. Once it detects a transaction has been made to your deposit address it waits for the transaction to be confirmed, then it will credit you the balance. This data is stored in a private database managed by the exchange where they keep track of each user's balance. The bitcoins you deposited are then either pooled to pay for someone else's withdrawals or sent to a cold wallet (an air-gapped device that is not connected to internet) where they are stored securely if they're not going to be used in the near future.

This wasn't really my question. I'm asking how they forward the deposit from the deposit address to the address owned by exchange.

Sorry for not answering your question properly,
The deposit address IS owned by the exchange, depending on the exchange it may be common to find that the funds you sent to your deposit address are later directly used, together with other user's funds, to pay someone else who you don't know. Though some exchanges may use an extra hop where they send the funds to an address dedicated to pool them, it's important to note that the bitcoin protocol allows spending from many previous outputs at once, so this hop is not requiered and the exchange can merge the funds all while doing the transaction.

I know its owned by the exchange. How do they forward it to their "main" account tho?

Bitcoin has no accounts, only addresses and they're just an interface thing to make it easier for users to specify the destination of a transaction. Transactions work by spending UTXOs (Unspent Transaction Outputs). This is what I was trying to explain, the exchange doesn't need to pool balances into any "main" account, they can directly pool the output of your deposit transaction as ready to be spent and used to pay someone. Though some exchanges may use some kind of internal database that organizes outputs in accounts, this is irrelevant to the bitcoin protocol.

Most exchanges pool their currencies. If not BTC then for others. Check any exchange and see for yourself.


text:
How doesn't the most powerful miner get the block reward everytime?
My understanding is that miners try several values for a nonce until the hash of the nonce and the data is of a certain format. However assuming that all miners start the nonce counter from the same number then that would mean the miner that is going to find the correct nonce is simply the one that can hash the fastest. Which should always be the same miner. What am I missing here?

There are many many many fast miners. There is no uber miner.

Mining is like a lottery. If rich people buys 60% of the tickets, they would win on average 60% of the time, they wouldn't win always.

You need to build a valid block. That means that you need a valid nonce. If you start searching from 0, 1, 2, 3... or wheather you try random numbers is irrelevant.
The hash is also not only dependant from the nonce. If you start at 0 and another miner starts at 0 and you both have a different set of transactions in the block, you need to finde different nonces.


text:
How to retrieve readable private key from bitcoinjs-lib
I'm still new to bitcoin and experimenting a lot with bitcoinjs-lib in JavaScript.
How do I create a readable string from a private key?
This is my current setup:
      const seed = bip39.mnemonicToSeed(seedPhrase)
      const bitcoinNetwork = bitcoin.networks.testnet
      const hdMaster = bitcoin.bip32.fromSeed(seed, bitcoinNetwork) // seed from above
      const keyPair = hdMaster.derivePath('m/0')
      // try to get private key as readable string
      const privateKeyBuffer = Buffer.from(keyPair.privateKey)
      const privateKey = privateKeyBuffer.toString('utf8')
      console.log('privateKey → ', privateKey)
      // fail to get private key as readable string
      const { address } = bitcoin.payments.p2pkh({ pubkey: keyPair.publicKey })

any ideas for me?

use .toString('hex') instead.

Don't export / import individual private keys when you are using BIP32 HD keys. IT IS DANGEROUS.
.toString('hex') and .toString('base64') are readable string representations of Buffers, but no crypto apps use them. The accepted format for individual private keys are WIF. But like I said, IF YOU ARE USING HD KEYS, ONLY STORE/EXPORT/IMPORT YOUR SEEDPHRASE OR AN XPUB.

Source: From this Github thread.


text:
Why are blocks in a permissioned blockchain linked together?
My question: Do the blocks in a blockchain without proof-of-work (i.e. a permissioned blockchain) have to be linked together via a cryptographic hash?
Longer version of my question:
(Please correct me if some of my remarks contain mistakes)
The blocks of a blockchain are linked to each other so that after proof-of-work their content cannot be easily faked, right? If several new blocks were created on top of a block which contains my transaction, I can be pretty sure that I'm on the longest blockchain and my transaction can't be faked (i.e. the double spending problem is solved).
However, in a permissioned blockchain there's no proof of work. As far as I know, in permissioned blockchains agreement on the longest chain (i.e. consensus) is reached by having a majority of blockchain participants agree on the longest chain. But since there's no proof-of-work, 51% attacks (pretending to be the longest blockchain while containing blocks with tampered transactions) are much easier to achieve, or am I wrong?
So why would you need to add a hash of the preceding block to a new block in a permissioned blockchain since there's no proof of work and thus linking the blocks in this manner does not provide any help to solve the double spending problem?

I think you're mistaking PoW for a mechanism that guarantees the chain's correctness, rather than just a means for finding consensus.
A blockchain (without PoW) is just an ordered list of batched updates to a database.
PoW is one mechanism to guarantee that everyone eventually ends up on the same chain, but it doesn't guarantee that this chain is valid. Validity is enforced because non-miner full nodes actually validate all the operations in the chain to determine correctness.
If you remove PoW, you need another mechanism to obtain consensus. One way of doing that is having the block by signed by a trusted set of nodes. This means you're trusting those nodes to not sign multiple conflicting chains. However, it does not necessarily mean you trust them to assert validity of that chain. You can still have full nodes that verify that the chain being created is valid. In order to do that, your set of updates must be identifiable. A hash chain is one way of doing that.
If you're going to fully trust whatever your trusted parties sign without any validation, just use a replicated database instead. What a blockchain adds is simply a mechanism for identifying and auditing updates.
To be clear, I don't think there are all that many uses for permissioned blockchain technology, and a lot of the claimed advantages are hype. However, some of them will likely turn out to be a modern instantiation of BFT systems with auditability, and be boring but quite useful.

Thanks for clarifying that consensus about the longest chain and validity are two different things!
However, I’m not sure I understood your sentence „In order to do that, your set of updates must be identifiable. A hash chain is one way of doing that.“ correctly. - Do you mean that e.g. each new block has to be signed by the miner and this signature verified, so that no alien miner could fake blocks? - But why would one need a hash chain for that? Or in other words, why would you need to store a record of the validation into the blockchain?

In order to verify that a batch of updates ("a block") is valid, you need to know what state it builds on. A very reasonable way to do so is to include the hash of the previous update that led to that state. Otherwise you could for example miss one update due to being offline, download the latest block, and find it invalid due to e.g. spending a coin that doesn't exist in your eyes (because it was created in a block that you missed).

I think this question does not have a good answer, because there is no strict, general definition of what a 'permissioned blockchain' is.
In general, if only certain participants are allowed to extend the chain's history, then trust must be placed in those participants to not alter the record. Less participants means more trust must be placed in each individual participant.
What a participant (or a colluding majority of participants) can alter will depend on the rules of the specific system in question. A cryptography-enforced block ordering may or may not be alterable, it depends on the protocol.

So why would you need to add a hash of the preceding block to a new block in a permissioned blockchain since there's no proof of work and thus linking the blocks in this manner does not provide any help to solve the double spending problem?

Doing so establishes an ordered history for transactions, but in a permissioned system you're still going to need to trust that the permissioned participants are not acting maliciously. So the use of a 'blockchain'-type architecture does not bring about the benefits normally seen with an actual blockchain system (like bitcoin), at least not for users (since the user needs to trust the permissioned actors). Perhaps an argument could be made that a blockchain architecture could allow the permissioned participants to interact in a less trusted way, but again that does not quite capture the user-facing benefits that a blockchain network normally provides.


text:
Are UTXOs signed with a private key?
Are UTXOs signed by a private key?
I'm trying to understand exactly which parts of Bitcoin use public and private keys. You need a private key in order to generate transaction output, and to create a transaction that uses those outputs, but I'm not sure what happens in the middle.
My current guess is that they aren't signed. The transactions generating the UTXOs are signed, and the block containing the transactions can be validated and then traced back to the miner. It doesn't seem necessary to sign the UTXOs, and even if we wanted to, the only private key available would be the miner's.

That's correct.
UTXOs are just entries with the following fields:

txid of the transaction that created it
output position in that transaction that created this output
the output itself (consisting of scriptPubKey and amount)
the height of the block that created this output (needed for relative locktime checking, see BIP112)


text:
What previously existing technologies made Bitcoin possible?
When watching a tutorial, they mentioned that Bitcoin is based off 4 or 5 technologies that existed for at least a decade before Bitcoin. Satoshi Nakamoto was the first person to combine them all into a digital currency.
I'm aware of at least some of them - SHA-256, ECDSA, peer-to-peer distributed ledger - but want to try and understand all of them.
What other technologies underpin Bitcoin?

Arvind Narayanan and Jeremy Clark wrote an excellent paper about that: Bitcoin's Academic Pedigree. I recommend reading the paper in full, but the following briefly summarizes the paper's content.
Linked timestamping/verifiable logs
Bitcoin borrows the blockchain data structure from Bayer, Haber, and Stornetta which described a very similar data structure in context of a timestamping service in the 1990s. The original also makes use of Merkle trees already. The authors suggested regularly publishing the "blockheaders" in a newspaper.
Byzantine fault tolerance
Byzantine Fault Tolerance (BFT) describes a distributed network to converge on a shared state even when their are malicious or unstable actors. While the whitepaper doesn't cite a specific source, Nakamoto described Bitcoin as a practical solution to the Byzantine Generals' Problem (a challenge that requires BFT), thus indirectly referencing an enormous body of scientific work done in the 1980s through 2000s. While not mentioned, peer-to-peer networks like BitTorrent (2001) must have served as an inspiration.
Proof of work
Originally proposed as a means to deter spam, sybil attacks, and denial of service attacks, PoW failed adoption in those applications due to the stark difference of computing power in various devices.
Digital cash
Digital Cash refers to a form of money that can be electronically transferred but exhibits characteristics of cash: final settlement, peer-to-peer transferability, resistance to forging, and transactional privacy. HashCash, b-money, and bit gold discussed ideas of using puzzle solutions as cash. None of these earlier projects had a solution for the doublespending problem, though. DigiCash solved the doublespending problem but required a central operator to issue new tokens.
Public keys as identies
While public-key cryptography was discovered in the 70s, the use of public keys as pseudonymous identities was first described by David Chaum in 1981. Since anyone can generate their own key pair, public-key cryptography lends itself to self-certified authentication.
Secret sauce: Putting it all together
Prior solutions for Byzantine Fault Tolerance required some level of honest behavior from which Nakamoto sidestepped partially by introducing economic incentives and assuming self-interest. Instead of publishing their chain in the newspaper as Bayer, Haber, and Stornetta floated, Nakamoto uses a peer-to-peer network and proof of work to decentrally author the timestamping data structure. The resulting shared groundtruth solves the doublespending problem that remained unsolved for HashCash, b-money, and bit gold.
The rewards for block authors incentivize collaborative convergent participation, ensuring both BFT but also distributing initial funds to the network. As the network identities derive from self-generated private keys, the peer-to-peer network can be open and permissionless—sidestepping the single points of failure of trusted third parties that caused issues for many previous digital cash projects.

Follow up question - I'm trying to understand what prevents participants from issuing fake UTXOs. Nakamoto pointed to Proof of Work and the longest chain to solve the Byzantine Generals Problem, but from what I understand transactions are also verified by nodes. What tech should I research to understand how nodes create consensus on valid transactions?

Every transaction id is unique, and therefore each transaction is output uniquely traceable. Synchronizing nodes simply keep the full list of all unspent transaction outputs. You can read more on https://bitcoin.stackexchange.com/a/56589/5406, https://bitcoin.stackexchange.com/q/95564/5406, https://bitcoin.stackexchange.com/q/12427/5406

Sorry - I'm phrasing my question poorly. I agree that UTXOs are traceable from the Genesis block. What I'd like to understand is the system that nodes use to get consensus on what valid transactions to put in the mempool. I'll start by going through these Python implementations of Bitcoin nodes, but if there are specific technical subjects I can research that would be very helpful (compared to reading code) https://bitcoin.stackexchange.com/questions/41682/a-complete-bitcoin-implementation-in-python

The mempool holds unconfirmed transactions. Every node has its own mempool and they don't need to match. They usually overlap almost completely, though. The transactions in the mempool must be valid, and cannot be in conflict with other transactions in the mempool, but only the transactions included in blocks are what everyone converges on and becomes part of the consensus.


text:
how to see my private key bye decrypted wallet.dat
How to decrypted my wallet.dat (Yes, I know the password) so i can see my private key? if anyone can help there is 1 LTC for them

If this was Bitcoin core you would enter the password and use dumpwallet from the console or cli

why is my comment deleted/ disabled?

You're posting comments as answers. They're being converted to actual comments (which you don't have permission to create yourself, presumably).

@RedGrittyBrick: you may have misunderstood me i want to decrypted wallet.dat file not using the console

Hello Al Mos, it seemed that you were replying to Luca Blight, but you created an answer post instead of commenting on Luca's answer. If you were trying to respond to RedGrittyBrick's comment on your question, you should have added a comment there. --Answers on Stackexchange compete with each other they don't have a fixed order, so using them to respond to previous posts will not work.

Please check out our [tour] to understand how this site works.

If you are using Bitcoin Core:
1 - Go to window > console
2 - Type listunspent
3 - You will get a list of addresses with the spendable amount
4 - Copy one of those addresses
5 - Type dumpprivkey pasteYourAddressHere

you may have misunderstood me i want to decrypted wallet.dat file not using the console

First you need to know which software this wallet.dat comes from, many softwares use different types of wallet.dat.


text:
wallet.dat corrupt. Try using the wallet tool bitcoin-wallet to salvage or restoring a backup
I'm trying to restore an old wallet, using bitcoin-qt 0.21 but I'm getting the following error on startup: wallet.dat corrupt. Try using the wallet tool bitcoin-wallet to salvage or restoring a backup
What tool is this? I have tried googling it. Thanks!

bitcoin-wallet is a tool distributed along with Bitcoin Core. The package contains several binaries, including bitcoin-qt, bitcoind, bitcoin-cli, but also a few stand-alone tools like bitcoin-tx and bitcoin-wallet.


text:
Computta stealing bitcoin and behave like its nothing
Mining with https://computta.com/ I had balance of 0.54+ mBTC, every hour i checked and i have written them down in my book.
Suddenly since this week they made my computer balance 0.529 mBTC but on my web-site account my balance remaining  0.53 mBTC
I reported them and they pretending to be like its nothing no issue at all but i used 7 days 24/7 to make it and now on the fly they steal my bitcoin.
What to do in such case? stop using them? suppose i had large balance 1100 mBTC and they did the same i cant claim it back anymore it would be stolen.

My advice is if you are going to get involved with money that does not require a third party to trust, don't actually trust a third party. There's nothing we can do for a scam unless they help you or you bring them to court

they steal my bitcoin. What to do in such case?

When someone steals something from you, the appropriate response is to report it to the police. You'll have to provide evidence that a crime has occurred.
If the evidence is not the sort that would be credible in a court of law, it may not be possible to progress this.
If the criminal is outside the jurisdiction of your police, and the sums involved are low, it may be difficult to progress this.

Due Diligence
Part of the intent of cryptocurrencies is to create currencies that are outside the control of governments. A corollary to this is that you need to be diligent when assessing the trustworthiness of cryptocurrency organisations
See

Computta Review: Hand over the keys to your PC to persons unknown
Computta – Smart Cryptocurrency Mining PC Application Software?

Computta is made by a company named Computta Networks LLC. The corporation started appearing online in July 2017. They claim to be registered in Delaware.
There’s virtually no information about the company available online. In fact, one of the first results that pops up when you search for Computta Networks LLC on Google is this page on RealScam.com, where the website is identified as a likely scam.
There’s also the problem that Computta’s testimonials are accompanied with stock photos that have been taken from other websites. They do not appear to be legitimate testimonials.


text:
How do i cash the money from my NiceHash account to Paypal or European Bank account?
In my nicehash i have balance of 100 Euro.
How do i cash the 100 Euro now to Paypal or my European bank account or do receive via Westurn Union?

From https://www.nicehash.com/help/how-can-you-use-earned-bitcoins:

Once you receive your payments in your personal wallet, you can:

transfer Bitcoins to Bitwala and pay your bills in EUR or transfer EUR to your bank account
use online exchanges like Coinbase, Bitstamp, Kraken and others to directly exchange bitcoins to EUR or USD and then transfer EUR or
  USD to your bank account
also buy various goods directly with bitcoins, for example, computer equipment in CaseKing computer shop
  transfer bitcoins to EUR or USD on pre-paid Credit Cards via CoinsBank service

Of course, there are a lot of other options on how to use, spend and
  convert your Bitcoins, simply search the Web for other options or ask
  your retail/online shop whether they accept bitcoins as a payment
  option.

I need easy/quick/safe reliable bitcoin to CASH options so that all my currency stays as bitcoin and from there i pay to paypal, ebay, amazon or banks

All those parties you mention, i.e. "paypal, ebay, amazon or banks" do not deal directly with Bitcoin or any other cryptocurrency. So you would need some kind of interface. StackExchange doesn't like direct product recommendations, but it may make sense that you start looking for a prepaid VISA or Mastercard which can be loaded with Bitcoins. Please be careful as there has been strange things going on with this kind of cards in the past. You will find several offers using Google.

I signed up Bitwala but they are not available yet to get started. So i should try Coinbase right? But i will have to pay exchange transfer rates?


text:
How transactions will take place once all the blocks have been mined
I understand there can be maximum of 21M BTC. Also, new BTC are added into system as a reward of mining blocks. So is there any hardcap on the number of blocks that can be mined? Or there is no limit on blocks to be mined, instead, there would be no rewards for mining after 21M coins?
Let's say there is a cap on blocks, how the new transactions can be verified after 21M mined coins?

Or there is no limit on blocks to be mined, instead, there would be no rewards for mining after 21M coins?

This is correct, although the miners still get all the transaction fees as reward, there is just no block reward like there is now with 12.5 BTC


text:
Is every bitcoin transaction (eventualy) validated by every miner?
I can see that my bitcoin transfers becomes real when my exchange detects 2 or more confirmations.
I believe each confirmation is a validation. Am I correct? If so, How many confirmations will have my transaction? As many as miners does exist? If not, how many?

Welcome to Bitcoin.SE!
Each node validates all transactions in every block and, every block in its entirety.
The confirmation count is how many blocks are mined on top of the block that includes your transaction. A new block is mined every ten minutes on average.

Say your transaction is in block number n; as more and more proof of work is added on top of the block n (by means of block mined on top of it) the probability that someone proposes a longer chain that does not contain your transaction at block height n decreases as blocks are mined on top of block n.
This is due to the fact that whoever wants to propose an alternative chain that differs from the active chain starting from height n, has to provide valid proofs of work for every block starting from n, before someone further extends the active chain, which happens on average every 10 minutes.
Each confirmation is a valid block mined on top of block n; confirmations make what is written in n harder and harder to change as time passes.

It is a representation of the number of blocks present in the blockchain which are now accepted by the by the network since the block that includes the transaction. There is not actual authority to determine whether the transactions is valid or invalid, so the recipient uses number of confirmations as a way of protecting against double-spend attacks.
The network always try to extent the blockchain, so that some chain may win. The deeper the transaction is in the chain, the higher the chance it will win because the network tries very hard not to duplicate efforts. It is mandatory for the attacker to match the power of entire bitcoin network to get along with the block generation, as the difficulty level keeps on increasing with the increase in the block else it will get difficult for the hacker to forge the transaction.
Technically, the more nodes to confirm the transaction, the safer you are from any hacker. So feel please when more than 2 miners verify your transaction. As the more verifications, the higher are the chances that transaction will remain in the public hash chain rather than a conflicting transaction if there was one.


text:
Generate cryptocurrency addresses on server
I want to generate cryptocurrency addresses (e.g. for top 10 cryptocurrencies on CoinMarketCap) on my server and be able to send transactions when deposit arrives. Can I do that with CLIs or there is another/better way to do that? Or maybe there is a service that is suitable for cryptocurrency address generation?

yes you will need a bitcoin core installed and fully synced and after you have that, you can use this php library to help you (i used this before i recommended to you):
https://github.com/aceat64/EasyBitcoin-PHP

Thank you for the reply. Is there any library that supports BTC, BTH, ETH and other coins from Top 10?

Yes this can also do it as long as the coin has json-rpc. but cons is that you will need all core synced which takes up alot of disk space


text:
New address generation on exchange services
Services like ShapeShift generate new addresses for each transaction. It is not clear how to they do that. I didn't find any API that supports address generation for such a big amount of coins like on ShapeShift. Or maybe these guys use some crypto exchange to generate the addresses.
How can I implement address generation function?

you may want to look at the way, how HD wallets do key handling. You could define extended private and public keys and try to go from there...

There are a lot of online tools to generate bitcoin addresses and some of them have APIs. For example Blockcypher
's one.
But usually such services have their own full node which manages their wallet. In such case they'll generate new addresses using bitcoin-cli tool.
$ bitcoin-cli help getnewaddress
getnewaddress ( "account" )

Returns a new Bitcoin address for receiving payments.
If 'account' is specified (DEPRECATED), it is added to the address
book
so payments received with the address will be credited to 'account'.

Arguments:
1. "account"        (string, optional) DEPRECATED. The account name for the address to be linked to. If not provided, the default account "" is used. It can also be set to the empty string "" to represent the default account. The account does not need to exist, it will be created if there is no account by the given name.

Result:
"address"    (string) The new bitcoin address

Examples:
> bitcoin-cli getnewaddress
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getnewaddress", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/

As to the other coins, I bet they have alike tools, but looks like there is no "silver bullet" API for every coin out there.
And if you are going to handle big amount of coins, you, maybe, don't want to generate addresses via the third-party services.


text:
How do services like ShapeShift generate new addresses
I found that ShapeShift generates new address for each transaction. How do they do that? Is it possible to exchange the coins in the same manner as ShapeShift do, but without the creation of new address?

This is called Hierarchical Deterministic key derivation.
New public keys, and by extension Bitcoin addresses, can be generated from a set of parent public keys. This way, the front-end of Shape-shift never needs to communicate with a "hot wallet" and can generate a new set of addresses for every user transaction.
To spend from these addresses, Shapeshift simply derives the corresponding private key (server-side) from its parent private keys.
Child private and public keys can be derived in parallel (front/back-ends), maintaining a fire-wall between them.
Intro to HD Wallets
For details on HD key derivation works, check a recent talk of mine at Scaling Bitcoin: https://youtu.be/OVvue2dXkJo
Slides here: https://teachbitcoin.github.io/wallets.html#/5

I am not aware on the way how shapeshift has implemented their solution, maybe a developer from this company reads this forum and can provide an  answer.
Generally there are two approaches for different addresses on a webpage:
1.) the background is running a bitcoin core node (or any other wallet software which fits their needs), and everytime a user visits the webpage, the server asks the node for "getnewaddress", and displays this to the browser. There might then be some logic in their back office app, to convert/move values to the correct "other chain".
2.) usage of HD keys. HD keys come with xpriv and xpub, which can generate a set of 2^31 keys from a single privkey. There is a slight problem with this, these HD keys cannot be handed out easily to the customer, cause they are derived from a single privkey. But for the shape shift service it is more than sufficient, cause they use "one-time" addresses...

And how could I generate HD keys? Do I need a full cryptocurrency node for this?

not sure about your question... generally you don't need a full node. It  depends what you have. You can code your own library (assuming there is some programming experience), you could use libraries (need to do a search, they are available for many programming languages), you can use ready made tools (another search in the forum) or at the end even use Electrum wallet, and type the key's letters and numbers by hand ... well, not really... I recommend to read Andreas' book "Mastering Bitcoin", chapter 5 on wallets, which helps to understand how these keys are generated.

Yes, I could generate an HD wallet with Electrum, or Trezor and many other hot/cold wallets. But I need to create the addresses on a server and be able to perform transactions. So these wallets are not suitable for this case.

They do not necessarily need to use an HD wallet nor do they need to use Bitcoin Core. They can just be generating random private keys as is the traditional way to generate private keys using any software that they want.


text:
Post Pow hash verification
I am unable to understand how a PoW(Proof of work ) activity takes extensive computation  but the corresponding hash message verification of the final result is quick and easy.
What process and flow takes place in the final hash verification ?
Any guidance .

The final hash verification is the same one done in mining. The difference it's that is done just once, while in mining it's done lots of times, until the miner finds a hash on the target difficult.
It's similar to checking a database of pictures of stores to tell if there's one that's a pizzeria. You look to hundreds, even thousands of random pictures, your eyes and brain working on what you see to tell what the picture is, until you find a pizzeria. Then you post it online and people see it and they say, 'yeah, it's a pizzeria'. They only had to look at a single picture to validate it.


text:
Why can't I bumpfee a tx with 19 ancestors?
I have a wallet in bitcoin core 25.0 where one transaction has 19 ancestors and no descendants (the transaction IDs are obfuscated by A-T, where T is the most recent):
$ bitcoin-cli getmempoolancestors T
[
  "L",
  "J",
  "S",
  "H",
  "O",
  "R",
  "M",
  "K",
  "I",
  "Q",
  "G",
  "F",
  "P",
  "B",
  "D",
  "N",
  "A",
  "E",
  "C"
]
$ bitcoin-cli getmempooldescendants T
[
]

When I try to bumpfee that transaction, I get the following error:
$ bitcoin-cli bumpfee T '{"fee_rate": 418}'
error code: -4
error message:
Unable to create transaction. Transaction has too long of a mempool chain

This seems odd to me. The limit of 25 unconfirmed transactions is definitely not exceeded here. There is also package size restriction (max 101kvB), but that's not exceeded either. Here's the mempoolentry:
$ bitcoin-cli getmempoolentry T
{
  "vsize": 144,
  "weight": 573,
  "time": 1701581567,
  "height": 819521,
  "descendantcount": 1,
  "descendantsize": 144,
  "ancestorcount": 20,
  "ancestorsize": 2842,
  "wtxid": "<wtxid of T>",
  "fees": {
    "base": 0.00011887,
    "modified": 0.00011887,
    "ancestor": 0.00150381,
    "descendant": 0.00011887
  },
  "depends": [
    "S"
  ],
  "spentby": [
  ],
  "bip125-replaceable": true,
  "unbroadcast": false
}

ancestorcount including the bumped tx itself is clearly 20, and the ancestor size is 2842 vB. Why can't I bumpfee this transaction?

There is a limit on the number of descendants a transaction which gets updated during an RBF may have. This limit is of 25 descendant, accounting for the transaction itself. (There is also a limit on the number of ancestor, and on the accumulated size of descendants and ancestors.)
If you try to RBF a transaction which only has 19 ancestors, it can happen that any of those 19 ancestors itself has 25 descendants. In this case the replacement will be rejected.
From the data you provided in private, i counted that the transaction A from OP didn't have 19 descendants as you expected but actually 25 (accounting for itself). This is because some of its descendants not only had one output spent by your transaction chain, but also another output spent by another transaction. That explains why your bumpfee attempt got rejected.


text:
Why won't bumpfee accept my new fee_rate?
On a regtest node, I'm trying to bumpfee a transaction that have 1 sat/vB fee. I want to bump the fee to 2 sat/vB, but the wallet complains, saying:
error code: -8
error message:
Insufficient total fee 0.00000282, must be at least 0.00000846 (oldFee 0.00000141 + incrementalFee 0.00000705)

Why is this happening? The new fee pays exactly as much as is required to get this transaction into my mempool, right? I've tested on Bitcoin Core 25.0 and 26.0. The replacement transaction would be of the same size as the replaced transaction.
Here's the full context:
$ ./bitcoin-cli -regtest -rpcwallet=wallet445305173 listunspent 0
[
  {
    "txid": "33a1ec4bc9eaee66dfb2ae81fadf17bcdf29110643c3775cd462e40148e8e5f1",
    "vout": 0,
    "address": "bcrt1q0c46f338s4gnr34trjae8nu5ckhafj2l4l5nne",
    "label": "",
    "scriptPubKey": "00147e2ba4c627855131c6ab1cbb93cf94c5afd4c95f",
    "amount": 1.00000000,
    "confirmations": 1,
    "spendable": true,
    "solvable": true,
    "desc": "wpkh([c4093544/84h/1h/0h/0/0]02f32280b38e94d3028e2005a398941093c23794637734f2927a6d856e1d13ff8d)#82m64c6a",
    "parent_descs": [
      "wpkh(tpubD6NzVbkrYhZ4WMWdeCvc7DuoqY7wX6dsJEf8SZwrb7jqNUsgtHb3AkeDnYBcRRVNj6jm1RXT6J2R22X6TsKgnjJbQRWs4ZGRsbdjF65Zg9T/84h/1h/0h/0/*)#e3dfjhyk"
    ],
    "safe": true
  }
]

$ ./bitcoin-cli -regtest -rpcwallet=miner getnewaddress
bcrt1qk02jcchycn947u6e8a740yatrs8cnsxc7qa3zx

$ ./bitcoin-cli -regtest -rpcwallet=wallet445305173 sendtoaddress bcrt1qk02jcchycn947u6e8a740yatrs8cnsxc7qa3zx 0.001
9139f8b08b687b946dee4d24be88bb8cc90294629b206c01b04a34f8ce32b1ab

$ ./bitcoin-cli -regtest -rpcwallet=wallet445305173 gettransaction 9139f8b08b687b946dee4d24be88bb8cc90294629b206c01b04a34f8ce32b1ab
{
  "amount": -0.00100000,
  "fee": -0.00000141,
  "confirmations": 0,
  "trusted": true,
  "txid": "9139f8b08b687b946dee4d24be88bb8cc90294629b206c01b04a34f8ce32b1ab",
  "wtxid": "41190c475d2098d8a77863262bf117f657f9c07d6ccd1485bb5fc83de1624a72",
  "walletconflicts": [
  ],
  "time": 1702286813,
  "timereceived": 1702286813,
  "bip125-replaceable": "yes",
  "details": [
    {
      "address": "bcrt1qk02jcchycn947u6e8a740yatrs8cnsxc7qa3zx",
      "category": "send",
      "amount": -0.00100000,
      "vout": 1,
      "fee": -0.00000141,
      "abandoned": false
    }
  ],
  "hex": "02000000000101f1e5e84801e462d45c77c343061129dfbc17dffa81aeb2df66eeeac94beca1330000000000fdffffff02d359f40500000000160014b7dbc2759724bd6495735648cee0aa50e3b2f838a086010000000000160014b3d52c6
2e4c4cb5f73593f7d5793ab1c0f89c0d8024730440220652a34522866a176e6dd343fbf91ad8c002967b90a7496fdf0946c534e9695a90220140527500b84a9bd52684145dd622c49960d52f79b64fb98d93021dfc083d543012102f32280b38e94d302
8e2005a398941093c23794637734f2927a6d856e1d13ff8d59020000",
  "lastprocessedblock": {
    "hash": "44d959c6cb011430d752f16692d464dff2bdabb8a9baa5cb7e65f6675f1e42cd",
    "height": 601
  }
}

$ ./bitcoin-cli -regtest -rpcwallet=wallet445305173 bumpfee 9139f8b08b687b946dee4d24be88bb8cc90294629b206c01b04a34f8ce32b1ab '{"fee_rate": 2}'
error code: -8
error message:
Insufficient total fee 0.00000282, must be at least 0.00000846 (oldFee 0.00000141 + incrementalFee 0.00000705)

$ ./bitcoin-cli -regtest -rpcwallet=wallet445305173 bumpfee 9139f8b08b687b946dee4d24be88bb8cc90294629b206c01b04a34f8ce32b1ab '{"fee_rate": 5}'
error code: -8
error message:
Insufficient total fee 0.00000705, must be at least 0.00000846 (oldFee 0.00000141 + incrementalFee 0.00000705)

$ ./bitcoin-cli -regtest -rpcwallet=wallet445305173 bumpfee 9139f8b08b687b946dee4d24be88bb8cc90294629b206c01b04a34f8ce32b1ab '{"fee_rate": 6}'
{
  "txid": "74bcd6e58e5b7f7b364d6ebd055c9e6212a88cafeb0bf035c26545bc3a21b1a5",
  "origfee": 0.00000141,
  "fee": 0.00000846,
  "errors": [
  ]
}

$ ./bitcoin-cli -regtest getnetworkinfo
{
  "version": 260000,
  "subversion": "/Satoshi:26.0.0/",
  ...
  "relayfee": 0.00001000,
  "incrementalfee": 0.00001000,
  ...
}

bumpfee requires 6x original fee, instead of 2x original fee.
If I create a psbt of the same transaction with 2 sat/vB feerate it works fine. E.g. createpsbt, walletprocesspsbt, finalizepsbt, sendrawtransaction.

Maybe bumpfee is simply creating a 705 vbytes replacement transaction? But idk why, since walletprocesspsbt doesn't..

I have only one UTXO in the wallet, so I don't see how it could create anything bigger than 141 vB. The output from my bumpfee command stated that I try to set a fee of 282 sats, which indicates that the new tx is in fact 141 vB.

Hmm. In this case the 705 incremental fee indicates it's using 5sat/vb as incremental feerate.

Which.. Is exactly the default used by the wallet! Mystery solved. Can't wait for the next episode of "Kalle and Antoine explore the behaviour of Bitcoin Core's bumpfee".

The bumpfee command uses a fixed 5sat/vb incremental feerate when creating replacement transactions. This is why it's saying the fee should be at least 846 sats for bumping your 141 vbytes transaction. It's accounting for the original 141 sats fee, plus 5 * 141 sats for the incremental fee.
As Kalle points out in the comments the documentation for bumpfee is misleading. It states:

At a minimum, the new fee rate must be high enough to pay an additional new relay fee (incrementalfee returned by getnetworkinfo) to enter the node's mempool.

But the feerate needs to be 5 times that for the command to succeed.

From the bumpfee doc: "At a minimum, the new fee rate must be high enough to pay an additional new relay fee (incrementalfee returned by getnetworkinfo) to enter the node's mempool.". This seems to contradict what you say, see the output of getnetworkinfo in my question.

Yes, the doc is wrong. The incremental fee used by the wallet is (5 times) higher than the one used by the mempool.

Gah! Thanks for the answer. Maybe update the answer to mention the incorrect documentation.

Hmm i was editing my answer but since it says "at a minimum" it's only misleading not technically wrong right?

Right, but very misleading. I'm filing an isuue on github anyway.

https://github.com/bitcoin/bitcoin/issues/29053

The 1sat/vB is indeed what you need to enter the mempool. The wallet's 5sat/vB increase is not always necessary or sufficient to meet Rule 4. Sounds like in this situation, the wallet's incremental feerate is much higher than necessary.
For "why are there 2 different incremental feerates?" Since Rule 4 is applied using the size of the replacement transaction, and we don't know that before we're finished building it, AFAIK the approach for the wallet is "eh just shoot 5sat/vB higher and we should probably meet Rule 4." It's much easier to target a feerate than to target a fee that depends on the size of your resulting tx.


text:
Why do miners validate transactions?
It seems that if most transactions are valid, a miner could save a little time and increase its chance of mining a block by not validating.  Is the reason that there are enough invalid transactions to make this an ineffective strategy, because the risk of having mined an invalid block is not worth the time savings?
I have a similar question about verifying/validating blocks, and maybe the answer is similar, too.

While invalid transactions are uncommon, transaction and block validation is a minuscule effort in comparison to the effort expended on mining that can be easily parallelized with the mining process.
The cost of including an invalid transaction or building on top of an invalid block, however, is potentially losing a block reward and mining on top of an invalid chain-tip until the remaining network pulls ahead and you reorganize to the valid chain-tip.
Note, that something similar already happened in the past: On 2015-07-04 when BIP66 activated, roughly half the mining power was split off due to "SPV mining" without checking block validity, even though they were signaling support for the activation of BIP66. The result were two invalid chain-tips of six and three blocks.

Why do miners validate transactions?

Because they want to create blocks, that contain valid transactions. After sending the block to the network, other nodes verify the block for correctness. If the block is rejected, the possibility to "win" is lost...

invalid transactions

you seem to postulate, that there are many invalid transactions. I am not convinced, this is the case. Yes, everyone can send a tx to the network. This tx would end up in any of the approx. 10.000 nodes. There are far less miners, so the full nodes already filter invalid transactions. A particular wallet is usually not connected directly to a miner. As full nodes validate transactions, the probability that a full node forwards a wrong tx is minimal. If a full node does, there is other nodes, which verify the tx as well, and if this nodes sends faulty tx, he gets ignored by other nodes. I just wanted to state this, to make clear, that malicious crafted transactions have a hard time to make it through to a miner. And yes, the miner himself can generate false transactions, but then again looses all possibilities to win a block.

Is the reason that there are enough invalid transactions to make this
  an ineffective strategy, because the risk of having mined an invalid
  block is not worth the time savings?

As I tried to explain before, invalid tx are not a common thing. Miners strategy is currently to win a block, maybe with some fees along. So each miner can decide individually, what he puts as "winning strategy". There are often blocks with zero transactions, or very view tx, cause currently the block reward is much higher than fees. This seems to be a valid strategy, not the invalid tx.

That's my point. If invalid transactions are uncommon, why do miners bother to validate?  Sure, sometimes a miner would mine an invalid block and lose the reward, but most of the time the miner would save time and still mine a valid block.

@MRP "uncommon" is the wrong metric to consider. They are uncommon because miners validate. If miners didn't, it'd be trivial to cause them to lose money by creating invalid transactions deliberately.

The miners validate transactions to secure the network and in turn get rewarded for doing so. The miners are what prevent double spending and actually deliver the payments through the blockchain. Without the miners I could sent the same bitcoin to as many different people as I want. Who would stop me? .. well the miners would.
An example is a 51% attack. If a mining group or a miner gets 51% control of the mining power in the network this can happen:
"The attackers would be able to prevent new transactions from gaining confirmations, allowing them to halt payments between some or all users. They would also be able to reverse transactions that were completed while they were in control of the network, meaning they could double-spend coins."


text:
Bitcoin Cash API similar to BlockCypher
Is there any Bitcoin Cash API that has similar features as BlockCypher? Important is the ability to create new addresses and create transactions.

You should check out https://www.bitgo.com it's great for Bitcoin, Bitcoin cash, etc. Great APIs. Make sure you review developer docs for v2 apis.

blocktrail.com is nice but be careful as it'll be integrated into BTC.com

Following are API’s, that provide wallet creation, transaction
  management, withdrawing coin etc. Each one have their own
  specifications.

https://block.io/docs/basic
Widely used
Multi signed i.e. Require two signatures for all withdrawals.
Currently we can trade only Bitcoin, Litecoin and Dogecoin.
We can create address
Send coins to other wallets as well as Withdraw coins etc
Get last/All/specific address transactions
Good Documentation.
https://accounts.blockcypher.com/
Multi featured
Currently we can trade only Bitcoin, Litecoin and Dogecoin.
We can create address
Send coins to other wallets as well as Withdraw coins etc
Get last/All/specific address transactions
Good Documentation
More Features avaible than above. i.e Analytics, events & hooks for notifications much more
https://github.com/Overtorment/Cashier-BTC
Self-hosted Node.js Bitcoin payment gateway.
Open Source & free.
Less Documented hence Hard to implement
No 3rd parties (works though Bitcoin Core node)
Transactions are signed locally. No private keys leak
How much coin we can trade: Working on it.
May be payable in future.
Battle-tested in production
SegWit compatible : Working on it.
https://chain.com/
Specially built for Financial services
Permissioned network access
Multi-signature accounts: Secure, multi-asset account management for individuals, businesses, and institutions
Instant settlement
Transaction privacy
Awesomely documented.
How much coin we can trade: Working on it.
https://github.com/bitpay/insight/
Provided by well known BitPAy
Descent Documented
Multi-signature accounts: Secure, multi-asset account management for individuals, businesses, and institutions
Fees : Working on it.
How much coin we can trade: Working on it.
Secure


text:
Different balances in API block explorers for BTC
BTC.com block explorer shows bigger balance than for example Insight or Blockchair. For example: https://btc.com/1FLDCfr9iG7n6bAdGsqBXmhaLgC4aSze72
https://insight.bitpay.com/address/1FLDCfr9iG7n6bAdGsqBXmhaLgC4aSze72 https://blockchair.com/bitcoin/address/1FLDCfr9iG7n6bAdGsqBXmhaLgC4aSze72
Why BTC.com's result is different?

These explorers are running different code, and without seeing the code is very difficult to know why they are different

Just check on our explorer
https://bitaps.com/1FLDCfr9iG7n6bAdGsqBXmhaLgC4aSze72
Correct balance is 1.41297880BTC
You can also turn timeline mode and check balance change after each transaction


text:
Ripple testnet explorer
This is Ripple main Explorer. But where can i find the transactions ledger from wallets on Ripple testnet.

I've been working hands-on on creating a payment gateway solution for the ripple currency. I this https://developers.ripple.com/xrp-test-net-faucet.html this is where you can find the test net and develop on it.

There is a variant of viewing the transaction history at a certain address:
http://ripplerm.github.io/ripple-wallet/
Dont forget to switch the network to the test in the upper left corner. Good luck =)

There is a testnet XRP explorer:
https://test.bithomp.com/explorer
Mainnet XRP explorer: https://bithomp.com/explorer

Here you can paste the transaction hash and get the transaction details of Testnet transactions.

https://testnet.xrpl.org/

This may not be as user friendly as you would want/expect, but you can hit rippled APIs with curl.  Here's a way to look up a specific transaction on test net, if you know the transaction's hash:
curl -s -X POST "https://s.altnet.rippletest.net:51234" -d @- <<-END
{
    "method": "tx",
    "params": [{ "transaction": "<hash>" }]
}
END

Substitute <hash> above with your hash.
Follow a similar pattern to build "account_info" or "account_tx" commands.  Etc...

Is https://ripple.com/build/xrp-test-net/ not what you are looking for?

The asker is looking for a transaction history explorer, and there doesn't seem to be one at that URL.


text:
How Multisignature Wallets are affected in case of a hard-fork?
In an event of forking, are there any special circumstances involving multisig wallets? I am asking this because Coinbase says they do not support forks and multisig wallets?
Below is a quote from the Coinbase site:

Multisig vaults were originally introduced as a way for customers to
  manage their private keys and control their own security while still
  using the Coinbase interface. However, as Bitcoin forks become more
  commonplace, the complexity of multisig vaults makes it infeasible to
  support multisig withdrawals for each additional forked asset.

No, multisig addresses are not special in any way that is effected by forks. They are just like any other output on the blockchain.
The reason it is hard for Coinbase is because they need to implement support for signing and creating transactions for those forks which requires significant engineering effort. It's the same reason that they don't support every fork in the normal Coinbase wallet - it is difficult to implement such support so they won't.


text:
Bittrex API market history -- interpreting OrderType
The Bittrex API has a request to get the market history:

https://bittrex.com/api/v1.1/public/getmarkethistory?market=BTC-DOGE

which gives a response containing the following fields:

"Id"
"TimeStamp"
"Quantity"
"Price"
"Total"
"FillType"
"OrderType"

"OrderType" can be one of "BUY" or "SELL". What does this refer to?
Let's assume it has a value of "SELL". Does this mean:

The person who initially placed the order was selling (Seller is Maker).
The person who closed the order was selling (Seller is Taker)

You almost have it!
BUY means that the order was the consequence of someone buying at the ask price, as opposed to creating an order at a lower-than-market price.
SELL means that the order was the consequence of someone selling at the bid price, as opposed to creating an order at a higher-than-market price.


text:
Why is increasing block size in the Bitcoin network considered to decrease security?
I have been doing some research on the Bitcoin Cash hard fork and the main contention of increasing the block size appears to be the possibility of less security on the network. How does an increased block size result in a less secure network?

Generally speaking, a larger block leads to more computational resources (tx validation, bandwidth, storage, memory) required for each person who wishes to validate newly confirmed transactions.

Higher validation cost lead end-users to rely on/trust
centralised services to "validate" their transactions.
Larger blocks require more time to propagate in the network,
increasing pooling pressures for more centralized mining-pools.

The lower the validation cost, the more we can push validation to the edge (end-user) of the network, the more decentralisation we can achieve. Decentralisation is ultimately the source of security, as it is harder for an external force to attack.

Also, off-chain transactions can be made for much cheaper without sacrificing security. No need to store the history of daily coffee purchases of everybody on all Bitcoin nodes in the network.

Well - there is a security sacrifice to be 100% fair. There is no insurance against failing to respond to a cheating counter-party in payment channels. The required vigilance is an additional risk that a confirmed transaction does not have.

Can you explain in more detail? Also, even a confirmed transaction still has the small risk of a reorg. There are even users who choose to accept transactions before they have one confirmation (cringe).

That is true. A user can choose how much security he requires from a confirmed transaction before accepting it. Yet a commitment tx, even though it is valid, has not even been confirmed, which is why I mean it has less security. So a lightning payment (a new commitment tx) cannot have the same security as a confirmed tx with a confirmation depth. The entire payment channel capacity amount is in fact still “pending” confirmation.

Right, thanks. It's important that it remain easy to broadcast the state of the channel at any time.

Sorry. I meant “A user can choose how much security [he/she] requires...”