1,500% transaction fee and 3,5 months to confirm? So my service is skimming a tiny 0,001% (1/1,000) fee off every payment that gets through it. Most of the transactions are actually micro-payments so there are thousands of tiny unspent outputs accumulating in the service's wallet. I'm worried now that I will not be able to spent these outputs without having to pay a load of transaction fees and wait for eternity for this payment to clear.

The average btc value of my unspent outputs that come out of the commissions is 100 satoshis (0,000001 btc). That means that if I want to cash out 100 btc, I need to spend on average 100,000,000 of these outputs.

According to: How to calculate transaction size before sending the transaction size is: in*148 + out*34 + 10 plus or minus 'in', which makes my withdrawal equal to: 100,000,000*148 + 2*34 + 10 + 100,000,000 = 14,900,000,078 bytes = 14,9 GB ?! (am I missing something here?)

The maximum block size is 1 MB so I will need to split this transaction in more than 14,900 transactions of 1,000 kB each ?!

A transaction fee of 0.0001 btc per kB is required, so I will need to spend 0,0001 * 1,000 =  0,1 btc for each of these 14,900 transactions which means I will need at least 1,490 btc (to send 100 btc), which is roughly 15 times the amount I'm trying to send!

All these 14,900 transactions will need to be included on different blocks (since they would exceed the maximum block size otherwise) and since one block is found every 10 minutes on average, I will need to wait 14,900 * 10 minutes = 149,000 minutes = 2,483 hours = 103 days = 3 months and a half ?!

Please tell me I got this all wrong. I've really freaked out.

Edit1: Thanks to Nate Eldredge for pointing out an error in the calculations.

You're doing it wrong if your service generates thousands of dust-sized outputs. You need to consolidate your outputs as you go.

I assume that a transaction under your current model is like this:

Input (x1):
Payer Address (X BTC)

Outputs (x3):
Payee Address (Y BTC)
Service Wallet Address (100 satoshis)
Payer Change Address (X - Y - 0.00000001 BTC)

What you should do is to keep the Service Wallet Address accumulate the 100 satoshis as you go:

Inputs (x2):
Payer Address (X BTC)
Service Wallet Address (Z BTC)

Outputs (x3):
Payee Address (Y BTC)
Service Wallet Address (Z + 0.000001 BTC)
Payer Change Address (X - Y - 0.000001 BTC)


Not possible to load the blockchain in multibit so can't pay or recieve either till it's loaded "C:\Users\Pompen\AppData\Roaming\MultiBit".
 "C:\Program Files\MultiBit-0.5.18".
Unable to load blockchain "C:\Users\Pompen\AppData\Roaming\MultiBit\multibit.spvchain". The error was "com.google.bitcoin.store.BlockStoreException Corrupted block store: could not find chain head: 0000000000000000139072ad82693ddc93b29fca541778907aced232b031072b".
Opening wallet "C:\Users\Pompen\AppData\Roaming\MultiBit\multibit.wallet"...
... done
Opening wallet "C:\Users\Pompen\AppData\Roaming\MultiBit\Naamloos.wallet"...
... done

Then it shows these messages:

Starting blockchain replay from network...
Replaying blockchain from date "7-May-2015"
Stopping Bitcoin network connection...

And this error:
**17:56:34.604 [SwingWorker-pool-2-thread-2] ERROR org.multibit.network.ReplayManager - Cannot download blockchain as there is no PeerGroup**

Have a read of this support note on multibit.org which looks like it covers that error:
https://multibit.org/en/help/v0.5/help_support_blockStoreException.html

BlockStoreException
You see a BlockStoreException very occasionally when MultiBit starts. It prevents you synchronising with the Bitcoin network.
You can fix this problem by doing the following:

Find where MultiBit is storing your user data - see the help topic Troubleshooting

Shut down MultiBit

Go to your MultiBit user data directory - worked out in step 1 - and delete the file multibit.spvchain

Start up MultiBit again

It will then regenerate this file and start syncing. After it has synced you should see all your bitcoin in your wallet..


Shapeshift + bitcoin cash question. The deposit link expired before the deposit reached it At first, the transaction stayed unconfirmed, and then, four hours later, it had one confirmation, and now, two days later, the blockexplorer says it has 247 (?) confirmations, but the wallet still says it has two and is pending.  I figured that when the amount will reach Shapeshift, they will issue an automatic refund although the blockchair says that the main part of the deposit is already sent and spent. I tried to use CPFP while it was still unconfirmed to draft the funds back, but it seems like I misunderstood the function. Can anybody tell me what's the problem, if it's stuck for centuries or how to speed it up? And it is actually a second time in a row I get into this situation. Anyway, would anybody just sort out my confusion?
41cd7bb49bab97d82063f5fde1b2e5b9e8cb2cbc1faba65a938d70c69dbce8a7

See also Why is my transaction not getting confirmed and what can I do about it?

  the blockexplorer says it has 247 (?) confirmations, but the wallet still says it has two and is pending.

Sounds like an issue with the wallet not an issue with the transaction. Indeed, the transaction has many confirmations now, contact the support for the wallet you are using to see what the issue is (or ensure your wallet is fully synced if you are using a local wallet).

  I figured that when the amount will reach Shapeshift, they will issue an automatic refund although the blockchair says that the main part of the deposit is already sent and spent.

Why would you get a refund if you are just depositing the funds?

  I tried to use CPFP while it was still unconfirmed to draft the funds back, but it seems like I misunderstood the function.

If you sent the funds to an address shapeshift owns, only they can spend that transaction, so only they can use CPFP. But CPFP is unnecessary here because the transaction is confirmed now, as you mentioned.

  Can anybody tell me what's the problem, if it's stuck for centuries or how to speed it up? And it is actually a second time in a row I get into this situation. Anyway, would anybody just sort out my confusion?

What makes you think it is stuck? The transaction was successful, if your account hasn't been credited in shapeshift then you will need to contact their support.


Do lightweight wallets validate signatures? If not, why? I've learned that "some SPV clients simply don’t check signatures themselves at all": https://bitcoincore.org/en/2016/01/26/segwit-benefits/#efficiency-gains-when-not-verifying-signatures

I wonder if popular lightweight wallets (like Electrum) nowadays do signature checks? If not, why?

Some lightweight wallets do not check the signatures because checking the signature requires data from the previous transaction. However lightweight wallets generally will not have the previous transaction to fetch the data from and are thus unable to verify the signatures.


Are there any mining pools that publish what transactions they will include? If some large number of the mining pools started publishing what transactions they are planning on including the danger of accepting a zero confirmation transaction would be reduced dramatically.

Has there been any thought on this that I could read up on?

Knowing won't help
You are effectively looking for a centralised entity to provide you with a prediction of the future behaviour of a decentralised entity (asking a mining pool to predict the blockchain).
Even if one or more mining pools share this information, I do not believe it will provide you with a significant risk reduction in accepting transactions with zero confirmations.
Knowing that the transaction has been accepted by a mining pool simply means that it is a valid transaction with a sufficient fee for that pool. This gives no guarantee that it will not be orphaned by a rival block or rejected from another pool in favour of another transaction which double spends the same input(s) with a larger fee. These things may not have a high probability but if you're going to assume they won't happen then you are accepting a small risk of the transaction failing. This risk is there regardless of whether the pool has announced it is including the transaction.
The sender can still attack
The transaction still has zero confirmations and it is only in the case that the transaction sender is not an attacker that you could trust that the transaction will eventually be confirmed. If you are trusting the sender not to be an attacker then you do not need an announcement from a pool. It is unlikely the sender would accidentally send an invalid transaction or one without sufficient fees. If you do not trust the sender then you should wait for an appropriate number of confirmations (depending on the level of risk you wish to accept and the resources you estimate the sender has).
For amounts you are prepared to risk losing, you are of course free to accept payments with zero confirmations. My point is that the risk involved with accepting unconfirmed payments is much the same regardless of whether a mining pool has stated that they will include a transaction.
Miners are free to change their mind
As Peter Michael Lacey-Bordeaux points out in the comments to Scott's answer, there is nothing to stop a mining pool changing which transactions it includes at any time. The calculation of which transactions to include is short, whereas the search for a valid block hash is long. Given that no hash has yet been found, there is no disadvantage in abandoning a given block of transactions in favour of a slightly different block which includes some higher fees. This means the sender can attempt a double spend without any mining resources at all. This is no threat to people who wait for a few confirmations, but should be considered by people who wish to accept unconfirmed transactions.
The expected time until a valid hash is found (by someone, somewhere) is approximately 10 minutes (depending on how recently the difficulty has been updated). If 7 minutes have already elapsed, the expected remaining time is not 3 minutes. It is still 10 minutes, because the process is an exponential distribution which makes it memoryless. So starting afresh with a new block of transactions doesn't have any effect on the expected time to find a valid hash, but it may increase the total fees. There is therefore an incentive for a miner to keep restarting the search with a more up to date transaction block, and the same incentive will apply to any pool equipped to do so.
In summary, even if mining pools did announce transactions to be included, I would definitely not rely on that information.


How can I track all trades at an exchange such as GDAX Can I track all trades on an exchange, not just my own. Is it possible to assign a trade to an anonymous figure then continue to track that figure?

"Can I track all trades on an exchange, not just my own" yes. visit https://docs.gdax.com/#get-trades for additional information. this trades are afaik anonymous so you can not track who did which trade.


How to connect to a remote Bitcoin Core remotely If I have 24/7 running bitcoind on a headless server, is there a graphical way to connect, maybe only temporarily to the server's Bitcoin Core daemon or its client to see if everything is going smoothly on the server?

I found a plausible answer which did not work for me, but almost!

To start it up, follow this:

Install xpra both on the server, and on the client. On Debian-like OS it would be:

sudo apt-get install -y xpra

Temporarily stop the Bitcoin Core daemon on the server:

bitcoin-cli stop

Over the first SSH connection, start xpra on the server like this:

xpra start :7

Over the second SSH connection, start bitcoin-qt on the server like this:

DISPLAY=:7 bitcoin-qt

Connect xpra from the client to the server like this:

xpra attach ssh:SERVER-IP:7

After you have finished your work, follow this:

Close Bitcoin-Qt on the client
Press CTRL+C in this window and close it:

xpra attach ssh:SERVER-IP:7

Press CTRL+D in this window and close it:

DISPLAY=:7 bitcoin-qt

Press CTRL+C in this window and don't close it:

xpra start :7

Issue this command in the SSH session to the server:

xpra stop :7

And finally start your Bitcoin Core daemon again with or without a wallet:

