text:
Can I find a bitcoin wallet from an address directly from blockchain data? (not website)
For example
https://www.walletexplorer.com/wallet/03457b955f9c055c/addresses shows all the addresses linked to wallet 03457b955f
How do they do that?
Thank you !!

https://en.bitcoin.it/wiki/Privacy#Blockchain_attacks_on_privacy many techniques, mostly "common input"

Just to make sure you're aware: there is no such thing as a unique wallet identifier in Bitcoin. The association between addresses and wallets is a guess by that website, and the 03457b955f is an identifier chosen by walletexplorer.com for the observed cluster of (presumed related) addresses.

How do they do that?

See https://www.walletexplorer.com/info

What is on this site?
WalletExplorer.com is Bitcoin blockchain explorer, with two additional features:

it merges addresses together, if WalletExplorer thinks that they are part of the same wallet
wallet can have name

How wallets are computed? When are addresses merged together?
Just a basic algorithm is used to determine wallet addresses. Addresses are merged together, if they are co-spent in one transaction. So if addresses A and B are co-spent in transaction T1, and addresses B and C are co-spent in transaction T2, all addresses A, B and C will be part of one wallet.
Sometimes, an address belongs to some service but it was never co-spent with others. Then that address stays unnamed. It is typically more often at addresses with higher amount (as there is no need to co-spending).
How are names discovered?
In most of the cases, I registered to service, made transaction(s) and saw which wallet bitcoins were merged with, or from which wallet it was withdrawn.
There is probably no easier way how to discover names other than this.
Please note that the name database is not updated, so it does not contain newer exchanges (or newer wallets of existing exchanges)


text:
How to convert difficulty from `mining.set_difficulty` message for Litecoin?
I'm trying to determine how to properly convert difficulty from a mining.set_difficulty message to target for Litecoin, similar to how it's done for Bitcoin.
For Bitcoin, the process I use is as follows:

I start with the genesis nbits value: 0x1d00ffff
I convert this to the max target:
0x00000000ffff0000000000000000000000000000000000000000000000000000

Then, I calculate the target using this formula:
target = max_target / difficulty

For example, with a difficulty of 524288, the target becomes:
target = max_target / 524288 = 0x0000000000001fffe00000000000000000000000000000000000000000000000

Now, I'm trying to apply a similar algorithm to Litecoin. Here's what I have so far:

The genesis nbits for Litecoin is 0x1e0ffff0
I convert this to the same max target as in Bitcoin:
0x00000ffff0000000000000000000000000000000000000000000000000000000

I use the formula max_target / 524288, which results in the same target as in Bitcoin:
target = 0x0000000001fffe00000000000000000000000000000000000000000000000000

However, when I perform this calculation and compare it with the shares I receive on the pool side, I find that shares have a higher target, such as:
0x0000000005713013fcbf8bf0dcc329a5f56b856c2dbe64603e34b47169eaaa50 (pow)
>
0x0000000001fffe00000000000000000000000000000000000000000000000000 (target)

Upon further investigation, I found this code snippet, which introduces a coefficient of 65535:
if (opt_algo == ALGO_SCRYPT)
    diff_to_target(work->target, sctx->job.diff / 65536.0);
else
    diff_to_target(work->target, sctx->job.diff);

This suggests that the target for Litecoin should be multiplied by 65535. My question is:

Should the target be scaled by 65535 in the same way?
Why is this adjustment necessary for Scrypt (Litecoin) but not for Bitcoin?
How do I correctly calculate the target for Litecoin to avoid getting shares higher than the calculated target?

Any guidance on this would be appreciated!

source: Stack Exchange

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

sort: votes


text:
Does anyone know why so many burn transactions are being sent to address 1111111111111111111114oLvT2 currently?
The number of incoming transactions to 1111111111111111111114oLvT2 in the past 24 hours is enormous...
Edit: they are OP_RETURN txns, but each has two identical outputs to that burn address; I don't get it.

It’s stacks: https://bitcoin.stackexchange.com/q/70241/5406

Does this answer your question? What's with this address 1111111111111111111114oLvT2?

Do apps on Stacks have unique, fixed addresses like erc20 contracts? Becuase most txns seem to be sent from just a few addresses, some of which have had 10k+ btc pass through...
https://mempool.space/address/18hofVCQv8cMDpqDNqSXyrUDffq7MKLxiu
https://mempool.space/address/1Di1YoMov6Ua3gPedfQz7TkP6iTLqbPUzi
https://mempool.space/address/13ogR3PP3dUNbP62CBaxtdygYjPzUc17sb

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


text:
Bare minimum system requirements for Core
The Bitcoin.org page on Bitcoin Core Requirements and Warnings lists three types of setups:

#
Type
Disk Gb
Gb / mo
RAM Mb
Windows

1
Bare Min (default)
350
8 / 150
512
7/8.x

2
Bare Min (custom)
5
5 / 0.3
256
7/8.x

3
Minimum Recommended
350
15 / 150
1,024
7/8.x/10

I don't think I want to dedicate 1/3 Tb to running Bitcoin Core, so #1 and #3 are impractical, but #2 seems feasible. However, there are two problems with #2:

The download specs for all three types have the footnote, "Plus a one-time 340 GB download the first time you start Bitcoin Core." That seems like a contradiction of the requirement of only 5 Gb of disk space for type #2. So which of the following is correct?

The footnote should not appear in type #2, or
The Disk space spec of 5 Gb is wrong, or
I'm allowed to discard the initial download after starting Core.

The spec says type #2 is not compatible with Windows 10. Is that true?

Summary: For the Bare Minimum (With Custom Settings), i.e., type #2 above:

Is the spec of 5 Gb minimum disk space correct? How is that not a contradiction of the footnote stating a requirement of an initial download of 340 Gb?
Is it compatible with Windows 10, even though that OS is not listed in the spec?

Pull request opened about the typo - https://github.com/bitcoin-dot-org/Bitcoin.org/pull/3561

The 350 GB (approximately) mentioned at the page - is the "whole blockhain". In order to run full node (like Bitcoin Core) the client must rerun full blockchain. After dowloading it, almost all blocks can be removed (this is called pruning is settings) which results to reducing storage capacity to 5 GB.
So, you are right with the guess #3 - your are allowed to discard initial download after starting Bitcoin Core.
Regarding the second question. Yes, it is compatible with Windows 10. Why win10 is mentioned in confusing way - I don't know. Perhaps it was meant that win10 is recommened but later someone added win7 and win8. Bitcoind requirements are in the documentation, so if you have any doubts you can look at spec.
Edit: there is already pull request to clarify documentation.

Bare min setup uses the bitcoin's feature called pruning.
In prune mode your node will sync the whole blockchain (the data on the website is a bit outdated, it's closer to 400GB now), but it has to start from block 0. If you set your pruning to 5 GB, it will start syncing from block 0 till the 5GB limit and after that will still sync (so your internet connection has to go through whole 400GB) but will delete older blocks. So at the end your history will be only latest few dozen k blocks. But your node in the process will "parse" all the 400+ GB of data, just keeping latest 5GB at a time.
Yes, bitcoind/bitcoinqt works on windows 10 :)

So does that mean that I start with a download of 400 Gb, but almost all of it will be deleted by the pruning process?

And when you say I have to go through the whole 400 Gb, is that once a day? Seems like that would blow way past limits set by my ISP. So using Core would seem to be only suitable for people with massive bandwidth available. Is that right?

@NewSites you will download 400GB in total (not every day) and you don’t need a hard drive with 400GB free space, only as much as your pruning is set to.

@NewSites you'll download 400Gb just once (first time) and if you'd run the node on a daily basis, you'll just download the update - so only the newest blocks - about 145Mb a day.

@TonySanak , so what do you mean by, "your internet connection has to go through whole 400GB"?


text:
Is it possible to use BitGo's wallet with other software (Electrum or else), what is the used derivation path?
BitGo wallets are based on a 2-of-3 multi-signature, the end user have access to:
- Public key (xpub) of the 3rd signer (as the main wallet xpub)
- Native Segwit (Bech32), bc1... addresses to receive BTC assets
- Private key/seed (BIP39) of the 1st signer (and public key xpub as well)
- Private key/seed (BIP39) of the 2nd signer (and public key xpub as well)