bitcoind -daemon -disablewallet


How can I generate a bitcoin address? Is there any way to generate bitcoin addresses  other than the Blockchain API? (given the fact that it is not public)

There are a number of sample programs here: https://bitcointalk.org/index.php?topic=1026.0

Also see the wiki for the step-by-step algorithm for generating a valid address.


Why a transaction couldn't be found with bitcoin-cli after 11 confirmations? I made a new address with bitcoin-cli getnewaddress:

39WqU8NJJasFjmaS2J4424UGVJn8Tqvh82

Then I initiated a transfer from some online service.
The transaction is displayed with 11 confirmations:
https://www.blockchain.com/btc/tx/cc09117205515389ed618acd31b6e691e363446c5ce5cce94b24cc74701fbd74

Now, I am trying to verify this with bitcoin-cli:

$ bitcoin-cli listreceivedbyaddress 0 true true 39WqU8NJJasFjmaS2J4424UGVJn8Tqvh82
[
  {
    "address": "39WqU8NJJasFjmaS2J4424UGVJn8Tqvh82",
    "amount": 0.00000000,
    "confirmations": 0,
    "label": "",
    "txids": [
    ]
  }
]

$ bitcoin-cli gettransaction cc09117205515389ed618acd31b6e691e363446c5ce5cce94b24cc74701fbd74
error code: -5
error message:
Invalid or non-wallet transaction id

$ bitcoin-cli -getinfo
{
  "version": 190100,
  "protocolversion": 70015,
  "blocks": 481192,
  "timeoffset": -1,
  "connections": 10,
  "proxy": "",
  "difficulty": 923233068448.9053,
  "chain": "main",
  "walletversion": 169900,
  "balance": 0.00000000,
  "keypoololdest": 1584106964,
  "keypoolsize": 997,
  "unlocked_until": 0,
  "paytxfee": 0.00000000,
  "relayfee": 0.00001000,
  "warnings": ""
}

What should I do in order to verify locally success of the transaction?

Why balance didn't increase?

The node is configured with prune=4096.

Your node is not fully synced, when you posted this it was only synced up to block 481192 (look at blocks under getinfo).

Once the node catches up to the chain tip the tx should display properly.


Time/memory complexity of Bitcoin API calls Is there a way to see the time/memory complexity of Bitcoin's API? For example, bitcoin-cli getblock "some-header-hash" fetches the block with a matching hash.

How is this implemented under the hood? Does it do a linear scan of the entire blockchain all the time or does it keep a (key, value) table where keys are header hashes? I'm concerned with the implementation as given in http://chainquery.com/bitcoin-api.

Bitcoin Core maintains a LevelDB database (a key-value database) that contains the chain status data. This data includes the block headers, the block locations on disk, the UTXO set, and a few other things.

For blocks, the chainstate database has the block hashes as the key and block headers with some extra data appended as the values. The extra data also includes the block's location in the blk*.dat files (file number and byte offset within the file for the beginning of the block). So looking calling getblock just means that the key-value pair for the block hash is taken from the LevelDB database which I believe is O(nlog(n)) (IIRC it uses some kind of tree as the backing structure). To get the block itself, the lookup is O(1) as it just has to read a specific file at a specific offset.

Very few RPC calls in Bitcoin Core actually do any sort of searching through the blockchain. Most things are either stored in a database or a reference to its location is stored in the database so the item itself can quickly be retrieved by or following a database read.


Are loans with enforced repayment possible on the blockchain? Are loans with interest possible in Bitcoin, such that repayment is enforceably encoded with Bitcoin Script on the blockchain from the establishment of the lending contract?

What do you mean by "loans with interest"? If you mean guaranteeing being
payed back the principal plus some interest that is not possible since
that depends on the external world (i.e. it is offchain).

On the other hand, if you mean just creating repayment links for the agreed amounts it is just following the instructions of BIP21.


A life-cycle of a transaction - correct? Newbie alert ! Please let me know if this is not the right forum.

So I have spent time reading up on Bitcoin. I think, I understand now; but, would love to have it confirmed.

To start with, we have a transaction, t1 as below.

t1 : {a1, 50.00 BTC, a2}

Where,
t1 is the transaction that goes to the block-chain (ledger) for confirmation.
a1 is the input, for example, Mt Gox from whom 50.00 BTC were purchased.
a2 is the output address who purchased the bitcoins from Mt Gox.

After t1 is confirmed, the unspent amount of a2 is 50.00 BTC.

Let us say, a2 wants to send 40.00 BTC to a3 for some service. Then, a new transaction t2 is created as below.

t2 : {a1, 40.00 BTC, a3}

As before, t2 goes to block-chain awaiting confirmation. The input to t2 is a1, amount 40.00 BTC and the addressee (or recipient) is a3.

Are the following correct ?

t2 has input address as a1 as described here - What does a transaction look like?
Because t2 does not mention a2, the anonymity of a2 is preserved.
t2 is confirmed because unspent balance of a2 at this point is 50.00 BTC. (Not sure how, but sounds like it.)
After t2 is confirmed, unspent balance of a2 is 10.00 BTC.

For reference, I used the following.

t1 : eac977ae6ee885b62c4756230f6bdd27ccfa7de215836e6f5fc379c66f4c6a81
a1 : 1LNWw6yCxkUmkhArb2Nf2MPw6vG7u5WG7q
a2 : 16fKtcRS2P57pH6dF5stJ4wF1SC4SzaMJK

and,

t2 : c8a8db01733a4300ad14e1fd78ff776ec21260e7081dd48c7b2f5ad1a9a1da46
a3 : 1Cmerw473xaaNpR6T9Lo5DA6d99uXLe3gc

Transacions don't have input and output addresses, they have input and output scripts. Addresses are just short-hand notation for particular scripts.

When making a transaction, you don't just say what the input and output scripts are. You have to explicitly reference which UTXO (unspent transaction outputs) a transaction spends, and then you also make a set of new UTXOs. Each UTXO has an amount associated with it.

  t2 has input address as a1 as described here - What does a transaction look like?

If t2 is trying to spend the coins that were sent to it in t1, then it would need to reference t1 (not a1 or a2). Specifically, it would need to reference the UTXO in t1 that credited the a2 script.

  Because t2 does not mention a2, the anonymity of a2 is preserved.

Not really. Anonymity is only preserved by not linking your address to your name, such as by posting on a social media website.

  t2 is confirmed because unspent balance of a2 at this point is 50.00 BTC. (Not sure how, but sounds like it.)

If t2 were confirmed, spending the UTXO made in t1, then, yes, it would be successful because the total inputs is more than the total outputs. Actually, it's total inputs are 10 BTC more than it's total outputs, so that 10 BTC would just go to the miners (and not be left on the 'address balance').

  After t2 is confirmed, unspent balance of a2 is 10.00 BTC.

Not actually, like mentioned above, it doesn't really work like that. Transaction outputs are either completely spent or are unspent. So after t2, the output is completely spent. If the 10 BTC is not sent to another output in t2, then it is just assumed to be a very generous miner fee.


How does the bitcoin network recover in case of a hash collision in the block hash? A Bitcoin client has to download the whole blockchain from the P2P network in order to become a full node.

A full node is able to determine, if a transaction in the network is valid or not.

To download the blockchain, the client queries other peers in the network for more blocks by providing them with the hash of the last block it has currently in its downloaded blockchain.

The other nodes search in their currently best blockchain for the specified hash and return a list of hashes of further blocks the client can download.

After the client determines that the further block hashes are indeed in the longest block chain by crossvalidating other nodes, it requests those blocks from its peers by giving them the hashes of those new blocks.

After the download, it checks for itself that the blocks follow the rules of the bitcoin network and inserts them in its current blockchain.

This algorithm assumes that any valid block in the blockchain has a unique hash that identifies it.
What happens, if by chance a block is inserted in the blockchain that has the same hash as a previous block and that complies with all rules of the bitcoin network?

Wouldn't that break the algorithm?

It would not break the algorithm.

As the inventory vector of the described new block would be a duplicate of an already known block, no other node would request this block. It would just be ignored, as if never discovered in the first place. Everybody else would still be hashing away happily, obsoleting the block eventually.

Tough luck for the miner, he'd not get the reward, because everybody would be convinced that no new block has been found at that height yet.

Of course, chances of that happening are negligible, because the block hash is a random 256 bit output (smaller than the current target), which allows for an immense number of possible hash outputs of a similar magnitude as the address space.

Actually, @NickODell made me aware that it can cause a problem, when nodes see the newer block before the older block that was already part of the longest chain. In that case the node would be unable to synchronize, as it would not be able to build the complete chain.


Where can I find the backlog of Bitcoin transactions? I would like to see and track the evolution of the backlog of Bitcoin transactions. Is there a website that does that?

Thank you!

David

Yes, there are some (in order of preference):

https://jochen-hoenicke.de/queue/#24h
https://blockchain.info/unconfirmed-transactions


What date does the 2016 halving happen at? When does the 2016 halving happen? Is it a predicted date or could it be when network load is achieved?

The first block with the halved block subsidy is 420,000. However, blocks are discovered in a random process – whereas the protocol aims to have blocks found approximately every ten minutes, in effect blocks are currently found about every 8.94 minutes. Therefore, one can only estimate the precise arrival of the Halving:

thehalvening.com estimates 2016-07-10 – 10:24 UTC
bitcoinclock.com estimates 2016-07-10 – 05:39 UTC
bitcoinblockhalf.com estimates 2016-07-10 – 10:10 UTC

It's not clear from the sites whether they rely on the current measured block interval or the theoretical ten minutes for their estimates. So far, it seems to me that the time has mostly been overestimated, earlier predictions were for later in July.

It seems therefore likely to me that the halving will occur on the 8th, 9th or the 10th of July. Naturally, any predictions will increase in accuracy as the halving draws nearer.


Bitcoin-qt console on cmd Is there a way to interact with Bitcoin-qt from Windows cmd and run commands like if I'm running them from Bitcoin-qt console?

While you have bitcoind or bitcoin-qt running with the -server option, you can then use bitcoin-cli to run commands.

It's part of the bitcoind package.

If you have your conf file in a custom directory you'll have to specify that to bitcoin-cli as well, otherwise it should just work.


How to sweep a segwit bech32 private key? I'm testing segwit bech32 addresses and generated the following using bitcoinjs:

address: bc1qc7u5njf4nf2rj3zys642mfc7nct6kdven8j4e9

private key: 5Kkzs8XrJNAmf9VQDFeGBfaRvSByAvPK6DbDXw5BVqswWaXSG2Y

When I import this private key into electrum 3.0.5, it imports it as the following address: 1KD3SE71kGAcxw57BvcmUzsHwx3QxdPBW7

How do I go about sweeping funds from the bc1... address if electrum 3.0.5 sees the legacy format address instead?

Use Electrum 3.1.1 and prepend "p2wpkh:" to the private key before importing or sweeping it. For example:

p2wpkh:5Kkzs8XrJNAmf9VQDFeGBfaRvSByAvPK6DbDXw5BVqswWaXSG2Y


Pegged sidechain vs. Lightning Network? How is the Elements Project's pegged sidechains concept similar to and different from the Lightning Network's payment channels concept?

Although Lightning Network is completely different and maybe not best to compare both, things that are easier with Elements or only possible with Elements right now:

Issue assets: https://elementsproject.org/elements-code-tutorial/issuing-assets

Confidential Transactions (Amounts hidden)

Hardware Wallet for Liquid(An implementation of Elements)

Tether (USDt)

TDEX: Protocol to build decentralized exchange for trading assets issued on Liquid (An implementation of Elements)

Simplicity: https://github.com/ElementsProject/simplicity

Covenants: https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 (Maybe soon possible on Bitcoin as well)

LN is also possible on an implementation of Elements: https://twitter.com/notgrubles/status/1355547472827834373
Few differences between Lightning Network and Liquid (An implementation of elements) mentioned in https://blog.liquid.net/six-differences-between-liquid-and-lightning/

Transaction size: the size of payment each Lightning channel can process is limited by the size of the initial funding transaction used to set it up. This makes it less likely that, as transaction size increases, a complete pathway from buyer to seller will be found, making the Lightning Network less reliable for large transactions.
There are no limits to the size of a transaction on the Liquid Network (technically 21 million BTC would be the limit!). A user can peg in as much BTC as needed and start transacting immediately. Recipients also do not need to engage in any channel preparation, they can receive as much as a sender can send. Since Liquid operates on its own blockchain, the number of transactions it can handle is subject to a blocksize limit Fees are currently very cheap (0.1 sats/vbyte for next-block confirmation), but as Liquid adoption grows fees are expected to increase which will make micro transactions unviable on-chain.

Speed: Payments via the Lightning Network can be made almost instantly. Since Lightning payments do not require confirmation on the blockchain they can take place as quickly as an internet connection will allow: potentially allowing for millions of transactions per second.
New Liquid blocks are produced at regular one-minute intervals—ten times faster than the average Bitcoin block—and two confirmations are required for a transaction to be considered settled. This means that Liquid transactions take around two minutes.

Privacy: a degree of monitoring is still possible with Lightning since individual nodes can record the channel and direction information from transactions they are asked to process. While this method of surveillance has limitations, it still represents a privacy concern.
In contrast, the Liquid Network’s protocol is designed so that the amount of funds and type of asset transferred are not revealed to anyone other than the sender and recipient. This is made possible by a cutting-edge cryptographic protocol developed by Blockstream called Confidential Transactions.

Trust model: Liquid’s trust model is based on a federation consisting of 15 hardware security modules (HSMs) attached to host servers (known as functionaries). The functioning of the BTC:L-BTC two-way peg relies on two thirds or more of the Federation functionaries acting honestly.

LN privacy issues are also explained in https://abytesjourney.com/lightning-privacy/


Can't spend Watch-Only coins, have I been scammed? Inspired by Murch's format of Why is there no such thing as a redirected, forged, or fake transaction? to create one question that is well-worded and accessible through search engines.

Recently, I've imported an address to my wallet that contains the bitcoins I have earned. Now I want to spend them, but my wallet shows it as "Watch only" or "Non spendable" and says "Private key for address not found"

How can I claim back my bitcoins and spend them?

D U
P
L
I
C
A
T
E
S

A watch-only address means an address your wallet is tracking the balance of, and not more than that. To own an address, which means to be able to spend from it, one is required to know its private key. All addresses generated by a wallet software have their private keys stored by and known to the wallet.

A common scam using watch-only addresses is as below:

A user is told "invest today, earn 100 times soon"
The victim pays the malicious actor.
Later the malicious actor says "We have your profits, now you need to import them to your wallet"
The victim is instructed to import the address as "watch-only" to their wallet and not the private key required to spend the coins.
It takes time for the victim to notice that they can't spend their balance. However, the malicious actor has already vanished.

Remember that Bitcoin is a cryptocurrency, which means it's possible to make transactions!!! If the malicious actor was honest, he'd ask for the user's address so that they could make a transaction and send their earnings, but importing to wallet should always be considered fishy.


Does the mempool size equal roughly the unconfirmed transactions? My bitcoind (v0.13.0) mempool size is currently 12k transactions as can be seen from:

tail -f ~/.bitcoin/debug.log

I find this number very surprising as I naively expected it to keep in line with the number of 'Unmatched transaction' as reported say by blockchain.info which currently shows 3k transactions.

https://blockchain.info/unconfirmed-transactions

What am I missing?

Every node owner can set their own policy for the mempool. The mempool is limited two-fold:

With -maxmempool=<n> you can set an explicit limit of MB that it will not exceed. The default is 300MB.
Transactions that don't surpass the minRelayTxFee are not added to your mempool.

As statoshi.info has the mempool at 145MiB and ~11k transactions, it appears likely that different settings on the minRelayTxFee seem to cause your and blockchain.info's divergent mempool size here.


Does the version prefix of an address force the type of transactions the address may treat? A Bitcoin address is created with Base58Check encoding and it requires a version prefix, such as 0x00 for a P2PKH(pay-to-public-key-hash) address, 0x05 for a P2SH(pay-to-script-hash) address.

Does the version prefix of a Bitcoin address force the type of transactions the address may treat, or is it just for indicating the appropriate one?

In other words, can one do:

Generate a ECDSA key pair.
Create a Bitcoin address with it, with a version prefix 0x05.
The generated address is a P2SH(-like) address; at least its format is.
Make a P2PKH transaction with it.

Since addresses are only human abstractions and do not actually exist on the network, no, addresses do not force the type of transaction that you can create with the data provided in an address. There would be no way to enforce that. However creating a transaction that does not use the type that the address specifies is a good way to lose funds because the way to spend those outputs are different.

So yes, you can take a P2SH address and create a transaction with a P2PKH output that has the same data that the P2SH address provided. But the person who controls that P2SH address is not going to be able to spend the coins from the P2PKH output since the requirements for spending will be different.


How to setup bitcoin network using regtest? My question might seem really basic , but I am looking for help as to how can I setup bitcoin network using regtest?

2 ways.

bitcoind --regtest --printtoconsole
Configure bitcoin.conf and include a line regtest=1.

Second way is better so usage of bitcoin-cli is less verbose.


How does Bitcoin verify that a user owns the bitcoins he/she spent? I'm making my own blockchain based currency for a school project and kind of hit a roadblock. I have a wallet class which initializes with zero coins. What prevents the user from just sending a transaction, if he doesn't own the spent coins. Bitcoin is anonymous, so it doesn't save the balance of each account, right? So you could just reprogram a wallet to not subtract the spent amount from your balance? How does Bitcoin prevent this? Thanks in advance.

Bitcoin doesn't really care about balances, accounts, people or ownership. It doesn't need to know about any of those things.
Read the above sentence again. It is true. It has many important implications.
Bitcoin is cash, not an account. There's no system that tells a pizza storekeeper how many $10 bills (banknotes) you have under your mattress. The pizza storekeeper doesn't care. They only care that the $10 bill you hand them is not fake.
They don't need your ID. They don't need your name. They don't care whether you don't have a bank account. They don't ask you who owns that $10 bill, because they don't care who paid for the pizza - only that it gets paid for at all.
Don't let the terminology confuse you. The bitcoin blockchain isn't a ledger that keeps track of balances. It is a transaction journal that records only half of a real-life transaction - the half where A gives B some Bitcoin money, not the half where B gives A a pizza.
The transaction has inputs and outputs. The inputs are "coins" that A is giving up and the outputs are typically a new "coin" that B is getting and a new "coin" that A gets back as change (since Pizzas rarely cost exactly $10).
A Bitcoin "coin" is really just an output amount from an earlier transaction that has not yet been spent in a subsequent transaction. It is an Unspent Transaction Output (a UTXO).
Bitcoin nodes just keep track of UTXOs. When a UTXO is spent, the U in its name no longer applies. Every node observing the spend removes that TXO from its list of UTXOs. So every node seeing a second spend of a TXO would know that TXO is now not a UTXO and reject that second spend as invalid.
If a wallet reports a false balance to its owner, no one is harmed but the owner. A fake balance does not enable you to spend money you don't have. Its like a leather wallet that has "$30" written on the outside but which only contains two $10 bills.
That's the difference between bank accounts and cash.


How to import a private key to an encrypted wallet (on standard client) I have a standard client (QT client on OSX) with an encrypted wallet. I've tried to import keys with pywallet, but while it claimed to be importing them, when I ran again the bitcoin client, it said wallet.dat was corrupted (yes the client wasn't running when I did the import).

I guess pywallet doesn't know about encryption and didn't care enough to check everything was ok before importing them.

So, how do I do this import?

Trying to run the command line client gets me the following error a few seconds after starting it (with -daemon option of course):

EXCEPTION: NSt8ios_base7failureE
CDataStream::read() : end of data
bitcoin in AppInit()

Running the QT client with the -server option crashes too after a while (apparently it works correctly without that).

Since 0.6.0, key import/export are available in the client itself, though only through RPC. The commands are called dumpprivkey and importprivkey. For example (on testnet):

  $ ./bitcoind getnewaddress

  n2JjZgLeCUgfubswxDm9zAaBGSLLHSLdNv

  $ ./bitcoind dumpprivkey n2JjZgLeCUgfubswxDm9zAaBGSLLHSLdNv

  cR4RtpaeAZY8MwrNvTQGX9PZ9pdCgFoLxuo4Pkwqx61broC4Gb4y

And on another wallet:

  $ ./bitcoind importprivkey R4RtpaeAZY8MwrNvTQGX9PZ9pdCgFoLxuo4Pkwqx61broC4Gb4y

  $ ./bitcoind validateaddress n2JjZgLeCUgfubswxDm9zAaBGSLLHSLdNv

  {
      "isvalid" : true,
      "address" : "n2JjZgLeCUgfubswxDm9zAaBGSLLHSLdNv",
      "ismine" : true,
      "pubkey" : "029e3a934cfc9f89d7a1c15f99b98479cabc81964f4972e7b8fa3989a788261695",
      "iscompressed" : true,
      "account" : ""
  }