Seeds can be converted to private key here, BitGo provide it's own recovery-tool (it's debug infos can be used to get the xpub keys of the first and second signer).
Public xpub keys can be converted to Zpub (p2wsh) here or with Electrum with the command ./electrum.AppImage convert_xkey 'xpub...' 'p2wsh' --offline (Electrum and xpub-converter uses those specs and derivations paths).
While it is possible to import the BitGo wallet into Electrum without error, Electrum never generate the same receiving address as BitGo, Following this and this bitcointalk's forum threads:
1. What is the derivation path used by BitGo Bitcoin wallet?
2. Is it possible to use BitGo wallet in any other software like Electrum or else?
Other related QA: 1, 2, 3, (note that I am using Bitgo's wallet through Bitwala)

may be the answer reside in the source code of BitGoJS

It may be better to reach out to BitGo directly about this.

According to answers given to other users, BitGo's support just redirect users to the recovery tool and does not communicate on such information. This is paradoxal while they claim using a non-custodial wallet and are using opensource softwares (but are not widely transparent on what they do/use)

Have you tried using a bigo wallet with some btc in it; importing the 2 signer private keys into your other software; then attempt to spend some of the btc from the wallet in the new software? It's possible that this may still work, if bitgo is simply using a different derived address from the same script (similar to compressed/uncompressed addresses for p2pkh wallets).

It would probably be easier to figure it out if you sent a transaction from BitGo, then you can see the exact redeem script of the transaction, which will include the public keys and the order they're listed in. Then you just have to figure out the derivation path of those public keys from the zpubs and zprvs you have.

Looking at the BitGoJS code it would appear that the derivation path is m/0/0/derivationChain/*.
Looking further, the derivationChain seems to be a code depending on the address type:
    [0, UnspentType.p2sh, Purpose.external],
    [10, UnspentType.p2shP2wsh, Purpose.external],
    [20, UnspentType.p2wsh, Purpose.external],

    [1, UnspentType.p2sh, Purpose.internal],
    [11, UnspentType.p2shP2wsh, Purpose.internal],
    [21, UnspentType.p2wsh, Purpose.internal],


text:
New download of bitcoin core v28.0, how to use blocks which have already been downloaded to my machine?
I have just downloaded bitcoin core v28.0 from bitcoincore.org.
However, the new version of bitcoin core is not taking the copy of the blockchain which is on my machine from bitcoin core 27 and 26.
How can I get v28.0 to use the blockchain data which is already on my machine from versions 27 and 26?
I've been playing around with the bitcoin.conf datadir to no success.

The GUI status bar says: Number of Blocks left: Unknown. Synching headers (241603, 28.7%)... Last block time Sat Apr 6 3013 Progress 1.46%
$ bitcoin-cli getblockchaininfo
{
 "chain": "main",
 "blocks": 237023,
 "headers": 241603,
 "bestblockhash": "000000000000002a9ea9139b011c1643d65fc5dca4af9c87bd09ad3d29c4025c",
 "difficulty": 11187257.46136079,
 "time": 1369030450,
 "mediantime": 1369026380,
 "verificationprogress": 0.0165687083236199,
 "initialblockdownload": true,
 "chainwork": "0000000000000000000000000000000000000000000000439abfc36db3cce000",
 "size_on_disk": 10021451300,
 "pruned": false,
 "warnings": ""
}

What operating system are you using?

I am using the Ubuntu OS v22.04

Hello anyone know

You should not need to do anything. Just installing the new version should make it use the block and validation data you already have. If it doesn't, that is a bug, but we will need a lot more information about what is going on to figure out what is wrong. Where did you install Bitcoin Core? What appears in debug.log? What happens if you run the old version again?

Bitcoin Core is in the home directory. debug.log is a huge file with the date and time of each block since 2012.

If I run the old version it too starts to download the blockchain from block 0.

How can I get [the current version] to use the blockchain data which is already on my machine from [prior versions]

I believe the appropriate process is something like this:

Close bitcoin-qt, bitcoind etc. Make backups. Check backups.
Locate the Blockchain data.
E.g sudo find / -name blk00000.dat
Configure Bitcoin Core to use that location. vi $HOME/.bitcoin/bitcoin.conf if directory isn't in default location where bitcoin looks. See datadir and walletdir
If needed, move a copy of important wallet.dat to appropriate location. See existing guidance.

For comparison, here is the response for getblockchaininfo on a Bitcoin node that hasn't been run for 6 months on a PC that has inadequate resources (100% disk usage)
{
  "chain": "main",
  "blocks": 849345,
  "headers": 869149,
  "bestblockhash": "0000000000000000000090dd75955aeb49fb6a51f259f3d6ee3c9639ce241ced",
  "difficulty": 83675262295059.91,
  "time": 1719257861,
  "mediantime": 1719254246,
  "verificationprogress": 0.9679465468853898,
  "initialblockdownload": true,
  "chainwork": "0000000000000000000000000000000000000000803db1ef35254b7ce5b55f8a",
  "size_on_disk": 660000239919,
  "pruned": false,
  "warnings": ""
}

I think a key thing here is the number of blocks the program knows of.
This PC has a blocks folder with about 615 GB of data in it and a chainstate folder with under 12 GB of data in it.
Your equivalent information does support your conclusion that the program isn't seeing all your data. Maybe it has logged a reason why it isn't using all the data (e.g. some error message concerning a block file?)
In the file debug.log I see
2024-11-05T18:22:16Z Bitcoin Core version v24.0.1 (release build)
2024-11-05T18:22:16Z InitParameterInteraction: parameter interaction: -listen=0 -> setting -upnp=0
2024-11-05T18:22:16Z InitParameterInteraction: parameter interaction: -listen=0 -> setting -natpmp=0
2024-11-05T18:22:16Z InitParameterInteraction: parameter interaction: -listen=0 -> setting -discover=0
2024-11-05T18:22:16Z InitParameterInteraction: parameter interaction: -listen=0 -> setting -listenonion=0
2024-11-05T18:22:16Z InitParameterInteraction: parameter interaction: -listen=0 -> setting -i2pacceptincoming=0
...
2024-11-05T18:22:25Z Default data directory XXXXXXX/Bitcoin
2024-11-05T18:22:25Z Using data directory XXXXXXX/Bitcoin
2024-11-05T18:22:25Z Config file: XXXXXXX/Bitcoin\bitcoin.conf
...
2024-11-05T18:22:47Z LoadBlockIndexDB: last block file = 4309
2024-11-05T18:22:48Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=84, size=126890608, heights=845620...845702, time=2024-05-29...2024-05-29)
2024-11-05T18:22:48Z Checking all blk files are present...
...

Note the last few lines above. You'll have to search for the latest occurrence of these to check that the program is actually looking in the place you instructed.
Your debug.log should show you where Bitcoin core thinks your data is located and this should help you work out what is happening.
There may be other error messages earlier in the debug.log that explain why the program needed to do what it is doing.

I ran sudo find / -name blk00000.dat and it found the data directory in home/mickin/.bitcoin/blocks/blk00000.dat

How many blk*.dat files are in there and what are their creation dates? If that is the only directory containing a blk00000.dat and few other blk0*.dat all dated recently, it means your original block data has perhaps all been deleted or was originally elsewhere (perhaps on a drive since removed/disconnected/unplugged)

There are 4216 blk*.dat files in home/.bitcoin/blocks. There are also 4216 rev.dat files in the folder. These files were all last modified since between 31 Mar and 16 May of this year. I did not delete any block data and did not use any other drives.

When I scan my HDD it says that i am using 590GB of my HDD storage.

What does the GUI status bar say? (e.g. "Synchronising Headers (99.9%), 5 weeks behind") and in Window/Console, the CLI or using RPC API, what is the response to command getblockchaininfo?

The GUI status bar says: Number of Blocks left: Unknown. Synching headers (241603, 28.7%)...       Last block time Sat Apr 6 3013                 Progress 1.46%

mickin@mickin-IdeaPad-3-15IAU7:~$ bitcoin-cli getblockchaininfo
{
"chain": "main",
"blocks": 237023,
"headers": 241603,
"bestblockhash": "000000000000002a9ea9139b011c1643d65fc5dca4af9c87bd09ad3d29c4025c",
"difficulty": 11187257.46136079,
"time": 1369030450,
"mediantime": 1369026380,
"verificationprogress": 0.0165687083236199,
"initialblockdownload": true,
"chainwork": "0000000000000000000000000000000000000000000000439abfc36db3cce000",
"size_on_disk": 10021451300,
"pruned": false,
"warnings": ""
}

I added that info to your question.

I have updated my answer, hopefully you find something there that helps you.

These are the first two entries in debug.log: =206354 version=0x00000001 log2_work=68.965798 tx=8561394 date='2012-11-04T01:33:25Z' progress=0.007771 cache=15.8MiB(126352txo)
2024-10-26T17:44:19Z UpdateTip: new best=00000000000001922ffa0ca8429e87844ee626db025992228ee7b0e839101b20 height=206355 version=0x00000001 log2_work=68.965833 tx=8561460 date='2012-11-04T01:27:14Z' progress=0.007771 cache=15.8MiB(126441txo)       I didn't notice anything else in the file that would give me any clues as to what is gone wrong here.

When I set datadir=<Home/.bitcoin/blocks> in bitcoin.conf file I get the following error: Error: Error reading configuration file: specified data directory "<Home/.bitcoin/blocks>" does not exist.

$HOME (not  Home) is an environment-variable whose value is probably something like /home/eoin depending on your operating system, distribution, its configuration and your chosen user-ID. AFAIK the datadir value should not include the /blocks subdirectory, you should point at the one above that. In other words, I'd expect  datadir=/home/eoin/.bitcoin/ would be the default location if, for example, you use Ubuntu 24 with no customisation and your user-ID is eoin.  Also you shouldn't have <> around the value. See https://github.com/bitcoin/bitcoin/blob/master/doc/bitcoin-conf.md

I have updated the datadir for your changes above and it seems to accept it ok. Here is a screenshot of what I am seeing from bitcoin core 28.0 : https://ibb.co/Sdf9KGg

I played around with regtest, signet and testnet. Would this have moved the blockchain somewhere else?


text:
Why is this Ordinals transaction I sent wrong, can anyone help me?
let content_type = "text/plain;charset=utf-8";
    let body = Buffer.from("000");
    const inscription = {
      body,
      content_type,
    };
    const network = bitcoin.networks.testnet;

    const internalKey = bip32.fromSeed(rng(64), network);

    console.log("internalKey", internalKey)
    console.log("keyPair", keyPair)

    const hash_lock_keypair = toXOnly(internalKey.publicKey);

    const hash_lock_script = bitcoin.script.compile([
      hash_lock_keypair,
      bitcoin.opcodes.OP_CHECKSIG,
    ]);

    const p2pk_script_asm = `${toXOnly(keyPair.publicKey).toString('hex')} OP_CHECKSIG`;
    const p2pk_script = bitcoin.script.fromASM(p2pk_script_asm);

    let instructions = [
      bitcoin.opcodes.OP_FALSE,
      bitcoin.opcodes.OP_IF,
      Buffer.from("ord"),
      bitcoin.opcodes.OP_1,
      Buffer.from(inscription.content_type),
      bitcoin.opcodes.OP_0,
      Buffer.from(inscription.body),
      bitcoin.opcodes.OP_ENDIF
    ];

    const revealScript = bitcoin.script.compile(instructions);

    const revealScriptWithCheckSig = bitcoin.script.compile([
      hash_lock_script,
      revealScript,
    ]);

    const scriptTree = {
      output: revealScriptWithCheckSig,
    };

    const p2pk_redeem = {
      output: revealScriptWithCheckSig,
      redeemVersion: 192,
    };

    const p2pk_p2tr = bitcoin.payments.p2tr({
      internalPubkey: toXOnly(internalKey.publicKey),
      scriptTree,
      redeem: p2pk_redeem,
      network: network,
    });

    if (!p2pk_p2tr.output) {
      console.log("no output");
      return;
    }
    const script_addr = p2pk_p2tr.address ?? '';

    let utxos = await waitUntilUTXO(script_addr)
    const p2pk_psbt = new bitcoin.Psbt({ network: TESTNET });
    p2pk_psbt.addInput({
      hash: utxos[0].txid,
      index: utxos[0].vout,
      witnessUtxo: { value: utxos[0].value, script: p2pk_p2tr.output! },
      tapLeafScript: [
        {
          leafVersion: p2pk_redeem.redeemVersion,
          script: p2pk_redeem.output,
          controlBlock: p2pk_p2tr.witness![p2pk_p2tr.witness!.length - 1]
        }
      ]
    });

    p2pk_psbt.addOutput({
      address: "mohjSavDdQYHRYXcS3uS6ttaHP8amyvX78", // faucet address
      value: utxos[0].value - 150
    });
    p2pk_psbt.signInput(0, internalKey);
    p2pk_psbt.finalizeAllInputs();

    let tx = p2pk_psbt.extractTransaction();
    console.log(`Broadcasting Transaction Hex: ${tx.toHex()}`);
    let txid = await broadcast(tx.toHex());
    console.log(`Success! Txid is ${txid}`);

What do you mean by "wrong"? did it not compile? was there a compilation error? was there a run-time error? were the results different from what you expected in some way?

Showed this error bitcoinjs Can not sign for input #0 with the key, the bitcoinjs author said that I sent 2 already compiled scripts, this is wrong, but I don't know how to fix it, can you help me


text:
With the right technology, could the entire blockchain be rewritten?
Imagine that someone had access to an alien super computer such that they could mine any block in nanoseconds. At that point, could that person create a chain with the same BTC genesis block, generate any/all the blocks and transactions they want, to the point where this new chain had a greater cumulative difficulty than the current chain? And if that person did this, would the network accept this chain, thus erasing the past 10+ years of BTC?
I realize the computational power to do this is theoretical, like this question. However, I still wonder what, if any, safe guards are in place to prevent something like this?

In theory yes but the alien super computer would have to have hash power at an incredibly large multiple of the hash power pointed towards the Bitcoin blockchain today. According to blockchain.com today's network hash rate is around 130 million terahashes per second. If the alien super computer had more than this it could likely produce the next block with greater than 50 percent chance. However, to generate a new chain from genesis (over 10 years ago) it would need to create 10 years of blocks rather than just one. There are checkpoints in Bitcoin Core at historical intervals for when you are doing an initial block download but my understanding of these is that they don't overrule a new chain with a heavier accumulated proof of work even if it goes all the way back to genesis.


text:
Testnet Bitcoin Connection refused (111)
I have ah Raspberry and i will a BTC & Lightning node set up.
my bitcoin.conf
testnet=3
Bitcoind options
server=1
daemon=1
txindex=1
disablewallet=1
 Connection settings
rpcuser=raspibolt
rpcpassword=1212431
addnode=104.237.131.138
addnode=151.80.205.132
addnode=192.155.82.123
addnode=74.220.255.190
addnode=80.100.203.151
 Raspberry Pi optimizations
dbcache=100
maxorphantx=10
maxmempool=50
maxconnections=40
maxuploadtarget=5000

I have the addnode from this thread:
testnet3 node sync process is very slow
in the getnetworkinfo stands:
"version": 160000,
  "subversion": "/Satoshi:0.16.0/",
  "protocolversion": 70015,
  "localservices": "000000000000040d",
  "localrelay": true,
  "timeoffset": 0,
  "networkactive": true,
  "connections": 17,
  "networks":
  "warnings": "Warning: unknown new rules activated (versionbit 28)"

and in the debug log stands:
2018-04-24 17:39:51 connect() to 85.207.214.190:18333 failed after select(): Connection refused (111)
2018-04-24 17:38:16 connect() to [2001:470:c144:cafe::a]:18333 failed: Network is unreachable (101)

anyone have an idea where the error lies?
my testnet port: 18333 is open.
many thanks for the help!
regards

How much time did you give it? Could take a while until it finds peers on testnet. Both errors in your log aren't to uncommon.

several days. in the debug have i peer conection:
2018-04-24 18:41:24 New outbound peer connected: version: 70015, blocks=1294178, peer=10
2018-04-24 18:41:24 New outbound peer connected: version: 70015, blocks=1294178, peer=11
2018-04-24 18:41:25 New outbound peer connected: version: 70015, blocks=1294178, peer=12
can i switch to mainnet with this error? thank for you help :)

What error? Those debug.log lines are pretty standard to see, you'll see them as nodes that were online go offline. You have active connections, what is the problem?

the error in the debug.log irritated me. connect() to 115.68.73.83:18333 failed after select(): No route to host (113)
is this not bad?

Connection refused means there's something prevents reaching your server.
make sure that your firewall allowing connections to your port and try to add this line to your bitcoin config:
rpcallowip=0.0.0.0/0

i have add this line i n my config. in the debug log: 2018-04-25 05:11:38 Bound to [::]:18333
2018-04-25 05:11:38 Bound to 0.0.0.0:18333 but the Connection refused (111) are still there. my firewall I deactivated and the port 18333 is open. i have check under yougetsignal.com. in the debug.log have i updatetip: new best=00000000000000bd6da9189e324ba9852ea348c27f392b06a31429c783470020 height=1294289 version=0x20000000 log2_work=69.90756 tx=17934320 date='2018-04-25 05:20:26' progress=1.000000 cache=0.0MiB(356txo) Does not he get a connection to all nodes?

no dont do this, you will allow anyone to control your  client

bitcoin-cli  -rpcbind=0.0.0.0  it works like charm

This is a bad idea. Exposing your control interface to the world is never going to be secure.

Try to put rpcbind=0.0.0.0 in your bitcoin.conf file, it worked for me.

If you read this, don't do it. It might work but does expose a remote control of your node to [your local network and potentially] the world.

It is just a testnet.

I see everyone saying not to do this, but maybe you can also share the correct way to do it.

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


text:
How can a seed generate the wrong addresses?
What happened:
I created a wallet with my backup seed.
Then I sent to the generated wallet addresses:

BTC: bc1q70shswq68tx5p2e2mms34up5jpxeqfyzp3let6

Everything was ok and I had access to my funds in the Coinbase Wallet App.
Then I wanted to send BTC back to Coinbase to trade it.
But I got the same error as the guy on twitter: https://twitter.com/scottyboi78/status/1357378323270291457/photo/1
Calculating the fees was actually not the problem.
Then I restored the wallet with my recovery seed multiple times on my iPhone. I also tried Android Emulator with Android Studio and the official Coinbase Wallet App.
The result is always the same:

BTC: bc1qgdw5aqhd8uz7rl4cxkkk66u33swsnmzl6aeaqg (something wrong)

How can it happen that the SAME seed results in DIFFERENT addresses for BTC!
That should not be possible!
Please help me I lost all my money and it is there in the Blockchain but I can't access it because the seed generation has a bug (I think at least)!

Once you use a BTC receiving address once, any good wallet will not display the same address again; they'll display the next address in the chain (since your seed derives to a large chain of different addresses). The coins are not lost, your wallet balance should still be there, and the wallet will still track the old address, it just won't display the old addresses by default to discourage reuse of the old address.

But shouldn't the total balance in the blockhain explorer show the same amount on the new and the old address?

@Appyx No. Every address is separate, and the balance between addresses are separate too. Your wallet keeps track of all of this and adds it all up to show you your wallet balance, but the addresses are not inherently linked on the blockchain.

Ok thanks but why can't I see the funds then? Thy are obviously there on the blockchain.

It is difficult to tell you exactly what happened, but if you have the correct seed, you do not need to worry. Did you already send the btc to Coinbase? If you sent it to Coinbase to trade, then it obviously wont be in your wallet anymore.
If you didn't send to coinbase, then it is still sitting in the same address. You can ascertain this by looking up your address or txid in the blockchain. If you haven't sent the btc, then check your balance in the original Coinbase app. If it displays your balance, you're all good, but when you click "receive" it will generate a NEW address, not the same one every time (see @ieatpizza's answer).
If you don't see your balance in the app, you probably entered the wrong seed. Did you use a password in addition to the seed? Wallets allow users to add an extra (arbitrary) password to their seed phrase for uniqueness and extra security. In that case, loading the wallet from the seed phrase without the password will yield a valid, and empty wallet that is different from yours.
Things you can try:

download a different wallet, such as BlueWallet, and enter the seed there. Enter it with just the seed, and alternatively, with the seed AND your coinbase password appended to the end of the list.

Good luck!

But shouldn't the total balance in the blockhain explorer show the same amount on the new and the old address?

I'm still unsure what you're asking. Bitcoin is "in" an address until it's sent to another address. An address is like a bank account. When bitcoin is sent from one address to another, it is no longer in the sending address, so a block explorer will not show it there.


text:
How to recover blockchain.info wallet from 12-word passphrase and password
I have a 12 word passphrase and password from blockchain.info.  Trouble is that I can't remember the email I used.  Is there a way to retrieve the email with these two pieces of information?

There are two type of 12 word mnemonics from blockchain.info.
They use different word sets and have different meanings depending when they were created.
Pre 2015/2016 12 word seeds cointained your password to log in and were combined from a 50k plus word list. It was called the Legacy mnemonic.
Post 2015/2016 12 word list were combined from a 2048 word list and could be used to restore your public and private keys. These mnemonics are called HD
The blockchain uses separate links to check the validity depending if  you have have the Legacy or HD.
If you enter the list in the HD link and it says word not recognised it is most probably Legacy.
If you get checksum error only then most probably one of your words is misstyped, missspelled, wrong or missing. In that case it is possible to calculated the correct word but it is not an out of the box solution.

If you have your 12 words phrase from blockchain.info you can just restore your wallet, then you will use a new email and new password.
To restore your blockchain.info wallet:
1 - Go to: https://login.blockchain.com/#/login
2 - Click on Need some help?
3 - Click on Recover Funds
4 - Use your 12 word phrase, lowercase, with spaces between each word.

I have tried that link but it says invalid passphrase.  I know I copied the words down correctly.  Could it be from a wallet that doesn't exist anymore? These words are from back in 2013.

https://login.blockchain.com/wallet/forgot-password?guid=  My 12 word phrase worked on this website to retrieve my password.  Is there anyway to find out which email I used?

I am not familiar with this another link, you may need to contact blockchain.info support. But I guess your SEED is compatible with other BIP44/BIP39 bitcoin wallets. You can create an Electrum wallet using your SEED.

How would I go about doing that? By SEED do you mean the 12 word passphrase?

Yes, SEED is your 12 word passphrase. 1 - Download the Electrum wallet. 2 - go to create new wallet. 3 - Go with the option to standard wallet. 4 - Go with I already have a SEED. 5 - Click on options and check BIP39 SEED and enter with your SEED.

Thank you. Should this be able to show me if I have any bitcoins?

Yes, and then you can spend your Bitcoins from Electrum wallet.

Above answers are wrong. The blockchain.info 12 words are totally different from the 12 words used after 2015 when HD wallets were introduced and cannot be used with Electrum. Your blockchain.info 12 words were only used to store your password and use a totally different word list.


text:
How to recover Bitcoin files from 2011 that were erased using the Gutmann method
Всем доброго времени суток. С 2011 года на жестком диске хранился файл блок биткойн с наградой в 50 btc. Супруга по не знанию о криптовалюте удалила несколько папок включая и папку с файлом биткойн. При этом сказала что вроде была надпись о принадлежности данного продукта корпорации и будет удалено методом Гутмана. Есть ли возможность восстановить удаленный файл? Делал откат системы windows7.Папка появилась ,но файла нету(
Google translates this as

Good day. Since 2011, a bitcoin block file with a reward of 50 btc has been stored on the hard drive. A spouse who does not know about cryptocurrency deleted several folders including the folder with the bitcoin file. At the same time, she said that there seemed to be an inscription about the belonging of this product to the corporation and will be removed by the Gutman method. Is it possible to recover a deleted file? Did a rollback of the windows7 system. The folder appeared, but there is no file (

Any files erased using the Gutmann method cannot be recovered. The Gutmann method is actually overkill on modern disk drives.
At best, if empty space on the drive has not also been overwritten, you might recover fragments of data from previous versions of files or temporary files. If the files have not been used since 2011 this is extremely unlikely. The more use you make of the computer since the deletion, the less likely any recovery.
The best (and probably only) way to recover control over the money is to simply recreate the wallet using backups of the files or from the written copy of the private keys which you presumably made.


text:
Is it true that if I buy Bitcoin and plan to hold it for 10 years and sell, then Coinbase, Robinhood, or Gemini can prevent any theft?
It is said that Bitcoin can be subject to being stolen if I have it in my wallet on the smartphone, and is more secure in the Ledger hardware wallet.
However, if I buy it using Coinbase, Robinhood, or Gemini, and just hold it in my account for long term, such as 10 years, and suppose the account itself is not hacked, does that mean it is quite safe against theft?  (that is, not much different from some stocks in my Robinhood account?)

No. If your stock broker account (such as Robinhood) is hacked or stocks are transferred or sold from your account without your authorization, you have a lot of legal recourse and liability protection. Also, assuming the hacker manages to successfully complete a funds withdrawal from your stock broker account without you knowing (they'd be sending you tons of emails since they'd have to attach a bank account of their own to your account, verify it, etc...), the stock broker can dispute the transaction with the recipient bank and get the money back.
If you have BTC on an exchange account like Coinbase, once the BTC is sent, it is sent, and there is no way of recovering it. You're entirely at the mercy of the exchange if they'd want to pay you back out of their own money, and to my knowledge most exchanges generally do not. If you have any amount of BTC you are worried about losing, buy a hardware wallet.

Order of likelihood in which you will lose your funds:

The device you store your 2fa codes on gets compromised, effectively giving the hacker full access to your money
Trusted employee at the exchange steals users funds
Exchange gets hacked


text:
Is there any way to replace "move"?
The "move" command can't use because the account system is gone. So, Is there any way to manage my coins, address, wallet with no fee like "move"? Pleas let me know. :(

Yes, use separate wallets.
Bitcoin Core now supports loading multiple wallets simultaneously.
This isn't an exact replacement; you can't transfer between those wallets at zero cost. But on the other hand, the coins are actually physically separated, rather than being virtual bean counters within one wallet.

So I only have one way? You're just saying that it's a way to import all the private keys of all the addresses into your new wallet, right?

@ahwon: That's not how I interpreted Pieter's answer. Be careful importing private keys because you'll need to understand how that affects backup requirements and use of previously backed-up private keys or recovery phrases (for those wallet apps that support them). Getting this wrong can cause financial loss.  See GUI Support for Multiwallet Feature

@ahwon That's if you need a replacement at all. The alternative is implementing the account logic in your application. "accounts" in Bitcoin Core were just virtual counters: one wallet balance, with shared coins, but remembering how much of it belongs to which account. If you actually need something like that, you can also do the accounting outside of Bitcoin Core.

@ahwon And no, I'm talking about actually having distinct wallets (not just distinct addresses). Instead of having multiple accounts, you would create one wallet per account.

@PieterWuille  Now I fully understand. Thank you so much.


text:
Why do I need my password to generate a new receiving address in bitcoin-qt?
I heard that the wallet has 100 of the next receiving addresses already.  Shouldn't I be able to get one of those without unlocking it?

I believe you can. So long as the wallet has spare receiving addresses, you should be able to get one without supplying a password. If you can't, then it's probably out of spare receiving addresses.

The Bitcoin-Qt/bitcoind client will try to maintain a key pool of unused keys at an even size (default is 100 keys).  So each time you click "New key" it is going to try to add one to the key pool.
These keys in the key pool need to be encrypted, so your passphrase is required to do that.
The getnewaddress API call will, I believe, give you an address from the pool and if the wallet is locked, will simply deplete keys from the key pool without requiring the passphrase to replenish.

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


text:
Can too big hosted mining service be mitigated by allowing customers to choose mining pool?
Let's say a company is hosting mining hardware, either hosting customers' hardware or renting out the hashes produced by hardware owned by the company, or both. So the company is physically controlling the hardware.
What if this hashpower reaches a percentage of global hashpower that makes double-spends possible.
Can this be mitigated by the company allowing customers to select which mining pool they want their hardware/hashpower pointed at? For example through the company's web interface.

I think it primarily just gives you a false sense of security.
Let's say company XYZ is a hosted mining company like you describe. They grow so that they have 51% of the network's hash power. This may not be apparent on graphs like this one since it's spread among other (reasonably-sized) pools. However, since they are ultimately in control of the hardware, they can "go rogue" and make all of the hardware mine on their own pool. They now are able to execute double-spends, since they have 51% of the power. Note that this will not be a quiet thing: People will know that it has occurred.
A major reason why this probably wouldn't actually happen is that the company would be killing their golden goose. They could keep making money as a mining service, profiting from Bitcoin's success; instead they succeed in a few double-spends and then faith in Bitcoin is destroyed, and the value plummets. Or, since they no longer have cash inflow from new miners, they can't keep up with the rest of the network's improvements and they fall below 50% of the power. Either way, they're pretty much shot.
If we had a way to provably protect the hardware (via some private/public key system) so that the renters are really the ones that control what pool it points to (and the communication between the pool and the hardware was similarly tamper-proof), we could prevent this sort of attack completely. This would make the service more like a "customer buys some hardware, and we provide the space, power, and cooling in exchange for a fee" service than typical mining contracts.

It almost happened in january this year, by GHash. But that was a pool, not a company who rents out hardware. It is virtually impossible that 51% of the hashing power in hardware is controlled by one single company. It simply requires too much hardware/energy/cooling/space et cetera.
For what I understand, when you hire mining equipment or hashrate, you can always decide in which pool, and which coin you are going to mine. I never done it myself, but I read in fora that you can login via ssh, and run your mining command, and in that way select the pool you want.

GHash.io is intimately linked with Cex.io. I'd guess that a majority of GHash.io's power is due to people buying mining power through Cex.io, which puts it in the scope of this question. (and you can't, as far as I've seen, choose to point your power there to another pool, unless you buy hardware off of them and run it yourself)


text:
In a Blockchain.com wallet, Should I need to add the fees amount in the sent Bitcoin amount?
I need to send an exact amount from my Blockchain.com wallet, will the fee be taken the amount straight out of the amount being sent or do I need to add the fee to the amount being sent?
Example: Let's say the blockchain requests exactly 0.00075 bitcoins(30$), fee is 0.000055(2.20$). Do I send 0.0008 bitcoins(32.20$) or do I send 0.00075 and it takes the fee from main balance?
Thanks.

I would expect the wallet to look like the below image when you choose "send"

You set the fee separately by clicking the ▼ drop-down fee selector in the "Fee" section near the bottom of the screen just above the "Continue" button. So the amount you enter in the "BTC" section is the amount for the recipient excluding the transaction fee.
If your wallet looks different, you could contact customer support provided by the business that provides your wallet.


text:
What are the formats of a private key?
I copied my private key to a file and I can't remember what the string begins with. Can you help me by giving me the different types of private key: number of characters and and with which characters the private keys start. This is a bitcoin key from 2011/2012.

Does this answer your question? Why bitcoin private key WIF format always be started in K or L?

[what are] the different types of private key: number of characters and and with which characters the private keys start.

I have this note from https://en.bitcoin.it/wiki/List_of_address_prefixes

Decimal prefix
Hex
Example use
Leading symbol(s)
Example

128
80
Private key (WIF, uncompressed pubkey)
5
5Hwgr3u458GLafKBgxtssHSPqJnYoGrSzgQsPwLFhLNYskDPyyA

128
80
Private key (WIF, compressed pubkey)
K or L
L1aW4aubDFB7yfras2S1mN3bqg9nwySY8nkoLmJebSLD5BWv3ENZ

4 136 173 228
0488ADE4
BIP32 private key
xprv
xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63o StZzF93Y5wvzdUayhgkkFoicQZcP3y52uPPxFnfoLZB21Teqt1VvEHx

239
EF
Testnet Private key (WIF, uncompressed pubkey)
9
92Pg46rUhgTT7romnV7iGW6W1gbGdeezqdbJCzShkCsYNzyyNcc

239
EF
Testnet Private key (WIF, compressed pubkey)
c
cNJFgo1driFnPcBdBX8BrJrpxchBWXwXCvNH5SoSkdcF6JXXwHMm

4 53 131 148
04358394
Testnet BIP32 private key
tprv
tprv8ZgxMBicQKsPcsbCVeqqF1KVdH7gwDJbxbzpCxDUsoXHdb6SnTPY xdwSAKDC6KKJzv7khnNWRAJQsRA8BBQyiSfYnRt6zuu4vZQGKjeW4YF

The question is about private keys but only six rows in the answer refer to private keys.

@Pranab: Good point, others removed.

Ian's BIP39 site will show you an example of pretty much every coins private key format.  Technically these are WIF encoded private keys, but I assume these are what you mean.

https://iancoleman.io/bip39/


text:
import multisig wallet into bitcoin core, Vpub keys are not valid. how to?
I'm trying to import an HD multisig wallet created with Electrum into Bitcoin core v0.21.0.0.
I managed to do so with the fantastic cryptoadvance.specter server, but I also would like to import it using the standard bitcoin-cli commands.
This is what I managed to do so far, and it only works if I convert the pub keys Vpub Multi-signature P2WSH to tpub P2PKH, so for example:
Vpub5fRxfoprsHS9Vnhq1grZcJrWSRmSeBZbLCbnTJcvSDXr3xoBurx8MUt8UmHCsTVPXqk1rNpgt3X3KAvcJzCZvwn9yQymrWhwMJpEYysLqQV
becomes
tpubD8a2g9FwJxvC3c7YBvwvQL35Ph7jJTN4PnarTPCJAND6HGXSizk4ew1JxWKgqLXZuZSZ6KXZTFfgem2ar1itGNUywE1XJTY9azG4WBr25hn
then I can run this program and it seems to be working fine, unless it's not because the resulting addresses are very different. (the wallet created with Specter matches perfectly the one in Electrum, it finds the correct transactions as well)
#!/bin/sh

wallet=$1
pub1=$2
pub2=$3

echo "Making wallet '${wallet}' from ${pub1} ${pub2}"

rawdescriptor="wsh(sortedmulti(2,${pub1}/*,${pub2}/*))"
descriptor=$(bitcoin-cli getdescriptorinfo $rawdescriptor | jq -r '.descriptor')
bitcoin-cli deriveaddresses  ${descriptor} "[0,0]"

bitcoin-cli createwallet $wallet true
bitcoin-cli -rpcwallet=$1  importmulti '[{"desc": "'$descriptor'", "internal": false, "range": [0, 1000], "timestamp": 1609459200, "keypool": true, "watchonly": true, "label": "lol"}]' '{ "rescan": true}'
# bitcoin-cli -rpcwallet=$1 rescanblockchain

I can't use the Vpub keys because bitcoin-cli (v0.21.0.0) throws this message:
key 'vpub5UXsYa6RJKsn5DYT52PanEWhidjBRpt11vx7Y3MP4ShSRnEH9TZrGN2Cg4KjK2GVJNg2ynpZzq8YC1Jr1m3cnTfV8wsNT7EwTaYMy4PCDAg' is not valid.

At this stage i’m only interested into a watch only wallet, so i don’t need to use private keys.
Also, I'm in testnet and I have testnet=1 on my bitcoin.conf
I've tried reading as much as I could but I think i hit a wall now and I don't know how to continue.
Any help would be greatly appreciated

You're trying this with testnet funds, right?

yes, i’ll edit my question

Did you ever get this to work? I'm having the exact same issue on 0.21. barely any docs on the matter.

In fact I did! i'll answer my question, hold on

Actually I just kind of succeeded too. I wonder if we have the same solution :)
So I was using the root key signatures from seedpicker, where I got the Vpubs, but now I tried the master fingerprints from Specter PDF with SLIP132 and got the same addresses. What I still don't know is
a. where I can independently get the correct signature without relying on Specter and
b. why the addresses imported are completely out of order and
c. why bitcoin-qt does not show past transactions (I'm on a pruned node, so that could be the reason...)

see my answer for that, it should give you enough info

I used this guide. I understand you completely ignored the fingerprint and derivation path?

/0/* is the derivation path for receive addresses where /1/* is for change addresses, you use the script i pasted like this script.sh wallet_name vpub1... vpub2... vpub3... 0 "0,100"

I didn't mean the receive and change derivation paths. I means the key derivation path. When I created the descriptor I used the following format:
wsh(sortedmulti(2,[XXXXXXXX/48h/1h/0h/2h]tpubDFfbToY......e8dAX/0/*, ...

right, I ignored that. turned out it worked fine

Interesting. I also have a question for 'a' above. When converting the Vpub to tpub lopp's tool also gave me a new fingerprint, which I promptly (at least at first) ignored. Still wondering about the order of the addresses. Thanks for the info!

if it worked for you accept the answer!

this is a script that works for me, it imports a 2of3 HD multisig wallet.
I have very basic knowledge of bash so you may want to double check it before running it, anyway, what finally worked for me was to understand that I had to wsh(sortedmulti(2,${pub1}/0/*,${pub2}/0/*,${pub3}/0/*))to derive the receive descriptor and wsh(sortedmulti(2,${pub1}/1/*,${pub2}/0/*,${pub3}/0/*))for receiver.
I also found this good converter here:
https://jlopp.github.io/xpub-converter/
#!/bin/sh

wallet=$1
pub1=$2
pub2=$3
pub3=$4
startfrom=$5
range=$6

wallet="${wallet:=test}"
pub1="${pub1:=Vpub1...}"
pub2="${pub2:=Vpub2...}"
pub3="${pub3:=Vpub3...}"
rescanblockchain="${startfrom:=1934907}"
range="${range:=[0,100]}"

p1=$(echo $pub1 | cut -c1-10)
p2=$(echo $pub2 | cut -c1-10)
p3=$(echo $pub3 | cut -c1-10)

printf "\n\nWorking on '${wallet}' from ${p1}... ${p2}... ${p3} starting from ${rescanblockchain}\n\n"

# create wallet if needed
if [[ $(bitcoin-cli listwallets | jq '. | index("'$wallet'")' ) == "null" ]]; then
    echo "Making wallet '${wallet}' from ${pub1} ${pub2} ${pub3}"
    bitcoin-cli createwallet $wallet  true
fi

# convert keys format from vpub to tpub https://jlopp.github.io/xpub-converter/
pub1=$(node converter.js ${pub1})
pub2=$(node converter.js ${pub2})
pub3=$(node converter.js ${pub3})

# get descriptor for receive addresses
raw_receive_descriptor="wsh(sortedmulti(2,${pub1}/0/*,${pub2}/0/*,${pub3}/0/*))"
receive_descriptor=$(bitcoin-cli getdescriptorinfo $raw_receive_descriptor | jq -r '.descriptor')

# get descriptor for change addresses
raw_change_descriptor="wsh(sortedmulti(2,${pub1}/1/*,${pub2}/0/*,${pub3}/0/*))"
change_descriptor=$(bitcoin-cli getdescriptorinfo $raw_change_descriptor | jq -r '.descriptor')

# import receive addresses
bitcoin-cli -rpcwallet=$wallet importmulti  '[{"desc": "'$receive_descriptor'", "internal": false, "range": '${range}', "timestamp": "now", "keypool": true, "watchonly": true}]'  '{"rescan": false}' | jq .

# import change addresses
bitcoin-cli -rpcwallet=$wallet importmulti  '[{"desc": "'$change_descriptor'", "internal": true, "range": '${range}', "timestamp": "now", "keypool": true, "watchonly": true}]'  '{"rescan": false}' | jq .

# rescan blockchain
bitcoin-cli -rpcwallet=$wallet rescanblockchain "${rescanblockchain}" | jq .

# just print out few receive addresses
bitcoin-cli deriveaddresses  ${receive_descriptor} "${range}" | jq .

# print out balance
bitcoin-cli -rpcwallet=$wallet getbalance

So just to make this post more clear, this can be run directly on bitcoin-cli or in the bitcoin-qt console. Mostly I followed this guide.
instead of Vpubs, I used Jameson Lopp's converter to convert the Vpubs into tpubs, and while there I get the matching fingerprints, so I have everything I need.
Mind you, this is just to verify receive addresses independently from any other wallet (Electrum, Specter).
Sorry I can't upvote or do anything else, I am a first time user with 0 reputation :(


text:
Help in recovering BTC from seed phrase
So 6-7 years ago I had some bitcoin, and as with many I forgot about it...
I since found my notes which contain a 12 word seed phrase. I think (I may be wrong) I used Multibit so I reinstalled and fired this up and tried to restore the wallet from seed.
Multibit asks for the seed, then syncs, then asks for a date - which I don't have. If I leave this blank and continue  it just reverts back to the start dialogue where you can create a wallet, restore etc.
I also tried importing the seed into Electrum using this guide: https://bitcoinelectrum.com/restoring-your-multibithd-wallet-in-electrum/
I.e. setting the derivation path etc. But the wallet just comes up blank listing no transactions.
Is there anything else I could try?

"reverts back" this seems to be a bug, restoring without the datestamp is supported. Unfortunately I can't help further.

Like MCCCS said, the fact that it goes back to the start screen is a bug. Try installing an older version of MultiBit, and use that.
EDIT: Don't use Multibit. From the readme:

Dear Bitcoin Community,

It is time for us to let Multibit go.

KeepKey acquired Multibit a little over 1 year ago. At the time, the engineers who originally built and supported Multibit had announced that they would no longer be working on it or providing support. Multibit played an important role in the Bitcoin infrastructure. We felt that it was important for Multibit to continue and hoped that with our existing support and development teams, we would be able to keep Multibit alive.

The reality is that Multibit is in need of a lot of work. It has stubborn bugs that have caused us and Multibit users much grief. Additionally, Bitcoin has gone through a fundamental change in regards to the way fees work. The addition of SegWit in the coming weeks will mean the Multibit software has fallen still further behind.

Unfortunately, KeepKey simply does not have the resources to support the current issues, nor to rebuild Multibit to ensure ideal user experience. By focusing our attention on the KeepKey device, we will continue building and improving the best hardware wallet available.

Thus, KeepKey will discontinue support and maintenance of Multibit, effective immediately.

We recommend that all Multibit users discontinue using it and you move your keys to other wallet software of your choosing.

I would try using the electrum wallet, but DO NOT select to use SegWit addresses. Use the legacy addresses when restoring the wallet.

Them you but I've tried electrum as per the guide linked above, and I've chosen legacy over segwit. I just get a blank wallet with no transactions.

yeah, I was wrong you need to use an old version of multibit and transfer the funds to an electrum wallet because electrum and multibit are incompatible

for the date, just input jan 3 2009

This should be obvious, but I would recommend that you do not send your seed to strangers on the internet. Keep your conversation in public so others can help you avoid bad advice, and never share any sensitive information.

@5ynt4x_3rr0r_: Thank you for helping Nick, but please refrain from trying to get people to send you key material privately.


text:
What exactly is being done today to make Bitcoin "quantum-safe"?
A recent article on the potential threat of quantum computing to Bitcoin (and other cryptocurrencies) quotes an industry strategist:

...the crypto industry is working on "quantum-safe" crypto.

The article also says:

The National Institute of Standards and Technology (NIST) has released several quantum-safe algorithms that are resistant to attacks by future quantum computers, ..., and NIST has a timeline for governments and industry to deploy these algorithms to ensure the safety of the nation’s and businesses secrets.

I have not been able to find what is being done to make Bitcoin, in particular, quantum-safe.  Can someone point me to what is being done in this regard?

What do you mean by "in charge of"? Are you asking who is in charge

@RedGrittyBrick: I reworded my question in vaguer terms.  I hope you find this rewording more acceptable.

While there seems to be progress on quantum computing especially lately, from what I understand, quantum capabilities are still magnitudes away from being relevant to Bitcoin security. There recently were some post-quantum signature schemes published by NIST that garnered some interest in the Bitcoin community. It might be years or decades until quantum computing becomes actually relevant.
There is nobody in particular in charge of anything. However, there are some people working on a Bitcoin Improvement Proposal which aims to introduce a quantum-resistant output type: BIP-360: Pay to Quantum Resistant Hash. I’m sure as quantum computing improves, so will the interest in working on post-quantum security.

Thank you.  Something does not add up, somehow.  Maybe this is the Achilles heel of decentralization: no one is in charge of averting the potential sudden loss of billions of dollars' worth of value.  Or maybe I am greatly overestimating the risks.

@kjo: You mean, unlike assets with centralised responsibility for security such as the Venezuelan Bolivar, Enron and Lehrman brothers? :-)

@RedGrittyBrick: ever heard of "necessary but not sufficient"?


text:
Is it possible to "send" Bitcoin to yourself (new wallet) without announcing it to the network and without paying any fee?
I want to make clear that I've already performed said transactions, so I'm not asking this because I want to do it right now. I'm just curious.
Basically, I've spent a number of very sweaty and nervous days "rearranging" most of my coins so that they will finally end up in an encrypted cold storage wallet.dat, after having spent years fully unencrypted and regularly coming into contact with my main PC. Yes, I know it's insane, but I was not just lazy, but also seriously worried that I'd end up losing access to my coins by forgetting the passphrase. That's why I never did it.
Anyway, I've been forced to pay two Bitcoin transaction fees when sending the coins to myself twice. Although I probably would not have ended doing it if it's complicated/scary, is there some way that I could have just "transferred" the coins by, I don't know, typing some kind of private key dump command in the console of Bitcoin Core and then imported them into the new wallet or something?
Or is the only technical way to move funds between wallets to use the Bitcoin network and thus announce to the world that "somebody sent X BTC"?

The network comes to consensus on how much Bitcoin is held at individual addresses. If you want the network and the blockchain to recognize a certain amount of Bitcoin is held at a new address rather than an old one you can't avoid broadcasting a transaction and paying a fee. Of course there are offchain methods of transferring value like Lightning and Liquid between addresses but the Bitcoin blockchain does not know of these transfers.

Bitcoin funds are held in Unspent Transaction Outputs (UTXO). They can be spent by fulfilling the conditions of the associated locking script which generally means being able to sign with a specific private key. Wallets are essentially a key ring for private keys with some convenience functionality for better UX. If you are worried that a wallet may have been compromised, it is necessary that you store the funds in a new UTXO so that they are no longer spendable by the potentially compromised private key. This necessarily involves on-chain transactions as there is no other way to update which private key spends the funds.
If you are exclusively worried about being compromised in the future, you could encrypt your existing wallet and delete all unencrypted copies and thereby forego the on-chain transactions.
If you are seriously stepping up your security procedures, you should probably eat the transaction cost to turn a new leaf and start with a fresh wallet.

Let me define "funds being in a wallet" as "funds (outputs) being able to be spent by anyone who has the private key of the wallet". Unless you sign and broadcast a transaction that will be included in a block, your funds are in your previous wallet.
You could sign low-fee transactions and publish them every two weeks. One day, when there is less congestion, it'll be the part of the blockchain.
Instead of making two transactions from different source wallets, you can dump private key from one of them and import to other to make one larger transaction with lower total fees and a larger quantity of inputs.
Or you could just import the private key. Be aware that then your funds in your new address is secure as min(previous wallet,next wallet).
If someone gave me a private key with funds in it, I would sweep them ASAP. If the private key is mine, I would just import and forget about it.
Transfers without broadcasting transactions are known as off-chain payment protocols. The most famous ones are Lightning and Liquid, and these require an initial on-chain transfer.


text:
How can an online system detect coins sent to its offline (cold) wallet?
Say, for security reasons, that a bitcoin business has an online wallet (aka hot wallet) with enough coins for day-to-day operations. The rest of the funds are in an offline wallet (aka cold wallet or cold storage).
How can the online servers detect when coins are sent to the offline wallet?
Can this be (easily?) done with bitcoind or is another bitcoin client needed?
Technical details may be interesting, but I think more important is how a merchant can achieve this sort of functionality.

possible duplicate of Monitor all transactions on bitcoin network - API

+1 I would be interested in seeing more details of the linked question with regard to the specifics of this question.

Armory appears to have a watch-only functionality: See How to sign a transaction using only an offline computer?

Since version 0.10.0 bitcoind has support for watch-only addresses.
Here is the text from the release notes:

Watch-only wallet support
The wallet can now track transactions to and from wallets for which
  you know all addresses (or scripts), even without the private keys.
This can be used to track payments without needing the private keys
  online on a possibly vulnerable system. In addition, it can help for
  (manual) construction of multisig transactions where you are only one
  of the signers.
One new RPC, importaddress, is added which functions similarly to
  importprivkey, but instead takes an address or script (in
  hexadecimal) as argument.  After using it, outputs credited to this
  address or script are considered to be received, and transactions
  consuming these outputs will be considered to be sent.
The following RPCs have optional support for watch-only: getbalance,
  listreceivedbyaddress, listreceivedbyaccount, listtransactions,
  listaccounts, listsinceblock, gettransaction. See the RPC
  documentation for those methods for more information.
Compared to using getrawtransaction, this mechanism does not require
  -txindex, scales better, integrates better with the wallet, and is
  compatible with future block chain pruning functionality. It does mean
  that all relevant addresses need to added to the wallet before the
  payment, though.

Try bitcoin-cli help importaddress (and the help texts for the other relevant commands listed above) for the details.

Every bitcoin client knows about every account. You don't need the keys that control the funds in an address to monitor it.
1) Give your online server a list of your cold storage addresses.
2) Periodically check the balance of those addresses, perhaps using the command bitcoind getbalance [account]
API reference
Edit: Unfortunately, I was using the command I posted incorrectly. I think this functionality might not be in bitcoind. However, there is an open-source tool called Abe that's worth looking into.

Please don't confuse Addresses with Accounts (https://en.bitcoin.it/wiki/Accounts_explained). Information about addresses are included in Bitcoin Blocks, information about accounts are not. They are specific to a client instance.

@ThePiachu, you are correct and I have edited my answer.


text:
What are good ways to storing backup of an encrypted wallet?
What are good ways and places for storing backup of an encrypted wallet?
When somebody open encrypted wallet what all can he do when he does not have a key?
asuming that the key to the wallet is e.g. 73 trilion years far to cracking

You can back it up pretty much anywhere. USB drive, backup hard drive, Dropbox.
If your wallet is encrypted, all they can see is what addresses you own and how many bitcoins they have. They cannot send any bitcoins or get the private keys.


text:
How to extract all info for a public address from a local full node's db?
I recently started running bitcoind on a local Debian host, and I am still learning how to use the information in the local copy of the bitcoin blockchain.
I would like to extract all the information for one or more public bitcoin addresses currently available in the full node locally 1.  EDIT 2: I want to do this both from the bash command line and programmatically.  (IOW: no GUI-based tools, please.)
I recently learned that, contrary to my initial expectation, bitcoin core is not suitable for performing this sort of query.
Therefore, I went back to Google, but I've come up empty 3.  Hence I'm posting my question here.
Specifically, I would like to know

what software (preferably in the form of one or more Debian packages) would I need to install on the local full node that would enable me to extract all the information for one or more public bitcoin addresses currently available in the full node locally;
how exactly would I use this software to perform such queries.

1 I want to do this without reference to any specific wallet.  Having to add this requirement feels extremely weird to me (like having to add the requirement that answers to my question should work seven days a week).  This is a clear sign to me that there is still at least one pretty gigantic gap and/or confusion in my understanding of bitcoin, because I don't understand why a wallet should be even relevant to the kind of query I want to do.  I would have thought that a wallet would be, at most, an optional piece of information to modify the query, not an essential input for it.  But the fact is that I have not been able to find any way to interrogate the full node's database for specific addresses that does not require specifying a wallet.  This is just mind-boggling to me.
2 I apologize for not mentioning this critical requirement in my original post.  That was a major oversight on my part!
3 I am beginning to realize that the queries I want to perform on a full node's database (and without reference to a wallet) is something practically no one cares to do, and therefore it is hard to find tools for doing them.  Again, this strikes me as a bit weird, and feeds my growing suspicion that I am totally missing the point about bitcoin, blockchains, full nodes, etc.

Why this is hard
Bitcoin Core is chiefly a tool to synchronize with the current state of the network and to enforce the consensus rules with a self-owned piece of hardware. Beside being on the same page regarding the rules, this requires the node only to keep track of the ledger, the Unspent Transaction Output (UTXO) set. Bitcoin transactions need to be processed only once to that end.
The blockchain being now over 330 GiB, some people are actually choosing to run pruned nodes (that discard old blockchain data after processing it to calculate the UTXO set). Keeping additional indexes around with dozens of GiB in size is a special interest most users don't seem to care for.
In fact, Bitcoin Core does not feature a full address index out of the box. Originally maybe, because address reuse is considered a bad practice, later because other projects offer this, leaving Bitcoin Core developers feeling that they could focus on other things.
How you do it anyway
Bitcoin Core has an option to build a full transaction index -txindex (turning it on will require you to start over with synchronization and take about 30 GiB more space). This index is needed if you want to look up arbitrary transactions from the past. Other projects leverage this functionality and build additional indexing capability around it to offer Lightning Network support or Bitcoin explorers. I would recommend that you look into the Mempool Open Source Project or the Esplora Block Explorer. Either of these will allow you to run your own instance of a block explorer with APIs to look up blockchain data on basis of addresses. Note that the Esplora index will take about 1 TiB and apparently takes quite some time to build (H/T @Anonymous).

Thank you!  FWIW, I did have txindex=1 in my bitcoin.conf at the time I did the IBD, so I guess I should be good to go?  (BTW, your answer explains something that had been puzzling me: my first attempt at IBD failed for lack of space, even though 350GB had been available when I started running bitcoind.  Now I realize that the txindex=1 in my bitcoin.conf came with a much bigger space requirement than that.

Yeah, I think the transaction index adds another 200 GiB or so. If you had it on already, you'd be good to go indeed.

After looking a bit into mempool and esplora, which appear to be GUI/browser-based tools, I realized that I should have spelled out that I want to run queries from the command line and/or programmatically.  I am sorry about this omission!  (I keep forgetting that those like me, who consider graphical interfaces basically useless for any real work, make up a minuscule minority.)  I have now edited my post to make this requirement clear.  (I fear, however, that, given that what I want to do appears to be difficult, this additional requirement may be a deal-breaker...)

Oh, I just found https://github.com/Blockstream/esplora/blob/master/API.md, which you alluded to in your original reply, but I missed in my initial look-over.  (I still have not been able to find much documentation for mempool, though.)

OK, I guess this is it for mempool: https://mempool.space/api

@Murch The esplorer database is over a terabyte and takes many days to produce on fast hardware.

@Anonymous: Yes, I was talking about Bitcoin Core's transaction index.

That’s a couple of gigabytes.

Oh, I misremembered. It seems to be around 30 GiB according to past-you: https://bitcoin.stackexchange.com/a/49715/5406

I have written a program that allows you to search for any address regardless if it belongs to your wallet or not, in Python3.
Here is the github link:
https://github.com/ORP967/Bitcoin_Core_RPC_par_address
Let me know what you think and if you have any improvements.


text:
Bitcoin core -trying to open my watch adress with private key- unsolvable
First of all, please bare with my ignorance. When i bought btc 5 years ago i did not know more than i know today, which is very very little.
However, after retrieving my private key for an crashed hdd, i then created a new wallet in bitcoin core, i downloaded the whole blockchain, wrote -impprivkey in console followed by the private key connected to my old adress, where me btc had been resting for 5 years.
However, after a long scan it shows up in my wallet as unspendable. It shows only as a watch-wallet. Ok, i then write listunspent in console.
I get that the coins are
Spendable - false
Solvable - false
Safe- true
Now what can i do? What may have happened? I do have the private key. I have tried to sweep the coins into an electrum wallet, but since they are unspendable - aint gonna happen.
Any suggestions, anyone?
Thx and have a great day!
Edit:   I am looking at this as a lost case. But however it would be interesting to know what went wrong. Because when i did impprivkey in bitcoin core and waited the numerous hours for the rescan, the bitcoin did show up, but in the form of a watch adress and unspendable. The fact that -listunspent gave me : solvable - false,
Im curious to understand in what was it is unsolvable and why.
Thx again for any answers

Does this answer your question? Why outputs' spendable and solvable are false?

What happens when you attempt to import or sweep your private key to electrum? Electrum imports the key and then it says it is unspendable?


text:
Blockchain Login
We're working on a research based on the blockchain and I can't understand a point about login authentication. As we all know, blockchain is distributed or decentralized system, there is no central server available. But how authentication is provided among the users?
Like I have my credentials for paypal wallet, I enter my ID and password to log into the wallet and some central authorities verify that login and grant me access, how is this possible in the case of blockchain where the central server doesn't exist?

Cash
The Bitcoin network doesn't authenticate users. The Bitcoin network doesn't know or need to keep track of people's identities.
Just as a recipient of a $10 bill or €50 banknote don't need to know the identity of the other person, they just need to examine the paper to see if it looks genuine.
Bitcoin is cash, not a bank account.
Bitcoin transactions contain a cryptographic proof that the spender is entitled to spend an amount of Bitcoin that is the output of some prior transaction. This proof is based on private-key cryptography where a private key can be used to produce a cryptograhic signature of data that proves the author knows a private key corresponding to a public key associated with the amount. It is a secret number which you can mathematically prove you know without revealing the number.
The private key is chosen essentially at random. There are so many possible private keys that there is no realistic chance of two people randomly choosing the same key anytime in the expected lifetime of the Universe.

How to use cash?
Lets say you are on vacation in France, you see a cake you'd like to buy in a Boulangerie. The vendor looks at your $10 bill and says "I only take Euros". What do you do? You walk to a Bureau de Change show them your $10 bill and ask "How many Euros will you give me for this?". If you like their answer you get Euros you can use to buy your cake. If you don't like their answer, maybe you ask a passerby who looks friendly, maybe you ask in your hotel, maybe you can think of a thousand other ways to convert cash in one currency to cash in a different currency without the direct personal involvement of governments, mints or central banks?
Remember that people traded goods between countries long before computers, long before electricity. Swapping cash in Dollars for Sterling yesterday is fundamentally no more magical than swapping crowns for doubloons centuries ago or swapping Yen for Bitcoin today.
Much the same applies to any currencies. Including Bitcoin, cowrie shells or chunks of gold amulets. The business of money-changer is an ancient one but even they do not have a monopoly and do not prevent two people directly swapping things of equivalent value.

Got your point, but in such case as you stated, "the spender is entitled to spend an amount of Bitcoin that is the output of some prior transaction" but how the physical cash get converted into the bitcoin if no central authorities are there.

@Harsh: How does your physical cash get converted into your neighbour's unwanted lawnmower (or surplus Euros from their vacation in France) when no central authorities are there? When you go to your local market and buy oranges, do you have to show ID to a nearby policeman to authorise the purchase or does the trader just look at your money?

so is it kind of a barter system? and let's say I am having 2 bitcoins right now, how do I encash same?

@Harsh: Bitcoin is cash. How do you encash cash? All money is a kind of barter system.

still I am scratching my head, If I want some bitcoins, how do I get that?

@Harsh If you want some Euros, how do you get that?

There is a central government who issue (print) the euros

@Harsh: so do you go to the Government to ask for Euros? Do you go to a printing press at a mint in France? You don't. I live in a non Euro country but I can get Euros easily at nearby supermarkets, from my bank, from a bureau de change, from an ATM at an airport, from a friend or relative who has some left over from travel, from strangers I ask, from a million places that are not government run. Many of these don't know me and don't need to know my name.

Got you, How did the first user get the bitcoins?

@Harsh: See What exactly is mining and Who decides the block reward. You may find it useful to use the search bar at the top of this web page!


text:
how is bitcoin network protect itself from malicious nodes?
Can someone explain how does Bitcoin network protect itself from malicious nodes? Lets say someone creates bitcoin core clone and they manipulate it to their need. For example could someone change code for transaction verification? Or on a node lower mining difficulty? Could there be a slight change in consensus algorithm that goes undetected?


text:
segmentation fault while using oclvanitygen
I'm running the following oclvanitygen version. The program crashes with corefile.
I'm unable to decode the core file. Has anyone faced similar issue, how to proceed?
Update:
clinfo has the following to say, Could this be the reason.

Device Name                                   Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
NOTE:   your OpenCL library only supports OpenCL 1.0,
but some installed platforms support OpenCL 1.2.
Programs using 1.2 features may crash
or behave unexpectedly

oclVanitygen PLUS v1.50 (OpenSSL 1.1.1i  8 Dec 2020)

Available OpenCL platforms:
0: [Apple] Apple
  0: [Intel] Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
  1: [Intel Inc.] Intel(R) HD Graphics 530
  2: [AMD] AMD Radeon Pro 455 Compute Engine

$ ./oclvanitygen -v -i -D 0:0,grid=1024x1024 -f comic.txt -o ouput.txt
Loading Pattern #1: 1Test
Prefix difficulty:             16506514 1Test
Difficulty: 16506514
Device: Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
Vendor: Intel (ffffffff)
Driver: 1.1
Profile: FULL_PROFILE
Version: OpenCL 1.2
Max compute units: 8
Max workgroup size: 1024
Global memory: 17179869184
Max allocation: 4294967296
OpenCL compiler flags: -DDEEP_PREPROC_UNROLL
Compiling kernel, can take minutes...done!
Build log:
....
....
<program source>:1218:1: warning: no previous prototype for function 'hash_ec_point'
hash_ec_point(uint *hash_out, __global bn_word *xy, __global bn_word *zip)
^
<program source>:1379:1: warning: no previous prototype for function 'hash160_ucmp_g'
hash160_ucmp_g(uint *a, __global uint *bound)
^
Grid size: 1024x1024
Modular inverse: 2048 threads, 512 ops each
Using OpenCL prefix matcher
Segmentation fault: 11
Grid size: 1024x1024
Modular inverse: 8 threads, 131072 ops each
Using OpenCL prefix matcher
Segmentation fault: 11

You should try with the latest version 1.53 first. Download from https://github.com/exploitagency/vanitygen-plus

Try removing ,grid=1024x1024. Or even better just use -D 0:2


text:
Wallet.dat can contain only 100 private keys even if I back up?
Considering the Bitcoin client for Windows 0.8.1:
So the best way (if I have already used up 100 keys) is to send bitcoins to different wallet and then to newly generated one?
When I want new keys, can I just delete old wallet from default location and WILL BE THE NEW ONE GENERATED AUTOMATICALY when turning on the client?

A wallet (by default) always contains 100 unused keys. Every time the client needs a new key (for a new address, for sending change to, or - in theory - for solo mining payouts), it takes the oldest address from the pool, and creates a fresh one to add.
This just means you need to backup every 100 transactions. No need to switch to a new wallet.

When I want new keys, can I just delete old wallet from default location and WILL BE THE NEW ONE GENERATED AUTOMATICALY when turning on the client? And is this option possible?

If you delete the wallet, a new one will be created yes. But that does mean you lose all your funds, as you lost all old keys. You don't need to worry about this - a wallet always generates new keys when it needs them.

And so the key pool is getting constantly bigger? How can I get to know how big is at the moment?

The keypool always contains 100 future keys. The total number of keys in a wallet (those used + those in the pool) constantly grows indeed, though. I don't think the total number is exposed anywhere, but the getinfo command (RPC or debug window) can tell you the timestamp of the oldest entry in the key pool.

Run the client with the parameter -keypool=10000 to generate 10000 keys in your keypool.
Pros: Less backing up
Cons: Your wallet will be bigger (file size) and take maybe a few seconds extra to load

Today I learned.

That is for Bitcoin-Qt, if you use MultiBit, after you sent money, the change will return to the sending address.

authors: Сергей Шеркунов


text:
Why was the target block time chosen to be 10 minutes?
According to the wiki, 10 minutes was chosen as a 'tradeoff'.

Why ten minutes specifically? It is a tradeoff chosen by Satoshi between propagation time of new blocks in large networks and the amount of work wasted due to chain splits.

However in the original Satoshi paper, 10 minutes is merely assumed for the purposes of calculating disk space requirements.

A block header with no transactions would be about 80 bytes. If we suppose blocks are
generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year.

Is there a discussion elsewhere that explains how the 10 minute block time was arrived at?

I think that if the 10 minute block requirement proves problematic for some reason, and most miners & users agree, this can be lowered in the future.

Mike Hearn explained to me once that Satoshi estimated block propagation time to be 1 minute, and chose 10-minute block intervals because "wasting" 10% of mining work was a fair amount. Currently block propagation time is much, much faster though.

@pinhead What exactly do you mean by wasting 10% of mining work?

@FivePoints in this context, we mean that 10% of blocks mined will "lose the race" against another block mined at nearly the same time and become stale, meaning the subsidy payout to the miner will never be spendable and the energy consumed by the miner to produce that block will be wasted.

@pinhead makes sense but how was that 10% calculated? Is it simply (latency / block time)?

@FivePoints exactly. That was apparently Satoshi's thinking according to Mike Hearn

@FivePoints source, for what its worth: https://www.reddit.com/r/Bitcoin/comments/30lxo4/replace_by_fee_a_counter_argument_by_mike_hearn/cptwk21

@pinhead It appears that your accounting of waste fails to include all the waste of the machines that did not finish in 10 minutes.

10 minute blocks is simply a compromise.
Shorter block time:

PRO - Faster 1 confirmation time (to protect from 0-confirm double spend)
PRO - Less payout variance for miners (less reliance on large pools)
CON - Requires increased bandwidth (inter node communication)
CON - More forks, longer forks, and longer re-org time
CON - A greater portion of the raw hashpower is wasted, resulting in lower effective security.

With a longer block interval target of longer than 10 minutes, the pros and cons would be reversed.
The major benefit of a shorter block time is the reduced 1 confirm time.  While a quicker block's 1 confirm transaction has less strength than a longer block's 1 confirm transaction it is still better than any block's 0 confirm transaction.
The speed of 1st confirm may seem to be a huge benefit but in reality for most low value and time sensitive transactions such as the buying a cup of coffee, paying for a taxi, or using a vending machine, the risk of double spends is very low. Keep in mind that accepting credit cards is not without risk however merchants have long accepted they will face some losses however if those losses are minimal then it can just be seen as a cost of doing business.  So many merchants could simply accept 0-confirm transactions without exposing themselves to more risk than they do from credit card fraud.
The other factor that diminishes the real world potential of shorter target block intervals is that for many merchants, even  "faster" confirmation times still isn't fast enough. For a Point of Sale transaction, an average confirmation time of 2 minutes is still significantly longer than what most merchants would consider to be workable. The average credit card transaction takes about 20 seconds (including delays by customer).  The entire industry has spent significant resources to shave even a few seconds off.  Changes like enabling customer to swipe card, swiping before all items have been rung up, and not requiring signatures on low value are all about shaving a couple seconds off an already quick process and the cost of those changes is considered acceptable in order to slightly improve the efficiency of a checkout.
The other factor is that reducing the target interval only reduces the average confirmation time but half of them will be longer and the tail can be very long. Due to the random nature of blocks solutions about 15% of blocks will take longer than 2x the target, 3% longer than 3x the target and >7.5 minutes and about 0.5% will take longer than 4x the target.  That uncertainty makes it difficult for a time sensitive business to as a matter of policy wait for confirmations.  Having most transactions confirm in 30 seconds but some take minutes is going to lead to customer frustration at the point of sale.
If the BTC economy grows large enough we could see expanded use of "green addresses" to fill the need for instant acceptance without confirmations.  Such services could be provided by major corporations, and backed by insurance against fraud (for a small per transaction fee).  This would be a more viable 0-confirm solution than a simple reduction of the block interval.
That being said the 10 minute target was probably overly conservative and there are some advantages to a shorter block time.

Your mistake is that you think "double spend attack" means "51% attack". You can try to double spend with less but you're not guaranteed success. The more blocks waited, the smaller your chance. >50% is the point where you're guaranteed eventual success no matter how many blocks are waited.
The probability of success with a <50% attack depends on the number of blocks and not the amount of time. This is an advantage of shorter blocks.

Shorter block time has another pro - less variance for miners. Also, the extra storage space for short blocks is negligible since the bulk of data is the transactions, not the block headers.

You have some typos: The first 2 entries for "Longer block time" should be "CON" and "PRO" rather than "PRO" and "RRO".

@MeniRosenfeld Thanks for the corrections and I added variance differences and removed the storage differences as you are correc the differences will be rather small.  I also removed the time based aspect because while I have heard it requires more confirmations I don't have definitive knowledge.  There are enough other known differences.

Very nice update, I wish I could upvote again. ;)

Further: shorter blocks means more storage for pruned and SPV nodes.

I found that part of the wiki frustrating too, and I just edited it. I'd appreciate corrections. Here's what I wrote:

Ten minutes was specifically chosen by Satoshi as a tradeoff between first confirmation time and the amount of work wasted due to chain splits. After a block is mined, it takes time for other miners to find out about it, and until then they are actually competing against the new block instead of adding to it. If someone mines another new block based on the old block chain, the network can only accept one of the two, and all the work that went into the other block gets wasted. For example, if it takes miners 1 minute on average to learn about new blocks, and new blocks come every 10 minutes, then the overall network is wasting about 10% of its work. Lengthening the time between blocks reduces this waste.
As a thought experiment, what if the Bitcoin network grew to include Mars? From the farthest points in their orbits, it takes about 20 minutes for a signal to travel from Earth to Mars. With only 10 minutes between new blocks, miners on Mars would always be 2 blocks behind the miners on Earth. It would be almost impossible for them to contribute to the block chain. If we wanted collaborate with those kinds of delays, we would need at least a few hours between new blocks.

Also see: http://bitcoin.stackexchange.com/questions/30001/how-do-you-create-a-planet-specific-cryptocurrency-that-will-ignore-longer-block

As Bitcoins are the first cryptocurrency to use block generation and so forth, one can assume 10 minutes was a arbitrarily chosen. Any value that was big enough to propagate the new block through the network before another miner would be probable to generate a new block would be good. On the other end blocks shouldn't be too scarce, as it would take too long to get confirmations. An hour of computation is considered safe from being tampered with, so dividing that time into neat parts can give you 10 minutes.
There probably isn't any discussion available on this topic, as the first Bitcoin version was created by Satoshi alone, so until he reveals his true identity or comes back to the community, the exact reasons can't be figured out for sure.

The analysis in Satoshi's paper doesn't at all relate to the amount of time one should wait - that depends solely on the practicality of maintaining a high hashrate for a long time. He discussed the amount of blocks to wait - he showed, for example, that if the recipient waits for 6 blocks and the attacker has 10% of the network's hashrate, a double-spend attempt only has <0.025% chance to succeed. At 1 minute per block this is 6 minutes, etc.

Block time was determined by Satoshi Nakamoto as a tradeoff between 2 factors
1.Network latency:
After a block is mined, it takes some time for other miners to find out about that node and during that time, actually other miners are still competing (which means mining) against that block instead of adding that block to the chain. This leads to the waste of mining resources which is caused because several miners are still mining their blocks but the network can add only one. Plus this is a fact that it will take some time for any new mined block to show up to all the nodes since network lag is a thing.
2.Confirmation time:
We can be sure about the confirmation of a block being added to the chain/network only after some blocks are added to that chain. And to make confirmation more reliable about 5-6 blocks are needed to be added to the chain after our block. This will surely take some time. But we need to make this process fast.
Now, the network lag factor needs the block time to be longer whereas the confirmation time factor needs it to be shorter. Hence a trade off was chosen which is 10 minutes. This time length was surely chosen after some calculations. But theoretical reason behind the block time is same as described in this answer.

AFAICS, the only possible benefit to the longer block time is the reduction of bandwidth overhead due to less probability of block chain splits.
I even doubt that tradeoff, because if the transaction data is the bulk then there is the counter-balancing effect that shorter block times mean less data to transmit.
I am highly skeptical that there must be more work wasted with shorter block time, if the difficulty is calibrated w.r.t. the time to arrive at a consensus. Mathematically the miners earn a percentage of the newly created blocks proportioned roughly by their percentage of the system hash power, regardless the relative split in proportion of their luck between work difficulty and (the random) orphaned chains.
Unless there is a proof, I doubt the claim that shorter block times create longer times to arrive at consensus (i.e. re-org splits), because for example if there are 4 times more splits with 1/4 the block time, there are roughly 7 more iterations to arrive at consensus within the same duration.
G̶i̶v̶e̶n̶ ̶t̶h̶a̶t̶ ̶i̶r̶r̶e̶v̶e̶r̶s̶i̶b̶i̶l̶i̶t̶y̶ ̶i̶s̶ ̶a̶ ̶f̶u̶n̶c̶t̶i̶o̶n̶ ̶o̶f̶ ̶n̶u̶m̶b̶e̶r̶ ̶o̶f̶ ̶b̶l̶o̶c̶k̶s̶&̶m̶d̶a̶s̶h̶;̶ ̶n̶o̶t̶ ̶o̶f̶ ̶t̶i̶m̶e̶— ̶a̶n̶d̶ ̶t̶h̶e̶ ̶d̶i̶s̶a̶d̶v̶a̶n̶t̶a̶g̶e̶ ̶o̶f̶ ̶d̶e̶l̶a̶y̶s̶ ̶i̶n̶ ̶t̶r̶a̶n̶s̶a̶c̶t̶i̶o̶n̶s̶,̶ ̶i̶t̶ ̶s̶e̶e̶m̶s̶ ̶a̶ ̶s̶h̶o̶r̶t̶e̶r̶ ̶b̶l̶o̶c̶k̶ ̶t̶i̶m̶e̶ ̶i̶s̶ ̶c̶o̶m̶p̶e̶l̶l̶i̶n̶g̶.̶
I would appreciate if downvoters would at least try to defend their logic with a comment below my answer. That gives me an opportunity to debate them and show them why I think they are wrong (or to admit my mistake). The point is to make sure we collectively have the correct logic.

This answer is disregarding the time cost incurred by block transmission and block verification. Since that time is a roughly fixed amount for a full block, it is a larger relative portion of a shorter block interval than a longer block interval.

@Murch, I wrote that answer a few days or weeks after initiating my study of blockchains, cryptography, and Bitcoin. My views have changed considerably hence. However, presuming the transaction volume per block is reduced given a higher block frequency, your claim of constant propagation & verification time isn’t correct. Craig Wright has claimed the Bitcoin network propagates to 99% of the hashrate within roughly a second.

Since practically all miners are connected to Fibre and published data suggest that it's just slightly slower than speed of light, <1 second is not a difficult claim to make… However, the most significant impact this year was probably that miners upgraded to a recent version of Bitcoin Core to signal for the segwit activation. Earlier this year, we were still seeing multiple orphaned blocks per week. A blocktime of e.g. 60 seconds would have regressed us back to multiple orphaned blocks per day. Since the data is there to look at, it's puzzling that you seem to deny the effect.

@Murch, did SegWit reduce the average block size by a factor of 10? If not, then presumably the data you’re citing isn’t addressing my point. I do understand now (not that I did in 2016 when I wrote that answer) that shorter block times also increase asymmetric advantages for coalitions of hashrate such as pools which see their winning blocks instantly (no propagation delay). So excessive orphans could be selfish mining in action. Note Ethereum’s variant of GHOST is a partial solution to some of that.

authors: Максим Устьянцев


text:
How to move wallet.dat from Bitcoin Core into Electrum?
I've got a wallet.dat file from Bitcoin Core and I'd like to move that into electrum because I can't open Bitcoin Core as the syncing process takes forever and eventually fails. I also read that electrum won't read wallet.dat files. Is there any other way to do this?
I tried to run ...
$ bitcoin-cli dumpwallet "test"

but if I understand this correctly, I need to run bitcoind, and this fails on startup because of an error in debug.log like
LevelDB read failure: Corruption: block checksum mismatch
Fatal LevelDB error: Corruption: block checksum mismatch
You can use -debug=leveldb to get more complete diagnostic messages
Error: Error reading from database, shutting down.

In sum, I can't get the private keys using bitcoin core because upon startup, I get errors like the above.
Thoughts?

I looked at that post which uses bitcoin-cli to dump, but I can't run bitcoind in order to run the cli and issue a dump. Am I understanding this correctly that bitcoind needs to run so that bitcoin-cli can connect to it?