Security concerns with walletpassphrase I have some security concerns with walletpassphrase:

If it stores the passphrase for some unit of time. ie. so you can send funds, surely if the server is compromised, within that timeframe, the attacker can obtain the passphrase in its raw format?
If I have somehow misunderstood, ie. perhaps the raw passphrase isn't easily accessible (how?), an attacker could still empty the wallet within that timeframe seeing as the wallet is in an decrypted state.

All roads are leading me to use bitcoin libraries that allow me to create transactions and sign them using encrypted private keys that are only decryptable at the time of signing. I feel way more comfortable using my node for transaction broadcasting / indexing capabilities. Rather than leveraging its in-built wallet.

Wallet encryption protects funds at rest, it does effectively nothing about protecting funds on a live machine that has loaded the wallet to make a transaction.
There's no expectation that the passphrase will do anything in particular to protect online wallets on machines that contain malicious software, as you've surmised.


I transferred about 0.54 BTC and I cannot find this on Blockchain.com. Can anyone help? I'm hoping someone more onto it can help me find or understand exactly what happened when I xferred my BTC from an exchange (Dasset) to my wallet.

I transferred about 0.54 BTC to bc1ql8wxn65d7crka2gr4f3gcgnynv23hvqg6akxef

When I searched for transactions under this address nothing appears on Blockchain.com.
I know I have transferred to this wallet before but I can't even see those transactions.

Thanks in advance.

Firstly, I would use Blockstream.info or mempool.space, not blockchain.com for your online block explorer.

Second, depending on the exchange, they could batch withdrawals at a certain time each day, or they could set a very low fee, which means it would take a long time to be confirmed.

As was said in the comments, you could've been scammed. I have never heard of Dasset before.

Lastly, for each transaction, generate a new receive address to ensure privacy.


Why outputs' spendable and solvable are false? I noticed a transaction whose spendable and solvable are both false, what does this mean and why?

 {
    "txid": "c940241a0ef626e865e2004bc120536fb7868d510115e923c76d5e658a97f6d5",
    "vout": 0,
    "address": "mnbFFLXUqTPBweLm6w1GA2ZAJQbrTndEGC",
    "account": "",
    "scriptPubKey": "76a9144d98b2350032c849ac6e6e7ad0eb88e00fd7fbff88ac",
    "amount": 1.10000000,
    "confirmations": 132,
    "spendable": false,
    "solvable": false
},

Is this means this utxo is invalid somehow so cannot spend it?

Also, this is on testnet.

The listunspent rpc call returns all unspent transaction outputs (UTXOs) tracked by this wallet. This includes the UTXOs that can be spent by this wallet, but also UTXOs that belong to watch-only addresses tracked by this wallet.

When spendable is false, this wallet does not have the private key to spend the UTXO. This is e.g. the case for watch-only addresses.

When solvable is false, the wallet does not know how to spend the UTXO, regardless of whether it has the corresponding private keys.


If all Proof of ... systems use mining I understand how Proof of Work (PoW) works now, and am beginning to look at different Proof of ... systems like these:

Proof of Stake
Proof of Ownership
Proof of Existence
Proof of Space

From what I have read so far, it sounds like the term "Bitcoin Mining" means Proof of Work in the Bitcoin system. But then I'm not sure if mining is an inherent part of all these other systems and if it works in a similar way. If not, I'm wondering what the general meaning of mining is across these different "Proof of ..." systems.

The term mining is most specifically applied to Proof of Work consensus mechanisms. This is because verifying a bitcoin block is a rigorous process of hashing the block header until you find the block header hash that matches the current difficulty goal. New bitcoins are generated in the process (incentivizing mining) and hence the term mining.

Proof of Stake - In this consensus protocol, all the hard limit on the coins are outstanding on day 0 of the blockchain. This can achieved mostly through ICO. Now, the validators in this protocol stake their coins as a collateral in the network. The collateral serves as a guarantee that the validators do not act in a malicious way as they can lose their collateral. Every validator gets selected at random to verify a particular block. The chance of getting selected is proportional to the amount of money that is staked. The validators collect only the fee of the transactions in the block. The validators in Proof of Stake are called forgers or minters.

Proof of Ownership - This is not a consensus protocol. It is a byproduct of the blockchain that allows you to track the owners of certain information. The most glaring example would be colored coins. This is stored in the transaction as a metadata using a OP_RETURN opcode.

Proof of Existence - Again, this is not a consensus protocol and is basically a byproduct of the blockchain that allows you to verify that a particular record or transaction exists on the blockchain. This can be verified by different parties independently.

Proof of Space - This is a consensus protocol that leverages disk space rather than computational power. To mine blocks using PoSpace miners invest disk space to the network, with the probability of mining the block proportional to the space allocated as compared to the total capacity of the network. A PoSpace is a piece of data that the prover send to the verifier to show that he has reserved a certain amount of space. Without reserving that much amount of space, there is no way the prover can send that data. One way in which PoSpace can be implemented is by using hard-to-pebble graphs. The verifier asks the prover to build a labeling of a hard-to-pebble graph. The prover commits to the labeling. The verifier then asks the prover to open several random locations in the commitment.


Tracing solo miners and anonymity Can one, theoretically, write a program that is similar to a solo miner but instead it just logs IPs of other computers on the bitcoin net to trace IPs that might have bitcoin wallets on them and then to use that list as a preferable hacking list ?

I think we can differ between 3 types nodes:
1. people running just the bitcoin client as a wallet
2. people solo mining
3. people pool mining

I am almost sure that the 3rd option is not traceable (assuming the pool servers are secure).
What about the detectability of the first 2 (especially the solo mining).

Not only can you write such a program, you probably already have one.  If you run the standard Bitcoin Core client, you will see that debug.log logs the IP addresses of every network node it communicates with.  (It's irrelevant whether you use the client for mining or not - even non-mining nodes need to connect to peers, and could keep track of which peers they have found.)

On the one hand, an attacker could consider these targets more tempting, on the grounds that there might be bitcoins stored on those machines.  On  the other hand, since at present Bitcoin users tend to be more  technically skilled than the general public, these machines might be better secured than the average computer on the Internet, making them harder targets.

Ordinary clients and solo miners are both likely to run regular Bitcoin clients.  I don't know of any reliable way for an attacker to tell whether a node is mining or not.  The best approach might be for the attacker to have a large number of nodes, each connected to a large number of peers, and watch for the first appearance of a new block.  The first node to have sent out that block is somewhat more likely to be the miner that found it - but the attacker can't rule out the possibility that that node was simply relaying a block sent to it by someone else.

Anyway, it's not clear that a solo miner would be a more profitable target than anyone else on the network - miners don't necessarily store their earned coins on the mining machine.  The attacker could take control of a solo miner and make it mine for her instead, but odds are that she would be discovered long before the miner finds a block.  (She would certainly be discovered as soon as it did find one, when the miner notices that the block reward didn't go to the right place.)

Pool miners don't need to participate in the peer-to-peer Bitcoin network, so they could not be discovered in this way.   The pool operator can run a regular Bitcoin node that looks no different from any other node.


What is the cheapest device that can run a proper bitcoin client? What is the cheapest hardware device that can run a proper bitcoin client that can participate in the P2P network?

Go your local goodwill/thrift/whatever.  They have usually old PCs for ~15EUR.  If storage can hold block chain and can handle internet, is enough.


Can I send bitcoins with my mobile phone? Is it possible to send and receive bitcoins with a mobile phone? If so, are there bitcoin clients for Android or iOS?

There are at least two actual clients for Android and half a dozen "thin clients" that connect to a bitcoin server at home. As the thin clients are kind of complicated installs, I recommend Bitcoin Wallet by Andreas Schildbach.
There are a few questions of security as both apps have no way (that I'm aware of) to import/export/backup wallets and it's uncertain what level of security is held on data Google keeps in the cloud, but for carrying a small amount of coin for daily use, both are viable options.

Not being an iOS person I can't weigh in on the features etc. of the various iOS apps, but a quick glance over the various projects seems to show an assortment of thin clients and no actual iOS-based bitcoind implementation.


How do I convert Bitcoin to cash at my bank via Mt. Gox? If I use Mt.Gox to do this, what are the specific steps I need to take?

The factors that matter for any cash-out decision are:

Where are you located (country)?
How much are you looking to trade?
What type of cash are you looking to receive?
How soon do you need access to the proceeds?
Is privacy important?

You are specifically asking about Mt. Gox but there are numerous methods for transferring value from bitcoins to your bank.  In some instances, Mt. Gox will be a good choice or the best choice, and in other instances it may not be.

In the U.S., for instance, Mt. Gox does not directly provide ACH withdrawal.  ACH transfers are a method for inexpensive bank transfers.  They do support withdrawing of funds to Dwolla and Dwolla can be connected (via ACH) to your bank account.

Here's the article for Mt. Gox on the Bitcoin Wiki:

http://en.bitcoin.it/wiki/Mtgox#Direct_Deposit_2

And here's the article for describing most of the various cash-out / withdrawal methods:

http://en.bitcoin.it/wiki/Selling_bitcoins


How would you store a bitcoin wallet for a small bitcoin exchange? How would you store a bitcoin wallet with the security of the wallet being a priority for a small bitcoin exchange? Offline wallets are the safest though how would a client be able to withdraw their coins if the wallet is offline?

The safe way for an exchange to function is the hot-cold wallet system. A hot wallet, which the server has access to and where all deposits and withdraws get handled from.

Function of the hot wallet

The hot wallet is what your exchange will you to receive and send bitcoins with. If you are sending bitcoins to a user for a withdraw, it comes from the hot wallet on server. If you are receiving, make sure the address in in the hot wallet. A good hot wallet only keeps a small portion of bitcoins available. An amount that allows your service to run for a week or even a day without running out. Say your hot wallet was 5%-10% of your total funds, you'd daily or weekly add bitcoins or take bitcoins. If there are no bitcoins on the hot wallet, your service should come to a grinding halt. You cannot automate the filling of the hot wallet from the cold wallet, this is dangerous and is exploitable.

The benefit of this smaller balance on the server is that you cannot get robbed of all your funds suddenly

The cold wallet

The cold wallet should not be in any way connected to your exchange. It'd be best if only you had access to it. 90% of your funds should be kept here. The idea is that the attacker cannot access 90% of your funds electronically or automatically. You should manually be moving coins from the cold wallet to the hot wallet by yourself.

Note: Do not take my advice here as full advice, you should look up proper wallet management, it is a broad topic. See the Bitcoin wiki article on Securing your wallet.


How to view Bitcoin Cash (BCC) on Trezor Wallet I'm on beta-wallet.trezor.io and I've updated the Firmware to 1.5.1 and still can't see any Bitcoin Cash listed (BTC).  Perhaps I'm being impatient?

BCH (Bcash) as Trezor refer to it, is now available on https://beta-wallet.trezor.io after applying 1.5.1 firmware upgrade. Go to https://beta-wallet.trezor.io

You can also use tool to claim your BCC, read more on this blog page


bch transfered to cashadrrs instead of legacy I tried to transfer BCH from Coinbase to Ledger Nano S.The nano ledger S gave me a legacy address starting with a (1)
Coinbase sent it out to a cash addr. How can I get a hold of this BCH. Looking on Blockchair I see my transaction. I see my ledger address starting with a 1 and I see the cash addr. starting with a q. Coinbase tells me I have to sync my wallet with the cash addr. Blockchain.

Can anybody help???

It should show up in your Ledger.

Cashaddr is a representation of the underlying hash for that address. Each BCH address has a legacy and a cashaddr format. In your case, it is simply likely that the block explorer Coinbase links to defaults to showing the cashaddr format. There are explorers which will show you both, such as blockchair.

For instance, looking up the address 1FPS2Y71KhNQbugjMxAGKwsUFNbvfsYm2h on blockchair will show you it's cashaddr representation as well, which is qzwulnvalvs6gwfy9t7gz5qxs22t9fag45tpcgu32g. Funds sent to either of the above will be accessible by the same private key, in a wallet following either format. Both addresses refer to the same underlying script.


cgminer with two R9 290 giving me headaches I've got two R9 290, using cgminer I'm getting nothing but trouble. I'm using the 13.12 driver and installed the 2.8 SDK.

When I launch cgminer it sees both cards, GPU0 and GPU1. They both happily start mining, but after about 30 seconds cgminer hangs for a few seconds and GPU0 starts dropping its hashrate (it gives HW:1). I'm not sure what's causing the issue since both cards are identitical and I've only defined the settings once using -g 2.

I've seen that there are some difficulties with the particular card (had to define --no-asl to stop it from crashing the display drivers). Does anyone have any tips or clues to find the problem?

I'm running two Gigabyte R9 290 with an i7-930, 18 GB memory and a 1000w PSU on Windows 7 professional x64.

Is there an alternative to cgminer for ATI cards which can succesfully use the ASL api?

I managed to fix this by using the kalroth patched version of cgminer 3.7.2. Sometimes my cards still black screen after rebooting the mining process, but generally it runs quitestable once started from a clean reboot.


A Simple Question: Which blockchain (or ledger) do we query as a client? As far as I know, every full node has a copy of the ledger (or its view) stored locally.

A Generic Question: Which blockchain (ledger) do we query as a client?

In my question query is a generic term, it can be to look up, check a transaction etc.

Do we need to query multiple full nodes to get a common view of the nodes?

The following questions are also related to the above question.

Question: Is there one (public) ledger built from the common view of the full nodes?

If the answer to the 2nd question is: no, then why don't we build one unique ledger which is the common view of the majority of the full nodes in the network?

A More Specific Question: If we don't have one ledger, then how do we (as a client) realize that our transaction has got enough confirmation? Do we need to ask many full nodes to realize that?

I'll try to answer each question as simply as possible, and hopefully give an overview of your misconceptions.

  Which blockchain (ledger) do we query as a client?

We query the nodes that our client is connected to.

  Do we need to query multiple full nodes to get a common view of the nodes?

We don't need a common view of the nodes.  That's not too important.  What is important is a current view of the latest blocks, and which transactions our node has been notified about.  This is how we know which transactions have been confirmed (because they are in a block), and which have been broadcast over the network (because we have seen them).

  Is there one (public) ledger built from the common view of the full nodes?

Yes and no.  Yes, various companies and entities gather information on the state of nodes, and then provide an interface to the public to view information on those nodes, and the overall state of the network.  This is what a block explorer does.  However...no, this is not a part of the Bitcoin network, and clients do not and should not rely on them.

  If the answer to the 2nd question is: no, then why don't we build one unique ledger which is the common view of the majority of the full nodes in the network?

If one unique ledger was the common view, whom would you trust to run that ledger?  This is specifically the problem that Bitcoin has solved.  Bitcoin is a method of coming to consensus on the state of that ledger, without requiring a central trusted authority.  If we were okay with a central ledger, then we wouldn't need a blockchain, and Bitcoin would serve no use.

  If we don't have one ledger, then how do we (as a client) realize that our transaction has got enough confirmation? Do we need to ask many full nodes to realize that?

Confirmations don't come from nodes.  A confirmation is what happens when a transaction is included in a block, and that block is accepted by the network.  Each additional block that is accepted on top of the block including the transaction, is an additional confirmation of the transaction.  It has nothing to do with the number of nodes that relayed the transaction.  As such, we can query a single node for the latest blocks, and count the confirmations of a transaction by counting the blocks backwards until we reach the one with our transaction.  If the proof of work on those blocks checks out, then there is almost no chance that the single node has lied to us about the state of the blockchain.  It would be far too much work for that node to spoof.  Even if they had the computing power to do it, they would have missed out on a fortune in mining just to be able to lie to you about the state of one transaction.  In other words, the verifying the proof of work calculations on the blocks a node provides proves the node is honest.


Would it be any cheaper to transfer US dollars to Canadian using Bitcoin? I'm a Canadian working for an American company.  I get paid in American which gets deposited into an American account.  To get the money to Canada, I write myself cheques from my American account and deposit into my Canadian account.  Would it be feasible/beneficial to transfer the money via bitcoin (convert USD to bitcoin, then convert bitcoin to CAD) instead of writing the cheques?

If you exchange your US Dollars for Bitcoin and then use Bitcoin to buy Canadian Dollars, you will pay the exchange fees for that plus some more hidden costs such as for the bank transfers to fund these trades and the insurance cost for your Bitcoin exchange companies going bankrupt on you or the exchange rate dropping in between your purchase of Bitcoin and purchase of Canadian Dollars. Due to the volatility of Bitcoin and the surprisingly high rate of defaults of Bitcoin exchanges, these risks are, if priced correctly, much more costly than one might be used to in more established financial business.

Here are some wild estimates:

Low volume purchases of Bitcoin might cost up to about 0.5% in exchange fees.
Same for low volume sales of Bitcoin (i.e. for Canadian Dollars).
If you want to avoid the risk of the exchange rate moving between these transaction, you should budget for a similar loss (0.5%) due to the ask-bid spread.
Let us assume it takes you a week to complete everything including the money transfers, and that the risk of losing all is approximately the rate at which Bitcoin exchanges have historically defaulted (approximately half after one year of operation), and that you stand to lose all money involved if that happens. Then a fair insurance against this risk is another 1%.

The total of all this is an expense, either directly or as risk allowance to insure yourself, of 2.5%. Since you may be able to improve a bit on every point, this could be called competitive with banks' international currency exchanges (which have once been described to me by a banker as carrying a guaranteed flat-rate 2.5% fee plus hidden costs).

But if you only pay $157 for exchanging $9000 in your particular case, which is about 1.7%, it will only be advantageous to use Bitcoin if either you can improve significantly on my example, or manage to talk yourself into ignoring or neglecting the risk of the Bitcoin exchange defaulting on its obligation to you. Of course, there are many entrepreneurs, myself included, who are trying to improve on the poor track record of Bitcoin exchanges!

EDIT: From the comments to the question, my best guess currently is that you effectively paid 2.57% in fees with the solution you now have. This makes it a tough call to answer if using Bitcoin is advantageous---by my example, it only is if you put a very low value on the added hazzle of dealing with at least one company acting as a Bitcoin exchange. In practice, you might find it possible to improve on my estimates, so the answer might be that it may be advantageous, depending on circumstances.


Bitcoind Cannot assign requested address I'm trying to run a regtest bitcoind node but I'm always receiving the following error

  connect() to [2a05:d01c:a35:2902:6e18:7290:ff27:e9aa]:18444 failed:
  Cannot assign requested address (99)

My config:

bitcoind -printtoconsole -regtest=1 -rpcallowip=::/0 -rpcauth="...."

I'm running the node with through docker with the following image https://hub.docker.com/r/ruimarinho/bitcoin-core/

Thanks by advance for your answer.

First of all check that your system support IpV6.
Run this:

test -f /proc/net/if_inet6 && echo "IPv6 supported" || echo "IPv6 not supported"

Then make sure to bind to ::ffff:0.0.0.0


Cryptonote Based Altcoin All Transactions Locked I've created an altcoin based on the Cryptonote protocol. I have two seed nodes and am mining (successfully) on both of them in order to test the network. However, all mined coins are showing up as "locked". So, for some reason the other node isn't verifying the blocks mined in both cases, however, they must be communicating because their blockchains are synchronised.

Am I missing something?

In Bitcoin block rewards cannot be spent until they have become "mature". This happens once 100 blocks are mined on top of a block. The idea is that new bitcoins should not be spread around while they may still become invalid due to reorganizations.

In Monero the maturity depth is 60 blocks, which is reached after about two hours. I assume that Cryptonote has a similar delay for block rewards to become spendable.


How do thin-clients know in which blocks to look? Using SPV the client can assure that a transaction is inside a block, but how does it know in which blocks to look?

SPV nodes usually only look at block headers, and then will download some of the actual block data of blocks which other peers have told them contain transactions relevant to them. SPV nodes are relying on at least one of their peers to be honest and report when a transaction appears on the network that is relevant to them.

But how do other peers know which transactions the SPV nodes want to know about?

SPV nodes essentially give their full-node peers a filter, called a bloom filter, that tells the nodes that download all the transaction data which transactions to send to the spv node. This filter also has a built-in false positive rate, so that the SPV nodes don't have to show exactly which addresses are theirs (essentially a built-in privacy level). Rather they make a filter that will validate a superset of transactions that the node is actually interested in.

The filteradd, filterclear, and filterload are the relevant p2p protocol methods. The bitcoin developer documentation goes into more detail here.


What are the trust assumptions in --assumed-valid in bitcoin core 0.14? Please help me understand and distinguish the trust assumptions in the following three cases shown below. Specifically, please elaborate the attacks possible (even though completely theoretical) and trust sacrificed to get the functionality.

Case 1: Bitcoin Core before 0.14 without assumed-valid and where each node does complete signature verification.

Case 2: Bitcoin Core 0.14 with the assumed-valid blocks with signature validation skipped for blocks prior to release. This means that the block signatures are correct because bitcoin-core devs signed on it.

Case 3: (Hypothetical) : Bitcoin Core 0.14 with UTXO set which has the snapshot of UTXO database. This would be done in a similar way as assumed-valid. This would skip the complete IBD and be really useful for quickstart-pruned node.

I would like to know answers to the following 2 questions:

Q1) What are the possible attacks (even though completely theoretical) which are possible in case 2 but not in case 1. Please elaborate security-model change required to shift from Case 1 to Case 2.

Q2) What are the possible attacks (even though completely theoretical) which are possible in case 3 but not in case 2.
It appears to me that security model in Case 3 is same as that of Case 2. If I trusting core devs with signature-validation, might as well trust they give the correct UTXO set.

Q1) What are the possible attacks (even though completely theoretical) which are possible in case 2 but not in case 1. Please elaborate security-model change required to shift from Case 1 to Case 2.

None. If there happens to be a fork that makes the assume valid block to no longer be in the longest chain, then you will continue to validate all signatures in the longest chain. If someone were to give you a "fake" blockchain which does not include the assume valid block, you would be doing the same validation process as without the assume valid block. Assume valid does not change the security assumptions as the assume valid block does not need to be in the blockchain unlike was done with checkpoints.

  Q2) What are the possible attacks (even though completely theoretical) which are possible in case 3 but not in case 2. It appears to me that security model in Case 3 is same as that of Case 2. If I trusting core devs with signature-validation, might as well trust they give the correct UTXO set.

No, Case 3 has completely different security assumptions from assume valid. You are trusting that the Core developers are providing you the correct UTXO set and by doing so, you are trusting that you will be using the correct blockchain on startup. With assume valid, you are not trusting or assuming that you are using the correct blockchain, you are still validating almost everything. With assume valid, even if the assume valid block is wrong, you can and will still be using the correct blockchain and just doing the same amount of signature validation to be on the correct blockchain as software without assume valid.


How to Create or Generate a New UTXO in Bitcoin Core? I know how to use Console in Bitcoin Core but not that expert. I would like to ask is there possible for me to generate or create a new UTXO in Bitcoin Core?
All I have with me are the list of TxID which I have yet to use it. I don't know much about the right code for this.
Anyone can advise?
Thanks

"Creating a UTXO" is the side effect of transacting. It's an abbreviation of "unspent transaction output"
A transaction in Bitcoin consumes a number of UTXOs, and creates a number of new ones, possibly assigned to new owners.
So the answer is: send BTC somewhere (possibly to yourself).


How would SPV proofs be verified when moving assets back in 2-way pegged sidechains? I've seen similar questions posted all around, but haven't found an answer I can comprehend.

Ok, so the process of 2 way pegging is:

I move some coins to OP_SPVPROOFVERIFY on the parent blockchain.
I wait for some time (e.g. 1 day)
I get coins on the sidechain, transact.
Now, I want to move some of those coins back to the parent/main blockchain.
I send them to a special address on the sidechains, and they are now locked on that chain.
... magic magic
Now I can "SPV prove" that the coins are done with on the sidechain and are now free for transacting on the main chain.

How does step 6 work?

Assumptions

Only a subset of the parent chain miners & spv & full nodes are aware this sidechain even exists
The sidechain may use completely different proof of work, block format, address scheme (Or rather: what can a sidechain change compared to Bitcoin, and what is fixed?)

Under these assumptions, how can a full node running the parent chain recognize that the coins really vanished from the sidechain (of which they are not explicitly aware)? Remember, the parent full node isn't aware of the type of proof of work (if any) that happens on the sidechain, address scheme, really it only knows and speaks the language of Bitcoin, not the sidechain. So how does step 6 work?

Your question is spot on and poses the main problem of sidechain interfacing: How to prove to some chain (call it the "mainchain") that an event (such as a deposit) took place on a remote chain (call it the "sidechain").

As far as I'm aware there is as of yet no precise specific of how this works, but there are several approaches that can be taken. The approach usually taken here is to allow for a set of "functionaries" or "fishermen" to observe the transaction on the sidechain, wait for it to become confirmed there, and then vouch for the fact that it took place by signing off a statement (a "certificate") which attests to the fact that the transaction in the sidechain really took place. This can work well if there are some honesty assumptions about the functionaries, e.g., that the majority of them is honest. In that case, in practice, the withdrawal can really be a multisig check. This approach would work with the existing bitcoin implementation. This approach is very compatible with sidechains whose consensus is permissioned/byzantine, e.g. Plasma, Polkadot, Elements.

If you don't want to remain within the realm of bitcoin, there are more elegant solutions with different trust assumptions that can be realized. If you dislike the threat model of a centralized group of functionaries (or a "federation" thereof) and you want to go completely trustless, you need to produce a proof of a remote event in a decentralized manner. This proof will need to have the form of a simple string which attests to the fact that something happened on the remote chain, even if the local miners do not connect to that remote chain and do not know how its consensus works.

If the sidechain has Proof-of-Work consensus, then these proofs make a claim which attests to the fact that sufficient proof-of-work took place to bury a transaction on the remote chain. As they prove that proof-of-work took place, they are "Proofs of Proof-of-Work" (PoPoWs). The verification of such proofs is not a trivial manner and bitcoin does not have an opcode to do this currently, nor is there any support being planned. Hence, such schemata would be possible when the mainchain is a Turing-complete blockchain or supports a PoPoW opcode (unlikely).

On the other hand, the sidechain has to support the generation of these proofs too. This can be built-in to the chain, like ERGO, WebDollar, or Nimiq. A blockchain without PoPoW support can add it without soft forking and without miner approval by conducting an appropriate velvet fork.

Finally, these PoPoWs have to be produced by sidechains maintainers in a "one-shot" attempt that generates a simple string and they should not require interaction, i.e., they should be Non-Interactive Proofs of Proof-of-Work (NIPoPoWs). Given these ingredients, you can do it in a completely trustless manner.

All of the above constructions pre-suppose that the sidechain and mainchain survive securely independently. For example, the sidechain needs to have honest majority computation power if it's PoW-based.

To summarize, bitcoin does not currently have a way to do what you're asking in a trustless manner, but there are federated / cothority ways to do it. If you're willing to work on new systems, you can do it in a decentralized manner.

Disclaimer: I am one of the co-authors of the Non-Interactive Proofs of Proof-of-Work paper.


I think my bitcoin wallet was hacked. What to do? I opened bitcoin-qt after not mining for a couple months and found that I suddenly have no more bitcoins!  And I see that there were 2 transactions that I did not authorize sending my coins to other addresses!  Is there anything I can do to get my coins back?

Probably not. You can try to look at the addresses the coins were transferred to (or, if those were since sent elsewhere, at those addresses too) and see if you can figure out who they belong to. If the thief is somewhat competent, however, it's a good bet that he's made it very hard to track. If you can determine the identity, you might be able to take them to a court (small claims, civil, criminal...I don't know, and might depend on how many bitcoins were stolen, and where in the world you and your thief live) to demand the bitcoins (or equivalent value) back. But as far as the Bitcoin protocol itself goes: no, you cannot reverse the transaction.

To prevent this in the future, make sure that your computer is free of malware, always encrypt your wallet with a secure password, and consider using an offline wallet. See bitcoin.org's Securing your wallet page for other tips.

Are you sure that the addresses don't belong to you, maybe in some online service you used and forgot about?


BIP 44 master private key sign tx I have this Bip44 path implemented

m / purpose' / coin_type' / account' / change / address_index

Is it possible to use the Master private key to sign all the tx
ie. Bitcoin TX, Etherum TX

or do I have to get the asset based private keys for each asset and sign the tx's ?

or I have to get the asset based private keys for each asset and sign the tx's ?

Yes, you can't sign transactions using the master private key. Sign each transaction using the derived private keys.


how does lightning network transactions appear? from my understanding lightning network is a side chain that keeps track all the transactions in the network and just send the sum of the transaction to each of their respective recipients. form that logic, there should still be a transaction data appear in blockchain info with a lot of inputs and a lot of outputs in the actual blockchain right representing all the transaction appear in the lightning netowork? if so can you give me an example of that by the tx_hash or link please?
thanks

I am sorry to write so but your understanding that the lightning network is a side chain is wrong. Thus there is not transaction with many inputs and outputs that represents the payments tat go on in the lightning network.

A payment channel is encoded as a 2-2 multisig wallet. you have one key and I have one key. The capacity of the channel are the funds sent to this multisig wallet with the funding transaction. The balance in this payment channel is encoded by a commitment transaction which spends this funding transaction. This transaction has one input (the funding tx) and two outputs (one for the amount of funds that you own and one for the amounts of funds that I own). (There can and will be more outputs but those exist only temporarily while this channel is being used to rout a payment.)

The commitment transaction only hits the chain if the channel is closed and in the best case still has two outputs. Meanwhile on this channel literally million of payments could have taken place (between the peers of the channel, and to route payments through this channel for other nodes of the network) non of those payments will be seen in the blockchain.

The key observation of the lightning network is the revocable sequence maturity contract (RSMC) which is the protocol that allows to invalidate or revoke old commitment transaction by creating a strong incentive (I should better say penalty) to not publish an outdate commitment transaction.

since all the commitment transactions in the history of the payment channel are spending the fundingding transaction (creating massive double spends) and since double spends will not be accepted by the bitcoin network you can see that the blockchain will not save old channel state. This is exactly the reason who scaling through this offchain protocol is achieved.


Transaction priority I'm testing some functionality on the testnet and I'm having problems with the transactions priority.

According to the technical info, a transaction that has not enough priority should have a fee of 0.00001 BTC/kb (1000 Satoshi), but when I try to broadcast my transaction using a RPC call to my local full node, I get an insufficient priority error:

{u'message': u'66: insufficient priority', u'code': -26}

For example, the following transaction has 3 inputs and 2 outputs:

01000000039233cdbb26e926993a8658f1f26b9afc3677e3715c46c10196ad87072b7b88ae000000008a4730440220353cf2638228b64a3e77f37c4b870a8ff4b743e6d34f16a72e5f022505c7c0850220203a00f1489f113d52da891b4d9553f7c469b91a7196350fdb0e295dc6f8f8df0141049da517c9760c05c7af7fdf973d2206add57cff3fbff03488115f667503fab36e6182ffc8eb3ee693885daace3682804ec9476a3f691097631268e6dbcc5b5877ffffffff68a1afda2dec62ad1db346b093a7b418c2ae207dcc0867dad18bd38c5188c845000000008a47304402205fcb79f89500f2fbbdb558f0fc8ea6a5da48e33cf5296bc36d3f09960a68e58f02200c24f823057510f9d68c0a0c59d52615c1d2a7772dc4105e24fe5562b95d93c30141049da517c9760c05c7af7fdf973d2206add57cff3fbff03488115f667503fab36e6182ffc8eb3ee693885daace3682804ec9476a3f691097631268e6dbcc5b5877ffffffff92b877bac70d96e7901afeb0e4281a9c7eb54983b4918bb57a23fd4d2402b037000000008b483045022100efafead31c56a1fbede2af24d551d22e8d811b96881c96dc294ffafe36cdf140022060b356e06b8f96515c529bab9c18f3e1b162774ea83f012cd80667e2c88a59340141049da517c9760c05c7af7fdf973d2206add57cff3fbff03488115f667503fab36e6182ffc8eb3ee693885daace3682804ec9476a3f691097631268e6dbcc5b5877ffffffff02f82a0000000000001976a914b0acf50f8479ec5913e222610e073c1f54c1b01d88acb80b0000000000001976a914b0acf50f8479ec5913e222610e073c1f54c1b01d88ac00000000

what according to bitcoinfees will have a size of:

148 * 3 + 34 * 2 + 10 = 522 bytes

and it also has a transaction fee of 0.00001 bitcoins, but trying to broadcast it will raise the error shown above.

Does anyone knows what could I've been doing wrong?

I've found what was wrong. It seems that technical info is not up to date to the current Bitcoin Core version (0.11.2.0). Since version 0.11 (12 July 2015) the minimum relay fee is 5 times bigger (from 1000 Satoshi to 5000) so the transaction has not enough fees to be relayed.

Here you could find a discussion about the topic.


why 'increasing the block size above 1 MB requires a hard fork.” actually not require fork? in this link, they say

  “increasing the block size above 1 MB requires a hard fork.” In this
  example, an actual block chain fork is not required—but it is a
  possible outcome.

but i can't understand why actually it not require block chain fork. when block upgrade, soft fork or hard fork will occurred. but it say both of fork is not required actually.

thanks for your help :)

The definitions here are a bit confusing. It is important to understand the distinction between the "soft/hard fork" and the "blockchain fork".

Blockchain fork is an actual split in a chain of blocks. If two groups of people run incompatible software - two different chains will emerge. For example, Bitcoin and Bitcoin Cash follow two different chains that used to be one chain.
Soft or hard fork is a mechanism of performing consensus rule changes. Hard fork upgrade has a risk of causing a blockchain fork, but it does not have to cause it. If everyone will upgrade in time, there would be no chain split. For example, Ethereum has performed multiple "upgrades" through hard forks (such as Byzantium), and the chain did not split. Bitcoin prefers to stay on the safe side and introduces most of the changes to the protocol as soft forks.

To add to the confusion there are also user-activated forks and miner-activated fork, but these are not relevant to the question.


What keeps a dominant Bitcoin client vendor with the majority of the market share from unilaterally changing the protocol? I've been asking this in the comments, but I'll be more direct.

If a third-party Bitcoin client, say "iBitcoin" (for example), becomes the dominant client by acquiring most of the market share, what would keep the vendor from unilaterally changing the Bitcoin protocol to their own advantage?

The question

Consider the following:

iBitcoin gains 75% market share because, well, it's so awesome
At some point the vendor decides to change the rules so that it starts mining its own branch on the blockchain, but with a block creation fee that's significantly higher and can be adjusted at will. (See rules below)
iBitcoin users don't care because they are still able to exchange bitcoins back and forth with users of other clients, nor do users of other clients care. It's all hunky-dory in Bitcoin land. (See rules below)

Here are the rules that iBitcoin follows:

The iBitcoin branch is a copy of the main branch, block for block, with the exception that a second coinbase transaction is included paying out to the iBitcoin vendor's address. All coins in the iBitcoin branch can now trace their origin back to either the main coinbase or the secondary coinbase. Let's call these extra coins "new bitcoins" (BTC2). The main branch won't accept transactions from these coins, but that's OK.
Proof-of-work is eliminated in favor of the vendor's digital signature. Block signing happens on a central server.
To keep things simple, a transaction can include as its inputs either bitcoins (BTC) or "new bitcoins" (BTC2) but not both

Now the UI shows new bitcoins separately so that the user knows that these new bitcoins can't be paid to someone who uses a different client (like the Satoshi client), but they can be paid to another iBitcoin user. In other words, iBitcoin users accept payments in BTC or BTC2, others accept only BTC. The two currencies trade separately on the exchanges.

Thanks to the network effect, almost everyone eventually switches over to iBitcoin (or a compatible client). Gresham's law says BTC eventually becomes an item to be hoarded, just like gold, whereas BTC2 is used for day-to-day commerce, just like the dollar.

Please explain flaws in my design of iBitcoin and why it won't work.

Are we in trouble?

What keeps this from happening? As it see it: nothing. It's going to happen eventually. I call it the "embrace and extend" attack.

If this indeed works (and that's my question), then the vendor doesn't even need 75% market share to begin with. It could start with 5% market share and a scheme for giving out 100 BTC2 for every new sign-up, along with a referral scheme so that users have an incentive to bring in more users. Since BTC2 is pretty much created out of thin air, the rewards could be increased until a significant adoption rate has been achieved. Rewards could also be in BTC instead of BTC2, or even in US dollars for that matter. Achieving adoption is no big deal.

Also note that "BTC2" is the red herring here. It's not about creating an alternate currency, it's about creating an alternate blockchain that is controlled by the vendor. Hash power is overrated; if you control the clients, you own the game.

Back to the question: What keeps this from happening?

If the answer is that the Bitcoin community would never accept such a thing, well, sure, I'm sure the "World Wide Web" community said the same back when Microsoft was still working on Internet Explorer 1.0. I wonder how things would have turned out had the US Department of Justice not stepped in.

If the answer is that a Bitcoin client that deviates from the rules of the Bitcoin protocol is not really a Bitcoin client, again, that's like saying a web browser that does not render HTML as per the rules set out by the W3C is not really a web browser. It's technically correct, but it doesn't mean anything. For all practical purposes the version of Bitcoin that has the majority of the market share is the "real Bitcoin."

So I hope that I'm wrong and that there is in fact a defense built into the protocol.

What you are describing there is a client that is a hybrid of Bitcoin and something else.

For instance there is nothing to stop you starting ManishCoin and writing a ManishBitcoinSuperClient. If you can get enough people to believe in ManishCoin then it becomes a useful currency.


What percentage of Bitcoin transactions never complete? Occasionally transactions will be broadcast to the network that will show in a 0/unconfirmed status in the Bitcoin client. It is also the case that from time to time for various reasons those transactions will never confirm. One known reason for such unconfirmed transactions is a double-spending attempt, though these are usually quickly resolved by the network. My question is twofold:

Is there any source of data or is there a known statistic stating what percent of transactions hit 0/unconfirmed and never progress beyond this state (i.e. are resolved as conflicts by the network).
Is there anything aside from a double-spending attempt that can produce a 0/unconfirmed transaction that does not confirm.

Please note that I am not referring to the "generated" transactions by which miners are paid, but rather a point-to-point transfer of bitcoins.

I have watched for reports of a transaction that appeared live on the net that never got into a block. It has never happened, and I don't think it's likely to happen. The only practical way for it to happen is for the network to be split due to a connectivity problem or for a miner in cahoots with the person attempting the double-spend attack to mine a conflicting transaction (not accepted by the network) into a block before the transaction itself gets into a block.

I agree that accepting 0/unconfirmed transactions is sufficient for point of sale applications. Someone is very unlikely to attempt a double-spend in person for a few thousand dollars or less and is even more unlikely to succeed. (Update: Due to the risk of the Finney attack, I withdraw this argument.)

I think your guess is only reasonable within limits though. For big transactions, companies will sue people who charge them back. They can do the same thing with Bitcoin transactions if they ask for ID first. For face-to-face transactions, I don't think confirmations matter for transactions that aren't massive.

It's not a big deal for online transactions for a different reason. If we're talking a small payment for access to a web site, is anyone really going to bother with an attack? And does anyone care? Here, the percentage risk argument works. And for big online stuff, delivery's usually not immediate anyway (think PayPal, eBay, Amazon).


Is there a real threat of so called ">50% attack"? According to Bitcoin Wiki attacked who has majority of computing power of the bitcoin network can successfully do some nasty things such as potentially book double-spending or prevent transactions from gaining confirmations or block other minders mining valid blocks.

Today the vast majority of computational power is controlled by mining pools. According to blockchain.info GHash.IO is 30%, BTC Guild is 23% and Eligius is 12% (as of today 15/12/13).

Is there a threat for the network if pools would pair up to get more than 50%? Alternatively two major pools could get compromised simultaneously in order to get more than 50%. I was wondering how real is such scenario?

References mentioned:

https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_computing_power
https://blockchain.info/pools?timespan=4days

Well, the answer is two-fold: what's the chance of a 51%-attack to happen and what are the consequences if it does.

What's the chance of it happening?

You mention correctly that the major parties via which such an attack can be achieved, are miners. The chance that a 51%-attack is performed by a 3th party is neglectable, since the cost to achieve a mining output to achieve such as enormous. Only maybe if a large government would decide to assign a large budget to it, it may happen, but still ASIC hardware is scarce and difficult to manufacture.

So basically the real threat is in the miners. However, the chance that a miner would obtain >50% hashrate share is minimal. The miners themselves would not benefit from their pool having such power, on the contrary. So what would happen is miners leaving for another pool, pulling the pool's share back under 50%.

The only real threat that remains is the possibility that multiple pools are compromised simultaneously. In such a case, however, I believe the pool owners will notify users as soon as possible, resulting in miners leaving. Also, from the moment the party in power of the compromised miners starts manipulating the block chain, the community will notice. I believe it won't take long before people will be warning each other and miners will stop operating at the compromised pools.

So let's conclude that in the worst case, an attacker will can perform an attack and hold it for a few hours max until it will lose its position.

What are the consequences in such a case?

A party that is in control of the network can't really manipulate the blockchain very drastically. Here are the main actions one would be able to perform:

Decide what transactions are included in the chain. Essentially it can halt all payments, but than they would be noticed very quickly. Probably the attacker will only manipulate transactions of his own concern.
Receive all block rewards. But that is no more than an extrapolation of a miner's situation with a <50% hashrate.
As a result of nr 1, an attacker can easily perform double-spend attacks. This will be the main threat. Since the attacker decides what transactions make it to the blockchain, he can very easily make a transaction, perhaps even give it one confirmation, and then revert it with another. When he receives fiat or goods for his first transaction, he can make profit by reverting the transaction.

It is clear that the consequences are quite minimal. It is difficult to maintain such a situation, it will require extensive planning in order to make real profit from the attack since the only way to actually make profit is through exchanging things for bitcoins and double-spending the transaction you made.

EDIT: There might actually be a scenario in which an attacker may be able to make good profit from the attack, like David Schwartz mentions in the comments. Even with the fore-mentioned assumption that the network will react after the first time the attacker messes with the block chain, a well-prepared attack can do damage with one backfork*. The attack would look as follows:

The attacker deposits bitcoins in an account on an exchange. (Probably he will have multiple accounts on multiple exchanges to make as much profit as possible at once.)
As soon as the exchange recognises the transaction as being confirmed, the user withdraws the bitcoins again. Most exchanges use different wallets for sending and receiving, so the withdrawn coins will most probably come from a different address. (Making the withdrawal independent from the deposit.)
As soon as the attacker receives the transactions that represent his withdrawals through the bitcoin network, he will hardfork* the chain to undo his deposit transaction and doublespending it in his new chain, as well as including the withdrawal transactions in the new chain.
This way the attacker will have both the deposit amount as the withdrawal amount in his wallet.

Although this scenario is possible, it would require extensive planning. Also, most exchanges require more than one confirmations and the more confirmations are required, the harder the attack becomes. To successfully hardfork* multiple blocks in a feasible time, the attacker will need more than just 51% of the network hashrate.

* I'm not sure if this is an established term, but I think of a backfork as a fork of the chain a few blocks before the latest to revert the history of those blocks.

(Wrote this from my mobile phone, typos may occur.)


Why isn't importing wallet.dat as straightforward as it seems it should be? In most of computerdom, an app's File dropdown menu has an Import item that permits selection of a file to import into the application.  This would seem to be an obvious feature to include in a Bitcoin GUI, yet when searching for how one imports the wallet.dat file, no such straightforward import option appears.

What is the technical reason for this?

It is not so easy to "open" a wallet, because it requires rescanning the blockchain to find the outputs that are relevant. This can take a very lock time, especially if you do not have an SSD. Because the performance is so poor, it would be disappointing for a lot of users to use this hypothetical feature.


Confused about LND derivation of node's payee pubkeys Okay. A short summary of the problem: I'm trying to derive the root key from LND from the aezeed, but I can't get it right.
Assume the following seed (aezeed):
ability quality bulb clap quality piano focus ivory trust essence improve book antique analyst double equip reason venue jazz zoo host potato harvest divorce

For which the following root keys result:
tprv8ZgxMBicQKsPct7CvypLfrMHfanE3cmTwZuy8QTGNgzFZKSqFeXXinsuKvkyMe6DbqdGMu8Xp1fon8E3mgW62RiorqMv6qLV2dqPFX3pETp
xprv9s21ZrQH143K24sgGQxqWCjJMTN1p6jTc1zrFz2otiVmmihkGHBnD3WTQkbKMGhuEQ6VMoWmef61KGgJeUA9DNTDLC9cSUcS7Y5xos3tfBr

To check if these are correct, we derive the node's payee key (identity pubkey), which is m/1017'/0'/6'/0/0
results in 03bb9f9f7734ca9da4ec06543d32456384f878303305a72979e7316825e00749ad
the problem is; the above seed results in 039e625ffe5325224e6273fc5e0afe59f7ec82cb90add45e76f34cfff9efdcac60
(as per LND's getinfo)
Anyone who can spot my mistake?

Wrong cointype. I'm assuming mainnet = 0, and testnet = 1,  although I can't find any documentation on this.
m/1017'/1'/6'/0

gives the correct identity key.


generating private key from bip39 seed according to bip39, I maked 12 mnemonic words and then get a 512 bit seed from them.

now I want to know how must I convert this seed to private key ?

what functions must I use ?

please introduce me libraries for browser javascript.

although I know that I must use ECDSA and secp256k1.

but I do not know exactly what the steps are?

I don't know based on what algorithm I need to convert a 512 bits seed into a 256 bits private key.

Regarding algorithms:
BIP-0039 says:

From mnemonic to seed
A user may decide to protect their mnemonic with a passphrase. If a passphrase is not present, an empty string "" is used instead.
To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes).

So the algorithms so far are described by

PBKDF2
HMAC-SHA512
Reference implementations
Example implementations

According to the Bkitcoin Wiki entry for Private key:

Wallet software may use a BIP 32 seed to generate many private keys and corresponding public keys from a single secret value. This is called a hierarchical deterministic wallet, or HD wallet for short. The seed value, or master extended key, consists of a 256-bit private key and a 256-bit chain code, for 512 bits in total. The seed value should not be confused with the private keys used directly to sign Bitcoin transactions.

BIP-0032 says:

Extended keys
In what follows, we will define a function that derives a number of child keys from a parent key. In order to prevent these from depending solely on the key itself, we extend both private and public keys first with an extra 256 bits of entropy. This extension, called the chain code, is identical for corresponding private and public keys, and consists of 32 bytes.
We represent an extended private key as (k, c), with k the normal private key, and c the chain code. An extended public key is represented as (K, c), with K = point(k) and c the chain code.

It then goes on to describe the algorithm used.

Regarding Javascript Libraries

https://github.com/bitcoinjs/bip39
https://github.com/bitcoinjs/bip32

It seems to me that this requires a lot of digging about in documentation and source code.
It initially doesn't seem to be something that can be fully encompassed in the space alloted to answers in this Q&A forum.


How does Mt.Gox calculate high and low price? How does Mt.Gox. calculate high and low price? How can last price, over time, be higher than the high price?

The High Price is the lowest sell order that is on the exchange. Conversely, the Low Price is the highest buy order on the exchange.

However, the Last Price is calculated differently. It looks at what the price was the last several times that bitcoins changed hands.

If Last Price is higher than High Price, or lower than Low Price, that is indicative of one of two things:

Someone is trying to manipulate the last price by trading bitcoins absurdly high or low.
The market has moved since the last trade.


How to send bitcoin from an offline Bitcoin Core that doesn't have a synced balance? I am setting up a cold wallet. How can I generate a signed raw transaction from bitcoin core wallet that controls some bitcoins?

PS: I generated the wallet using getnewaddress in console from the bitcoin-qt GUI

The easiest way to do this by importing the address you generated on the offline Bitcoin Core client into an online fully synced Bitcoin-Core. The command is: bitcoin-cli importaddress <address>. The benefit of importing this address into the synced Bitcoin-Core machine is that you can use it as a watch-only address which will allow you to see all the UTXOs related to it. You can then use the command bitcoin-cli listunspent to show you all the UTXOs and then you can use the ones related to the address in question.

Note: Below txids and amounts are made up.
Now, using the UTXOs that were shown in the listunspent output you can create a transaction on the online client using the createrawtransaction command. I deliberately used two UTXOs to show how this can be done for multiple UTXOs and also to show how other commands will look like if one of the outpoints in the inputs belong to a legacy address and the other outpoint belongs to a P2SH-P2WPKH address.

bitcoin-cli createrawtransaction '[{"txid":"27893ad827ddd94c442c561b1d3bf3d0f60571d6518e4941698e5778b25e1991","vout":0},{"txid":"776be22ff789a86283b247f99f7b2c6f7f53185cb765570bc65c6e6bb7ed8558","vout":1}]' '{"12WJykFa1hqJUJ65QbFB8dS5XNJaR22w2S":0.1}'

This would give you the below hexstring that you can copy over to your offline machine.

output: 020000000291195eb278578e6941498e51d67105f6d0f33b1d1b562c444cd9dd27d83a89270000000000ffffffff5885edb76b6e5cc60b5765b75c18537f6f2c7b9ff947b28362a889f72fe26b770100000000ffffffff0180969800000000001976a9141083323e89f0f734c448cd16d5a5513afb841b1788ac00000000

Copy over that output on the offline machine in order to sign the transaction. Now signrawtransaction command was deprecated in v0.17 and removed since v0.18. In place of that we now have signrawtransactionwithwallet and signrawtransactionwithkey. You will use the former when you want to sign the transaction from a key belonging to your wallet in Bitcoin Core and use the latter when you want to sign a transaction with a key not in your wallet by passing the private key along with the command.

Since your address was generated from a key in the wallet, we will use the first command. After copying over the output of the createrawtransaction command we had got on the online client, we also need to provide the sciptPubKey and redeemScript. This is done so that the offline client knows what the locking script is for the outpoints and which key it needs to use as it does not have access to the transactions (since it is offline).

Now, use the command:

bitcoin-cli signrawtransactionwithwallet "020000000291195eb278578e6941498e51d67105f6d0f33b1d1b562c444cd9dd27d83a89270000000000ffffffff5885edb76b6e5cc60b5765b75c18537f6f2c7b9ff947b28362a889f72fe26b770100000000ffffffff0180969800000000001976a9141083323e89f0f734c448cd16d5a5513afb841b1788ac00000000"
'[{"txid":"27893ad827ddd94c442c561b1d3bf3d0f60571d6518e4941698e5778b25e1991","vout":0,"scriptPubKey":"76a914623ff66fb88ff802fe1b8eaff666ba52307eecb088ac","amount":0.09},
{"txid":"776be22ff789a86283b247f99f7b2c6f7f53185cb765570bc65c6e6bb7ed8558","vout":1, "scriptPubKey":"a914de7dad83bb2d6e9638d347dcb3c53fe238773c9387","redeemScript":"0014df7bcc159ade813e6bd6290d97ed0bc8987dc084", "amount":0.011}]'
"ALL"

This would give you a signed transaction as an output. Let's call it hexoutput. A couple of things to note. If you pay close attention you will see that the second outpoint used in the input contains redeemScript. This is because it belonged to a P2SH-P2WPKH transaction and hence you need to provide the redeemScript next to the scriptPubKey field. For more info you can refer the documentation here.

Now copy this hexoutput over to your online Bitcoin-core client and use the below command to relay it over the network.

bitcoin-cli sendrawtransaction hexoutput

This will give you a txid of the transaction as an output that you can use to monitor your transaction.