Chainstate LevelDB corruption after reading from the database I've been working with the LevelDB for a few weeks, coding some tools to access the database and parse the data to be human readable.

However, every single time I read from the chainstate the data gets corrupted (ask me to rebuild it when running bitcoind). I decided to copy the DB as a workaround after it happened the first time, but it's quite annoying to do so every single time I want to update the data.

I'm using plyvel and Python 2.8, and I close the DB every time I finish with the reading.

Example

# Open the LevelDB
db = plyvel.DB(".bitcoin/chainstate")

for key, o_value in db:
 # do stuff

# Close the LevelDB
db.close()

Does anyone knows what could be the reason? Does bitcoind prevent other software to access the DB by marking the last access somehow?

chainstate LOG after running the code, retrieving the obfuscation key, and closing the database:

2017/03/22-11:03:45.746702 7f3c18a39700 Recovering log #394423
2017/03/22-11:03:45.854583 7f3c18a39700 Delete type=0 #394423
2017/03/22-11:03:45.854711 7f3c18a39700 Delete type=3 #394422

Example code:

db = plyvel.DB(".bitcoin/chainstate")
o_key = db.get((a2b_hex("0e00") + "obfuscate_key"))
db.close()

debug.log after opening bitcoind (just the part referring to the LevelDB):

2017-03-22 10:03:45 Cache configuration:
2017-03-22 10:03:45 * Using 2.0MiB for block index database
2017-03-22 10:03:45 * Using 8.0MiB for chain state database
2017-03-22 10:03:45 * Using 290.0MiB for in-memory UTXO set
2017-03-22 10:03:45 init message: Loading block index...
2017-03-22 10:03:45 Opening LevelDB in /home/sdelgado/.bitcoin/blocks/index
2017-03-22 10:03:45 Opened LevelDB successfully
2017-03-22 10:03:45 Using obfuscation key for /home/sdelgado/.bitcoin/blocks/index: 0000000000000000
2017-03-22 10:03:45 Opening LevelDB in /home/sdelgado/.bitcoin/chainstate
2017-03-22 10:03:45 Opened LevelDB successfully
2017-03-22 10:03:45 Using obfuscation key for /home/sdelgado/.bitcoin/chainstate: 27c78118b7316105
2017-03-22 10:03:48 LoadBlockIndexDB: last block file = 810
2017-03-22 10:03:48 LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=53, size=51783543, heights=457770...458279, time=2017-03-18...2017-03-21)
2017-03-22 10:03:48 Checking all blk files are present...
2017-03-22 10:03:49 LoadBlockIndexDB: transaction index disabled
2017-03-22 10:03:49 LevelDB read failure: Corruption: corrupted compressed block contents
2017-03-22 10:03:49 Corruption: corrupted compressed block contents
2017-03-22 10:03:51 Aborted block database rebuild. Exiting.
2017-03-22 10:03:51 scheduler thread interrupt
2017-03-22 10:03:51 Shutdown: In progress...
2017-03-22 10:03:51 StopNode()
2017-03-22 10:03:51 Shutdown: done

Plyvel has Snappy compression enabled by default. Have you tried disabling it when opening the database?

# Open the LevelDB
db = plyvel.DB(".bitcoin/chainstate", compression=None)

With this code my bitcoind does not seem to complain after having opened the database with python.


How is the whitepaper decoded from the blockchain (Tx with ~1000x m of n multisig outputs) The whitepaper is apparently encoded at 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713, which is an m of n multisig Tx with 947 outputs (just under the scriptsig limit of 20kB!).

Using the Blocktrail Python SDK, I get a list of the outputs as hex using the following Python (2.7) code (NB, the APIKEY, APISECRET parameters are available if required from www.blocktrail.com):

from blocktrail import APIClient
bt_client = APIClient(APIKEY, APISECRET, network='BTC')
txnObj = bt_client.transaction('54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713')
hashes = [(t['script_hex']) for t in (txnObj)['outputs']]

The resulting list is available here in full and is essentially all pay-to-pubkey-script Txns. An excerpt:

[u'5141e4cf0200067daf13255044462d312e340a25c3a4c3bcc3b6c39f0a322030206f626a0a3c3c2f4c656e6774682033203020522f46696c7465722f466c617465446541636f64653e3e0a73747265616d0a789cad5c4b8b24b911becfafa8b3a1da292925654253d0d55373f06d61c007e39bbd061f0cde8bffbe25c55b5266f61ab3905d419ba54728e28bb76a963777fbcfb77fdf96db7d291f93f3e599f7fafcedefb73fffe1f6aff665fdefb77f7c7bfefce6c2fa166e695bdfd6dbcfbfddfef8c3dd5cf953ae',
.....
u'514130206e200a30303030313832353430203030303030206e200a747261696c65720a3c3c2f53697a652036382f526f6f74203636203020520a2f496e666f20363720413020520a2f4944205b203c43413142304134344244353432343533424546393138464643443436444330343e0a3c4341314230413434424435343234353342454641393138464643443436444330343e205d0a2f446f63436865636b73756d202f36463732454137353134444641443233464142434337413535303032314146370a3e53ae',
 u'51213e0a7374617274787265660a3138323732370a2525454f460a000000000000000051ae',
 u'76a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac',
 u'76a914031c79236ff3017496cf8d9a883f494458f245f288ac']

QUESTION: How is this array of hex data parsed into the bitcoin.pdf? Specific Python framed answers would be appreciated!

This is a fun little puzzle on the blockchain, basically. First, you need to know a little about pdf's and how they're structured, which you can find here.
Second, you'll note from section 3.4.1 that all pdf's start with this string:
%PDF-

In hex, that is 255044462d. And indeed that is in the very first output in the very first bare multisig pubkey:
<e4cf0200><067daf13>**255044462d**312e340a25c3a4c3bcc3b6c39f0a322030206f626a0a3c3c2f4c656e6774682033203020522f46696c7465722f466c6174654465

I haven't figured out what the first 8 bytes are for (♦edit: e4cf0200067daf13 = 2x 4byte little Endian "checksums", see @WizardOfOzzie comment below), but the rest of the bare multisig keys (everything in between 1 and 3 OP_CHECKMULTISIG in each output -- note the last one is a 1 of 1, so it's 1 OP_CHECKMULTISIG) are pieces of data for the pdf and they are in order. If you can put all the hex digits of the bare multisig keys into a single file (no whitespaces) called "fromblockchain.hex", you can run this very simple program to extract the pdf:
contents = open('fromblockchain.hex').read()
bytes = contents[16:].decode('hex')
f = open("bitcoin.pdf")
f.write(bytes)
f.close()

This should create a bitcoin.pdf which is the actual satoshi whitepaper. I've tested this and indeed it is the whitepaper. Good to know it's literally in the blockchain.
Alternatively, if you have bitcoind running on your machine, you can run this python script to grab the bitcoin whitepaper:
import subprocess

# raw = full hex of raw Tx using Bitcoin-cli
raw = subprocess.check_output(["bitcoin-cli", "getrawtransaction", "54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713"])

outputs = raw.split("0100000000000000")

pdf = ""
for output in outputs[1:-2]:
    # there are 3 65-byte parts in this that we need
    cur = 6
    pdf += output[cur:cur+130].decode('hex')
    cur += 132
    pdf += output[cur:cur+130].decode('hex')
    cur += 132
    pdf += output[cur:cur+130].decode('hex')

pdf += outputs[-2][6:-4].decode("hex")
f = open("bitcoin.pdf", "wb")
f.write(pdf[8:-8])
f.close()

Finally checking checksum
sha256sum bitcoin.pdf
b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553  bitcoin.pdf


Have the security vulnerabilities found in Bitcoin been fixed in other altcoins? This page maintains a list of vulnerabilities found in Bitcoin, and when they were fixed:

https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures

Are major altcoins, being based off of the same code, vulnerable to the same attacks? If so, have they been patched?

Generally not. It's very difficult to audit the state of most altcoins just due to the ridiculous number of them in existence, and the fact that many of them intentionally sever the history by rebuilding the Bitcoin repo from the files rather than properly forking the Git repository.

A large number of Proof of Stake altcoins were forked from 0.6 source code and remain using BerkeleyDB for block chain state storage rather than the LevelDB UTXO used in modern Bitcoin Core. Most Litecoin forks seem to have been made around Bitcoin 0.7 and maintain some of its eccentricities as well. Some more popular forks have back ported fixes or brought their forks to be somewhat level to Bitcoin, but these are the underwhelming majority. It's unclear if they have applied all the security patches they should have, or if they did them correctly given the differing source and histories.

From a quick glance at a small sample of some of the most popular forks listed on coinkmarketcap:

Litecoin - mostly in line with Bitcoin Core, with some patches cherry picked from upstream
DarkCoin - forked from Litecoin but does not appear to backport any patches.
DogeCoin - forked from Litecoin, with some patches cherry picked from upstream.
PeerCoin - appears to be a 0.6 or 0.7 vintage fork of Bitcoin, limited backported patches.
NameCoin - ancient fork of Bitcoin 0.3, very limited back porting of patches.

Most other altcoins will be the same or worse in terms of security updates of known bugs. It's a very real risk forking Bitcoin if you are unable to maintain it, and many of the people creating forks are completely ill equipped for the task.


Is a script spendable if multiple items are left on the stack? Is a script spendable if the top item left on the stack evaluates to "TRUE", and that is the only item left in the stack?

In other words, is it okay for multiple items to be left on the stack?

For example,

A scriptPubKey + scriptSig is spenable if an OP_1 (or anything other than OP_0 or nothing) is left on top of the stack after the script has finished executing.

scriptPubKey: OP_DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig:    <signature> <pubkey>

If the <pubkey> hashes to the <pubkeyhash>, and the <signature> corresponds the <pubkey>, then OP_CHECKSIG will end up leaving the following on the stack:

stack: OP_1

However, if you had the following scriptPubKey + scriptSig:

scriptPubKey: OP_2 OP_3
scriptSig:    OP_1

This would leave the following stack:

stack: OP_1 OP_2 OP_3

Would this evaluate to TRUE and mean the script is spendable?

I'm getting a non-mandatory-script-verify-flag (Extra items left on stack after execution) (code 64) error, and I'm wondering if this is the problem.

Yes, this is the problem.

Pre-segwit there is a standardness rule in Bitcoin Core that requires a single element only on the stack after execution.

In P2WSH, this is part of the consensus rules.

The reason for this is that without such a rule it is trivial to malleate any transaction: just prefix the scriptSig with additional garbage elements, which would never be inspected by the locking script, and thus just passed through.


Do all block explorers show all unconfirmed transactions? If I want to show someone that I just made a transaction without showing them my wallet, could I expect that it would be recorded on a block explorer immediately?

There is no guarantee that a transaction propagates through the network at all.

Blockexplorers can only show transactions that they see. They're often configured in a way that will make them be more likely to see transactions, however.


how can I run multi wallet on one computer to share same blockdata you know ,you need a 32GB size for one bitcoin client,is it possible to run several bitcoin programs sharing same data source using -datadir or something else? I have found that somebody had put it  about a year ago and got an big NO; Since 1 year has passed ,is it still NO?

On Windows it wouldn't work because of file locking/sharing I suspect and on Linux that wouldn't be a problem but the data would surely get corrupted. There's no advantage to running multiple servers either, if you need to process more transactions than the server can handle then you should probably be doing it a different way or with multiple machines. If it's to help the network then one will do - leave it 24/7 and it will start to provide more than 8 connections if you allow it via config.


Are there physical Bitcoin? I have seen several folks selling "bitcoins" on Ebay and the like - but they are made of base metal and have no real connection with the bitcoin concept other than the symbol.

I'm wondering if some number of bitcoins could be permanently assigned to a coin (i'd plan on about 10 bitcoins impressed into a one ounce silver round).  I'm thinking of having a public registry of bitcoins assigned permanently to individual coins.  Said bitcoins could be reassigned only in the instance of the "surrender" of said silver round.

I appreciate the fact this reduces the portability of bitcoins, but it would be an interesting method of storing value.

There absolutely are. As a matter of fact, Casascius already offers a 10 BTC silver round in addition to his better-known 1 BTC brass coins and 25 BTC gold-plated brass coins. While not coins per se, the same principal allows for bitbills and other physical Bitcoins.


How does Bitcoin avoid splitting into multiple p2p networks? So since Bitcoin is completely decentralized what stops multiple p2p networks from being formed?

And what happens with the block chain when two separate P2P networks eventually reach each other? Will all the nodes just agree to use the longest block chain?

Wouldn't that mean that a bunch of transactions would be lost?

As long as everyone follows the same rules, mining is convergent, because the expected interval of ten minutes allows every full node to catch up to the current state of the network.

Separate p2p networks (altcoins) derive from a different set of rules, where one of the rules is the Genesis block of the blockchain. Since their Genesis block is different and each block refers to their next ancestor until the Genesis block is reached, blocks found on a different chain are not valid for a chain with another Genesis block. They, and their ancestors are not a valid part of that chain.

As Pieter points out below,  some of the nodes' IP addresses are hard coded,  which allows new nodes to discover their first Bitcoin peers.

If the rules were the same, but two networks separately extended the chain, the heaviest chain would prevail when they reconnect. The other (lighter) chain would go stale and would not be continued. All the transactions that were previously confirmed in the network of the lighter chain would become unconfirmed and valid for mining as long as the UTXO they are spending are still unspent on the heavier chain. The process of mending a chain fork by resolving it to the benefit of the heavier chain tip is called a "chain reorganization".

Heavier and lighter here refers to the chain with the most proof of work. As long as both chain tips have the same difficulty, this would simplify to the longer chain. If the chains have different difficulties (because the separate chain tips both passed a difficulty reset), we actually need to compare the aggregated proof of work.


Bitinstant order was processed, but is not showing in blockchain - did I screw up? Did I do something wrong?  Here's the output from the order status page:

Quote ID    a086c30f-04a2-491c-b616-88655077ea68
Event ID    8db863ac-c880-45ae-b96e-ed8ece6e1021
Fees (inclusive)    3.99%%
Amount you paid $500.0 USD
Amount you will receive $480.05 USD
Destination exchange    Bitcoin Address
Destination account 1Jhbh2bezGY9GGPtkUdFixvtfrUpBHU55R

Timestamp   Event ID    Event type
Tue Apr 2 03:08:27 2013 8db863ac-c880-45ae-b96e-ed8ece6e1021    Quote for new transaction
Tue Apr 2 03:40:38 2013 44d23e52-d977-4e1c-825b-2dd9166a72d3    New Order
Tue Apr 2 03:41:49 2013 6bb94555-9e73-4d4f-a9bc-a5cc7e93492d    MTGox Connection Error
Tue Apr 2 03:51:50 2013 980e15b8-6c8a-45af-87b7-0fe9427bd818    Order executed - funds deposited at remote exchange

I take it that this is the transaction you are waiting for: 922ce90177.... As you can see it has been submitted to the network and will eventually show up in your client as well.


I hate to necropost but I am in the middle of building a custom monitoring system for our company and had to deal with this exact problem. While I sadly can't release any code at the moment, there two values you are looking for: "Temp" and "TMax". "Temp" is the inlet temperature and "TMax" is the outlet temperature. At the moment my code just iterates through the JSON data looking for those strings with a regex and combines all the ones it finds into an overall controller average.


Running Miner as embedded system (No OS) - Can it be done? I've been messing about with TCP/IP stacks on some fairly powerful MCU's lately (mostly the ARM M4 series), and this sort of led to the crazy idea, that I could somehow create an embedded platform specifically for mining (using FPGA's as co-processors). I've dabbled in pool mining just for fun, but came to the realization I actually have no idea how it works,
protocol wise. I already have the hardware scattered around my house somewhere, so it could be a fun (ie, time consuming) project!

I understand the bitcoin client does several things, such as validation of all blocks, handling transactions, address, wallets etc. But for an embedded miner solely involved in a pool operation, what exactly would be the minimum functionality? As I understand it, the pool largely handles everything, and all you are required to do is receive/send data through JSON-RPC and process it. Is that really all there is to it? Or am I missing something absurdly important? Any clarifications would be awesome!

That's about all there is to it.  You don't need to handle the Bitcoin protocol or worry about the blockchain, the mining pool does all that for you.  Just issue a request for 'work' to the pool using the JSON-RPC interface.  Hash the supplied work with different nonces over and over until you get a hash less than the given target, and use the JSON-RPC interface to submit successes.

You might want to poll for new work in a separate thread, so you know when the block you're working on has been found by someone else.


What is OP_CODESEPARATOR used for? Looking at the Bitcoin source (https://github.com/bitcoin/bitcoin/blob/v0.9.3/src/script.cpp#L843-L847, specifically), I ran into the use of the OP_CODESEPARATOR. Am I right in interpreting this code that it is not always the case that the whole scriptPubKey is signed, but really just the part that is later than the most recent OP_CODESEPARATOR? What happens if an OP_IF causes an OP_CODESEPARATOR to be skipped?
It seems strange to me that the entire scriptPubKey isn't used for signing in all cases, so I'm guessing there is some use case for this that I haven't thought of. Does anyone know what this use case is?
I've read through this bitcointalk thread, but didn't really find any conclusion there.

Looking at this diagram of OP_CHECKSIG steps and the Bitcoin Script wiki, OP_CODESEPARATOR is used to make OP_CHECKSIG check only part of the scriptPubKey. Essentially, only the script that goes after the last OP_CODESEPARATOR is used to sign the transaction and hence evaluated by OP_CHECKSIG.

In theory, a spending transaction could change the part of the scriptPubKey before the last OP_CODESEPARATOR  of the input transaction.

However, there's a problem. Since scriptPubKey comes from the input transaction, you can't actually modify any part of the scriptPubKey (even the part before the last OP_CODESEPARATOR) without changing the input transaction hash. Changing the input transaction hash breaks the link for any transaction trying to spend outputs from the unspent input transaction, making it impossible to use OP_CODESEPARATOR in practice.

I wasn't able to find any cases in practice where people have successfully used OP_CODESEPARATOR for a useful purpose, although it does show up in the blockchain. See this, this and this (and the thread you referenced) for core developers commenting on or discussing possible uses for OP_CODESEPARATOR.


Does python-bitcoinlib and the Bitcoin Core functional test framework share code? Were changes ever pushed down/upstream? Does python-bitcoinlib and the Bitcoin Core functional test framework share code? Were changes ever pushed down/upstream?

script.py of the Bitcoin Core functional test framework contains a comment that it was initially modified from python-bitcoinlib.
There doesn't appear to have been any code sharing beyond that and certainly not any later changes pushed up/downstream.
I asked Kanzure (previous maintainer of python-bitcoinlib) on IRC about it and he said:

python-bitcoinlib is forked from a thing that was itself incorporated into bitcoin core's functional test framework or the thing it was forked from was from code in the bitcoin core repository, i forget the lineage exactly but python-bitcoinlib came later


Why is the Litecoin blockchain smaller than the Bitcoin one? I do not understand why Litecoin's blockchain size is an order of magnitude smaller than Bitcoin's. Indeed according to this link the Bitcoin blockchain requires 196.52 GB and Litecoin's 16.55 GB.

In my expectation, the Litecoin blockchain should be bigger because the block size limit is the same, but the block interval is a quarter of the block interval of bitcoin.

Is this due to the smaller user base of Litecoin compared to Bitcoin?

Up until 2017, both BTC and LTC had 1 MB block limit. When SegWit was soft-forked into both protocols, the capacity increased to a hypothetical 4 MB blockweight limit.

But the limit doesn't mean every block that's produced is 1 MB.  All it means is that it can not exceed 1 MB.  What determines the size of the block is the size of the transactions in the block.

Let's say, the data size of a "one in" and "one out" transaction is about 200 bytes.  Now let's pretend, there are 100 transactions like this that are included in a single block.  That means the total size of this block would be about 2 kB.  This is significantly smaller than 1 MB.

This is one of the reasons why LTC's blocksize is smaller than BTC's even though it blocks 4 times as fast. The actual blocks submitted and recorded were significantly smaller than 1 MB because there hasn't been as much activity on the network.  Another reason, like D Nguyen mentioned, is that LTC was started 2 years after BTC.


How to import multi sig using importmulti correctly? I create a 2 of 2 with createmultisig using 02254aba14091e45a9067fbe5b225b3863d1c49650226d583dcede06a7c33f8613 and 02ad64a03b7fc53c02f68eac04743b819bfeeabe6ca7007f473dbaf7c3570f5dc9 pubkeys.

I then

curl --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "importmulti", "params":[[{ "scriptPubKey": { "address": "2NETfDLgh1VmER2RGRnEeWqx73Hn4xhJpU5" }, "label": "Imported MultiSig", "timestamp": "now", "keypool": false, "internal": false, "redeemscript": "522102254aba14091e45a9067fbe5b225b3863d1c49650226d583dcede06a7c33f86132102ad64a03b7fc53c02f68eac04743b819bfeeabe6ca7007f473dbaf7c3570f5dc952ae", "pubkeys": ["02254aba14091e45a9067fbe5b225b3863d1c49650226d583dcede06a7c33f8613", "02ad64a03b7fc53c02f68eac04743b819bfeeabe6ca7007f473dbaf7c3570f5dc9"] }], ''{"rescan": false}''] }' -H 'content-type: text/plain;' http://user:password@127.0.0.1:18332/

Which returns a warning:

success = 1;
            warnings =             (
                "Importing as non-solvable: redeemScript does not match the scriptPubKey. If this is intentional, don't provide any keys, pubkeys, witnessscript, or redeemscript."
            );

I am using the address and redemption script createmultisig returns.

What am I doing wrong? Why is the redemption script incorrect?

My goal is to add the multi sig wallet to my node so that I can build transactions with the wallet without having to manually input the redemption script.

createmultisig is likely giving you the p2sh-segwit address, not the p2sh one. This means that the "redeemScript" you get from it is actually the witnessScript and the real redeemScript is the p2wsh script for your witnessScript. You can tell createmultisig to create just a p2sh address by setting the address type parameter to legacy.

Alternatively, you can get the redeemScript for your witnessScript by usingdecodescript.decodescript` will first decode your script, then it will give you the various possible addresses for it (for each address type available) along with the scripts for them.


load balancing bitcoind Taking the question a step back.

I'm looking to build payment using bitcoin myself. The whole point of bitcoin is decentralisation and sovereignty.

Basically I need High Availability set up for bitcoin full node myself with no single point of failure. So that my website can reliably transact and receive payments.

== Original Text ==
Any one know or tried running bitcoin core server with the data stored on a NAS and a load balancer in front of it?

I'm basically looking for some kind of high availability set up (on aws with autoscaling group / EFS / ELB)

This won't work. Multiple instances of Bitcoin Core cannot use the same datadir. Furthermore, LevelDB does not usually work well with network storage so you probably can't even get the datadir to actually be stored on a NAS and still have Bitcoin Core work properly.

You could have multiple Bitcoin Core instances running behind a load balancer, but it probably won't be as useful as you think it will be.


Why estimatesmart fee returning the same fee for diffeent blocks number? I am trying to calculate the fee per kb using the estimatesmartfee.

I had called estimatesmart fee with  different type of blocks number .The fee remaing the same.

estimatesmartfee(2)=estimatesmartfee(6)=estimatesmartfee(24)

above statement seems to be correct . Please let me know if there is some another changes need to be done using the estimatesmartfee

The estimatesmartfee fee estimation algorithm maintains local historical records of two things:

Transaction fees (sat/B) of confirmed transactions
Target Intervals: Blocks between mempool acceptance and confirmation

Based on these records, the algorithm will be able to provide an estimation of the minimum fees required to obtain confirmation within your specified block interval target n.

Specifically, when you query estimatesmartfee(n), you are asking for a 95% historic probability that your transaction will be mined in n blocks.

There are two possibilities for why estimatesmartfee(n) will return equal fees for different targets.

It returns -1: The method doesn't have enough historical mempool records to perform the estimation.
For the mempool records on your local server, the fee rates for 95% confirmation probability within your indicated target values n fall within the same fee bucket range, resulting in the same sat/b values returned.

You may want to run the server a little longer and see if these values change.


What is the optimal Bitcoin Core 0.17 settings in bitcoin.conf settings for running a full node with a very beefy system? Is there an optimal bitcoin.conf setting file I should use when running a bitcoin core full node? I have a very beefy system with 16 core processor, 32gb ram, and nvme hard drive. I wan't to be able to dedicated as much resources as needed for the full node. I'm also running other nodes too, but would like to know what are the optimal settings in bitcoin.conf file.

I just learned about dbcache and this speeds up --reindex and would've been great if I had this setting in my bitcoin.conf file. Now I'm wondering what are some other optimal settings I should be putting in my bitcoin.conf file?

dbcache is the only significant performance influencing option.  Performance may be improved somewhat by increasing receive and send buffer sizes.

You don't specify exactly what application's you're concerned with speeding up.  To lower block reception latency you could connect to matt's public fibre network. See http://bitcoinfibre.org/public-network.html


For deterministic wallets, which key is better to give out? I am just finding out about deterministic wallets. I have read here that it is possible to derive the private key if one happens to have given out both master public key AND a child private key.

So if we want to give someone a key to send funds to, is there a better one to give out? Or can it be any, as long as we don't give out the other one?

You give out a single address, as with a normal wallet. The master private key and master public key are both for use locally and should never be shared with any party, especially not the former.


Can I check balance of wallet.dat without downloading the block chain? I have bitcoin associated with a wallet that I am now moving from a server to external storage for backup. As far as I know, all I need to do is copy the wallet.dat file to external storage and I'm good (given that I won't be doing any transactions in the foreseeable future).

My question is: once I move the wallet.dat file over, how do I check --without downloading the block chain -- the balance associated with it to make sure all is well?

I think your question has an underlying misconception. The wallet only contains bitcoins in an abstract sense: In realitas the wallet only stores the private keys that enable you to spend the bitcoin balance that is associated with your addresses. Think of it this way: When you look into your wallet, you only see a number of little boxes. You know that all these boxes are yours, but from the outside all boxes look the same, regardless of what they contain. You can only know how much you have in this boxes, by opening each of the and counting their contents. This "looking into the boxes" step happens by looking up the balances of your addresses in the public ledger (the block chain). The wallet.dat might contain the balance that was last counted when you compared to the blockchain, but can only be updated to the current state when counting the contents of the little boxes again.

So, without downloading the blockchain and having your software calculate your current balance, you could only check "if everything is alright" by looking up specific addresses. If you received your bitcoins in one transaction the balance is associated only with one address and this address could easily be written down or memorized separately from the wallet. You could then proceed to look up the balance of it on a website such as for example http://blockchain.info. This can be done safely, as the address alone does not allow anyone to spend the bitcoins.

So, summing up: Just from the wallet.dat you cannot get an update on the balance without acquiring additional information. You can however check the balance of addresses directly by using publicly available information.


Multiple transactions to one address I am having some trouble understanding the following. Lets say Alice, Bob and Charlie all sends me 1 BTC each to the same address. I want to transfer 1.5 BTC to Dennis, would it then take Alice and Bob's UTXO and send it, or would it take Alice, Bob and Charlie's unspent transactions send it and then resend me the 1.5 BTC as change?

I understand that is how it works with wallets, but I am unsure if an address aggregates UTXO, or whether they still remain separated.

You would only need to use Alice and Bob's UTXOs to transfer 1.5 to Dennis. You would then get a new UTXO worth 0.5 sent to you as change (minus network fees). This would leave you with your origional UTXO worth 1 BTC from Charlie and a new UTXO worth 0.5 BTC from your transaction to Dennis.


Mini private key with character "l"? When trying to redeem a btcc chip I noticed a bad encoded mini private key. One of the character is "l". Anyway has seen this before? I guess these keys are also base58 normally?
Thanks

Solved: it appeared to be an "i" but the private key showed it as "l".


What's the easiest way to someone to double-spend 0-confirmation transactions? I heard there is a desktop app today that 'easily double spends 0-conf tx'. Which is it? Is anyone working on a mobile version of this app?

Peter Todd wrote [Replace-By-Fee Tools](https://github.com/petertodd/replace-by-fee-tools
)

  Basic usage:

  ./double-spend.py <address> <amount>

  Creates two transactions in succession. The first pays the specified
  amount to the specified address. The second double-spends that
  transaction with a transaction with higher fees, paying only the
  change address. In addition you can optionally specify that the first
  transaction additional OP-RETURN, multisig, and "blacklisted" address
  outputs. Some miners won't accept transactions with these output
  types; those miners will accept the second double-spend transaction,
  helping you achieve a succesful double-spend.


Relative performance of various mining software? Has any measured the relative performance of various mining software? I figure such a study would be very beneficial for all the miners to choose the most optimal software out there to squeeze out the most bang for their buck.

I think the closest thing is the bitcoin mining hardware comparison:

https://en.bitcoin.it/wiki/Mining_hardware_comparison

Miners have different performance with different hardware architectures, so which miner is fastest for you depends on which hardware you have (AMD GCN/VLIW4/VLIW5, NVIDIA, different FPGAs).

It might be an idea to start a wiki page for a mining software comparison. Alternatively, adding more measurements on the hardware page could do the same thing (but might bloat the page a bit).


Armory - Master Public Key I'm looking into generating addresses outside of Armory using https://github.com/prusnak/addrgen. It requires a master public key which I can't seem find. Does anybody know where I might find it or is Armory not compatible such a system?

AFAIK Electrum is the only client that supports Master Public Keys as of now. Electrum uses a deterministic seed and also have an MPK that can derive bitcoin addresses that belongs to that seed. So people can generate addresses to receive, but can't spend from them; this is called a seedless wallet.


api.pro.coinbase.com retrieve historic candles data I am using PHP to retrieve historic candles data from api.pro.coinbase.com

https://api.pro.coinbase.com/products/BTC-USD/candles?granularity=86400

Above URL gets 300 candles. I would like to know how I can get more or less candles.

In bitfinex I can set the number of candles (up to 1000) using limit parameter like this https://api.bitfinex.com/v2/candles/trade:1D:tBTCUSD/hist?limit=1000

Im working on the same thing. You have to repeat the request.

For 1000 candles you need to loop the request 3-4 times with different start and end parameters.

I had it working for hole hours but now that I switched to minute granularity the request comes out weird.


Can I sell Bitcoin bought in 2014? In 2014, my cousin told me about bitcoins. I thought they were pretty cool, so I went to coinbase and bought 10 at the time (I was 14 at the time). Then, my best friends grandparents passed away and I forgot about them ever since.

Now I am 17, and today I logged on and am shocked to see coinbase says my 10 bitcoins are worth $60,000 dollars. How can this be? I am tempted to cash it out but feel this is illegal and the goverment is going to be on me. Should I tell coinbase there is a bug in the system or something? Has anyone had a similar situation?

10 bitcoins are worth $60,000 dollars. How can this be?

Indeed, the price has skyrocketed recently, each bitcoin is worth around $6092.00 USD as of writing this answer, it's not a glitch.

  I am tempted to cash it out but feel this is illegal and the goverment is going to be on me.

It's not illegal to sell or buy bitcoins in most countries, see: https://en.m.wikipedia.org/wiki/Legality_of_bitcoin_by_country_or_territory
You should probably just ensure you pay tax on the income.


Bitcoin Performance: What does Hashes/Second Mean? Computing preimages (nonces) that satisfy a hash output with known property (minimum number of prefixed zeroes) is the foundation of bit-coin mining and block-chain validation. For this purpose, all available hardware, whether general purpose PCs and servers or custom ASICs that specifically target bitcoin mining, is rated for performance in terms of "Hashes/sec, Mega Hashes/Sec, or Giga Hashes/Sec".

Without specifying the length of the data  that is hashed, I find this rating of HW in terms of 'Hashes/Sec' to be vague at best. All hashing algorithms input messages of arbitrary length  and computed an fixed length message digest. So, a processing power that performs a "million hashes per second" over input blocks of length 100 bytes is not quite the same of another HW that can perform 'million hashes per second' with input blocks where the block length is 4 kilo bytes.

Questions:

What does it mean to say 'my HW can perform x hashes/sec'? Does each 'hash' refer to the block size of SHA256 algorithm, which is 512 bits?
Or, does a hash refer to hashing a block chain, whose length is highly variable subject to the transactions that define a block-chain?
Is there is a well known benchmark program that can measure the 'hashes/sec' supported by any piece of HW?

Without clarifying the above details & publishing a benchmark that everyone can look up to, vendors' claims of "Hashes/Sec" seems like a marketing ploy to me.

[Added Later]
I have a further question on the details of how a valid nonce is searched. As I understand it, the search is determined by 3 parameters

(a) The block header
(b) target string
(c) nonce

A representative pseudo code that searches for the nonce can be written as:

while (hash_256(hash_256(block_header, nonce) >= target_string) do

      nonce = nonce + 1

end_while

I have modeled the above pseudo code from this blog of Ken Schriff. It is not clear how this code models the 'difficulty' parameter. Above loop (as well as the one found in the blog) iterates through all nonce values from 0 through (2^32-1). Or, exactly 4 billion iterations of the hash function. Even a PC with a 12 year old Pentium 4 CPU that performs at 1 MHashes/Sec (cf. Mining Hardware Comparison) can crack this in 4000 seconds, or in about an hour. Custom ASICs with GHashes/sec performance will crack it in a second.

What is the correction needed to reflect the 'difficulty' parameter in this pseudocode? Does the size of the nonce have to be related to the difficulty ?

SHA256 uses a compression function that maps a 64 byte input block and a 32 byte chaining state to the next chaining state. It divides the message into 64 byte blocks and hashes those sequentially.

The bitcoin proof of work uses SHA256(SHA256(block_header)). Between each hashing attempt only 4 bytes in the last block of the header change, so for each hashing attempt you only need to compress that last block of the message and then one compression for the outer hash.

So one bitcoin hash corresponds to two SHA-256 compressions. In definition of "Hash/s" says how many nonces can be evaluated per second which is a meaningful definition in this context.

The header contains the (root of a tree)hash of the actual block. But since the actual block only changes every 4 billion nonces, the cost up updating it is small compared to the cost of hashing the header. That's why it's neglected in those performance claims.

To compare different hardware you need to use miners specialized for that hardware. There are CPU, GPU, FPGA and ASIC based miners. Mining hardware comparison on the bitcoin wiki lists the performance of many different kinds of hardware. Nowadays only ASIC is competitive, for other kinds of hardware the cost of buying and electricity exceeds the earned bitcoins.


Will fees be charged when importing a key to my wallet? When the option to import/export keys is implemented, will fees be charged in this kind of transaction?

My friend exports a key from their wallet with 2 BTC.
My friend sends me this exported key by email.
I receive the key and import it to my wallet.

Since the "transaction" is not going through the bitcoin network, I can't see how a fee could be charged.


What is the average number of hashes it takes to mine bitcoins? I'm just curious about this. I'm not sure if the length of zeros in the hash result is directly proportional to the probability, or how to calculate this.

(Average hashing power of network per second between the last difficulty adjustment and the difficulty adjustment that came before it) * 600

or (2^32 * difficulty)


May it be a risk to use the origin as the change address? Follow scenario: The balance of my origin address is 1 BTC. I'm transfering 0.1 BTC to a shop where I'm buying some goods, my wallet returns the change to my origin address. Now my origin address has a balance of 0.9 BTC. I buy another 0.1 BTC on an exchange and transfer it to my origin address, which now has again a balance of 1 BTC (as much as it had at the beginning).

As far as I understood a transaction is a block of data containing the transaction's details and a signature generated with my private key. If I redo the first transaction to the shop the data block created will look binary identical (same amount, same origin, same receivers), and also the balance of the origin is high enough.

What hinders someone else to resend my transaction in the blockchain network, or a miner to duplicate my transaction, as soon as the balance has refreshed to a value high enough to fulfill the transaction. I'm still missing a hint what invalidates a transaction after it was confirmed.

If I never use a bitcoin address twice, I would be safe.

I am very grateful for any tip what I might have overlooked!

A transaction doesn't just identify a sending address as the source of its funds; it identifies a specific output of a specific previous transaction (by transaction ID and output number), called a txout for short.  Once a txout has been used as an input for a new transaction, nodes mark that txout as "spent" and any future transactions that attempt to spend it will be considered invalid.  (This means that the funds in the txout have to be completely consumed by the transaction; if that is a larger amount than you wanted to spend, you need a change output.  This is the whole reason to have change.)

In particular, this rule will prevent a transaction from being included verbatim in the blockchain a second time.  So any attempt to replay an existing transaction would not result in extra funds being sent.


Why is the accept / utility of one of my miners consistently higher than the others? I'm playing around with a couple of Antminer U2s, and two Block Erupters, running them off of a vanilla BFG setup using BTCGuild, I'm consistently seeing the following:

So, I'm curious as to why one of my miners (always a single AMU) always has such a higher Accept and Utility statistic than the other devices.

It appears that the worker with the more shares/utility is solving low difficulty pool shares, where the other 3 are probably mining at a more appropriate difficulty level.

Utility is the measure of how many shares are submitted per minute (diff1*pool difficulty mining at). That suggests further that the unit is working on lower difficulty shares than the other workers.

Usually on your pool website there will be a spot to change worker difficulty, and for those units, I would recommend 2 for the ICA and 8 for AMU, but you could always adjust according to your preference.


Will bitcoind save all wallet transactions in prune mode? I have bitcoind running in prune mode (last 10000MiB). Will daemon have info about all my wallet’s transactions or just those that will fit 10000MiB tail?

As long as the wallet is in place before bitcoin core has a chance to
  prune anything, it will work properly
  Reference Link

Let me explain. Basically here is a simplified version of how bitcoind stores wallet transactions:

wallet.dat contains Private Keys | Synced upto Block | Wallet transactions
When new block arrives, bitcoind looks for wallet transactions in the block and adds the ones found into  wallet.dat and also updates Synced upto Block field
In prune mode, older block data is removed, nothing happens to wallet.dat

So if you activate prune mode on a running node, or boot up an old bitcoin node everything should work.
However, if you import an older wallet.dat into already running pruned node, it has to rescan everything from Synced upto Block to find the transactions. This may not be possible due to missing block data


Do miners keep a "balance" of how much each public key has? I am trying to understand how double spending can be prevented if mining nodes do not keep a current "balance" of BTC associated with an account?

If they do keep the current balance isn't this a problem as the number of potential accounts is very, very large? That is, if each account balance takes up space in memory, and more accounts are created then the only way nodes can keep up is when the rate of growth of accounts is less than the rate of growth of available memory per node?

Am I missing something?

The notion of accounts is for human convenience. The system doesn't care that you think of all the coins accessible by the same private key as a single account.

Instead, miners keep an efficiently organized database of all UTXOs (unspent transaction outputs). When a miner validates a transaction, it checks that each input corresponds to a valid UTXO.

There's no need to keep the UTXO database in memory. Storing it on disk is fine as long as it is efficiently indexed. Since it's kept for precisely for this purpose, it is efficiently indexed for this purpose.


Where, in the code, in the Satoshi client is 21 million cap implemented? Which fragment of the Satoshi client is verifying if announced block has a valid reward?

I mean, we now live in the 25 BTC reward period. I guess client after receiving a newly minted block, does verifications, like checking if inputs and outputs are balancing for example, and, I guess, if the reward is 25 BTC, right?

So where is this fragment of the code?

I know where is the code which limits BTC supply to 21 million:

    int64 static GetBlockValue(int nHeight, int64 nFees)
    {
        int64 nSubsidy = 50 * COIN;

        // Subsidy is cut in half every 210000 blocks, which will occur approximately every 4 years
        nSubsidy >>= (nHeight / 210000);

        return nSubsidy + nFees;
    }

...and I am looking for somebody to point me to the right place, where the verification is done.

There are 3 places where GetBlockValue is called. One is on incoming blocks, one is on blocks we're mining, and one is an error message. This is the one for incoming blocks:

if (vtx[0].GetValueOut() > GetBlockValue(pindex->nHeight, nFees))
    return state.DoS(100, error("ConnectBlock() : coinbase pays too much (actual=%"PRI64d" vs limit=%"PRI64d")", vtx[0].GetValueOut(), GetBlockValue(pindex->nHeight, nFees)));

Source

This looks at the first transaction (the coinbase transaction) and checks the value. If it is larger than the subsidy plus the fees, then the block is rejected and the node that sent the block is blacklisted.


Parameters in UpdateTip - calculation of log2_work I looked up log2_work inside main.cpp and I can't follow its calculation by log(chainActive.Tip()->nChainWork.getdouble())/log(2.0).

a) What is -> explicitely indicating? (I'm at basic level of C++)

b) And what is log2_work exactly saying? Does it quantify the effort of calculation?

Related Question: here

FYI the code under discussion is available here on GitHub.

-> is a member access operator in C++, just as . is. They both expect the name of an object's member on the right (e.g. a member function or variable). The difference is that . expects an object on the left, whereas -> expects a pointer to an object which it first dereferences.

So chainActive.Tip()->nChainWork.getdouble() starts with the active chain, gets a pointer to a CBlockIndex object which represents the current tip, dereferences that pointer and gets the total chain work of the tip (which is a 256 bit integer), and converts it to a double.

Next it calculates natural_log(total_chain_work) / natural_log(2), which is the same as calculating log_base_2(total_chain_work). I presume this is simply to make the output smaller, as opposed to having to output the entire (much longer) total_chain_work.

If you'd like to get it back into the total_chain_work format used in older versions, just calculate 2log2_work, e.g. pow(2.0, log2_work).


What is a hash pre-image as it is used for the breach remedy? Until this afternoon I thought the anti-cheat transactions or breach remedies built on the exit-transaction of the counterparty.

Apparently, they build on something called a "hash pre-image". What is it the pre-image from? How and why can it be used to create a transaction once the counterparty tries to breach the payment channel?

In the image below from Rusty Russell's Deployable Lightning paper, you can see a visualization of the commitment transactions and their outputs:

For each payment in a channel, there are two commitment transactions generated, one for Alice and one for Bob.  Both Alice and Bob sign both commitment transactions, so they're both valid transactions (although only one of them could be included in the blockchain since both transactions spend the same inputs).

Both transactions pay two outputs.  The transaction Alice has (on the left in the diagram, Commit TxA) pays the following two scripts:

A regular P2PKH (or its segwit equivalent) output that Bob can spend at his leisure.
An output that Alice can spend after waiting a specified number of blocks (let's say 100), as enforced with OP_CSV, or which Bob can spend if he has a piece of data that hashes to a value in this output.  I call this the pre-image; in other descriptions of Lightning this is a private key used to generate a signature.

In the transaction that Bob has (on the right, TxB) these are reversed, there's:

An output that pays Alice using P2PKH.
An output that Bob can spend after waiting 100 blocks or which Alice can spend at any time using a pre-image.

In these outputs, Alice selects the pre-image that prevents Bob from spending her output (Revocation-A) and Bob selects the pre-image that prevents Alice from spending his output (Revocation-B).  They could use a random number of large size, although they'll probably both use hashes from a hashchain generated using Rusty Russell's 64-dimensional shachain to allow compact storage of any revealed hashes, seeding the chain with some initial random value.

Each time Alice and Bob agree to update the state of the channel, they both reveal to the other person the pre-image for the hashlock they placed on the output for the previous state of the channel, allowing the other person to create a breach remedy transaction.


What is short pseudocode for determining the total number of bitcoins mined? Here's what I have so far:

total_epochs = current_block_height % 210000
total_coins = 0;

for(i = 1; i <= total_epochs; i++) {
  reward = 100 / 2^(i * 210000 / 210000);
  total_coins += 210000 * reward;
}

But this overaccounts for the total coins. Any simpler strategy that works?

With a\b representing integer division and a%b the remainder of this division:

  blocks_per_epoch = 210000;
  initial_reward = 5 * 10^9;

  current_epoch = current_block_height \ blocks_per_epoch;
  blocks_in_current_epoch = (current_block_height % blocks_per_epoch) + 1;
  current_reward = initial_reward / 2 ^ (current_epoch);

  total_coins = 2 * blocks_per_epoch * (initial_reward - current_reward) +
     blocks_in_current_epoch * current_reward;

Note that this can be off by a few satoshis due to a different rounding.

If you work with integers for the reward, the division for current_reward can be replaced with a bitshift. If not, you can change initial_reward to 50 to give result in BTC instead of satoshis.


Blocks, scaling and segwit question Somewhat new to bitcoin, trying to understand the tech...
For my understanding all the transactions go into a block, every 10 minutes the block is mined and all transactions in it are confirmed. With every block confirmed (meaning every 10 minutes) the older blocks get harder to hack. The blockchain algorithm knows to adjust its own difficulty so that every 10 minutes a block is mined. Is the above correct?

If it is then how come the scaling problem is block size and not block frequency? If the network can adjust it self to the compute power why not resolve a block every minute while decreasing the amount of BTC to be produced with every block and keeping block size at 1MB?

Thanks

You are correct that changing either block size or block frequency would successfully allow more transactions to be confirmed per unit time.

However, changing the block frequency means changing the difficulty adjustment formula.  This requires a hard fork just like changing the maximum block size would.  In either case, network nodes that do not adopt the new rules will consider the new blocks as invalid, and if not everyone agrees to adopt the new rules, the currency will effectively split in two.

If you are going to have a hard fork anyway, changing block size has somewhat fewer technical pitfalls than changing the difficulty adjustment formula.  For instance, increasing the frequency will lead to a higher rate of orphaned blocks, where two miners each find valid blocks almost simultaneously and neither builds on the other.

Also, increasing the block frequency means that "confirmations" would not mean the same as they used to.  We think of "6 confirmations" as a benchmark for a transaction that would be extremely hard to reverse, but what that really means is "60 minutes of mining time".  If you adjusted the frequency so that the average block time was one minute, now everybody would have to use "60 confirmations" as the benchmark for equivalent security, and all software that counted confirmations would have to be updated.   (For instance, think of exchanges that don't want to credit a user's account until their deposits are sufficiently confirmed).  Any software that isn't updated will lose 90% of its security against double spend attacks.  So this would be more disruptive than changing block size.

Here is an example.  The current Bitcoin difficulty is about 6.8e11.  This means that an average of 6.8e11 * 2^32 = 2.9e21 hash operations are needed to mine one block.  Say you have a transaction in block number 400000 in the main chain, and it has 6 confirmations, so we are now at block height 400005.  In order to double-spend, someone would have to create a conflicting transaction in a conflicting block whose parent was block 399999, so the new block would also be at height 400000.  Then they have to mine 5 more blocks on top of their new block to get their new chain to be at least as long as the existing one, and hope that future miners will mine on their new chain instead of the old one.  So this requires mining 6 blocks = 6 * 2.9e21 = 1.7e22 hash operations.

Now imagine you want the average block time to be 1 minute instead, so you cut the difficulty to 6.8e10.  It now takes only 2.9e20 hashes to mine one block.  So a transaction with 6 confirmations under this new scheme only takes 1.7e21 hashes to reverse.  If you want the same security as before, i.e. 1.7e22 hashes needed to reverse, you have to wait for 60 confirmations.


Bitcoin Signature Verification I am trying to implement the OP_CHECKSIG opcode of Bitcoin and verify whether a signature is valid or not. I have the signature that I recieve from the transaction data and the public key(the hex field of a P2PKH transaction should contain both). I am trying to figure out what is the message digest itself that is signed. From what I know these are the required items -

1.The version number(4 bytes)
2.The number of Inputs(1 byte)
3.Transaction hash of the input being redeemed
4.Index of the output being redeemed (4 bytes)
5.ScriptPubKey of the output being redeemed prepended with the length of the script
6.Sequence Number(4 bytes)
7.No of outputs we are signing over(1 byte)
8.Total value of the output(8 bytes)
9.ScriptSig for the output prepended with the length
10.locktime field(4 bytes)
11.hashcode type(4 bytes)

So If I hash this data in byte format twice using the SHA256 Algorithm would my signature verification pass? I am trying to implement this using Java and this is my code -

public static boolean verifyUsingSecp256k1(byte[] pub, byte[] dataForSigning,
    BigInteger[] rs) throws Exception {
ECDSASigner signer = new ECDSASigner();
X9ECParameters params = SECNamedCurves.getByName("secp256k1");
ECDomainParameters ecParams = new ECDomainParameters(params.getCurve(),
        params.getG(), params.getN(), params.getH());
ECPublicKeyParameters pubKeyParams = new ECPublicKeyParameters(ecParams
        .getCurve().decodePoint(pub), ecParams);
signer.init(false, pubKeyParams);

return signer.verifySignature(dataForSigning, rs[0].abs(), rs[1].abs());}

However when I try to verify my Signature it returns as false. Am I missing something over here?

All the above steps are correct although. The only catch over here is that except for the Scripts, everything else is captured in the Little Endian format (for whatever reasons). So except for Step 5  and Step 9 all other data is stored in the Little Endian format. Took me a while to get to this answer! Just a small tip to keep in mind when implementing!


Unconfirmed Transactions Two of my transactions are still unconfirmed after more than 24 hours. The estimated confirmation times at blockchain.info are not accurate.  5 hours ago the estimate was 3 hours now it's saying 22 hours....etc. I know it's because I made the mistake of not including a miners fee. I'll never do that again.  My question is, will they definitely be confirmed eventually?  What happens if they're not?  Here's the link to one of the transactions:

https://blockchain.info/tx/3254c99062b53b1988e84cccdf6c45b2d1fbf429f91c924d916e854797dd8819

Thanks.

They will probably be confirmed eventually. But you don't have to wait. You can just form new transactions that spend the same outputs with the normal fee. The fact that there exists a conflicting unconfirmed transaction will have no effect on other transactions that attempt to spend the same outputs. You can be 100% sure they won't both go through, since an output can only be spent once. Unfortunately, depending on what tools you have, this may be difficult to accomplish.


What is the advantage of HD Wallets? I have read man resources and questions about HD Wallets. As pointed out in this question on SO, it won't be possible to send funds of a derived child address using the master private key.

In my humble opinion exactly this would make sense if I could create a derived child to receive funds for a specific purpose but being able to spend these funds using my master private key without the need to store each child private key.

Do I miss something here? Why should I use HD wallets if I still need to store each single local private key as well?

The answer you linked isn't wrong; you just stopped reading too soon.

Transactions aren't signed by the master private key itself; they are signed by the child private keys.  But those child private keys were generated from the master private key.  So it's true that all you really need to store is the master private key.

If you have the master private key, and you want to sign a transaction, you don't sign it with the master private key directly.  Rather, you first use the master private key to regenerate child private keys until you find the one that matches the address you want to spend from.  Then you use this child private key to sign the transaction.

For day-to-day use, it is convenient to store the child private key after generating it, so that you don't have to go to the trouble of regenerating it each time.  But for backups, all you really need to save is the master private key.


How can I find the coinbase transactions where the bitcoins involved in a transaction were created? I am exploring a transaction and if would like to know when was the money created, I guess I would end up with a lot of coinable transactions.
For a certain transaction I could explore the previous transactions successively until I found the coinbases. But I imagine this would be a very laborious job that could take a lot of resources. Just like blockchains.info trees ( https://blockchain.info/tree/59587897) but expanding the tree till the coinbase transactions

In the other hand I guess nodes when verifying a transaction do something very similar, don’t they?
How could I create this list of coinable transactions that original the bitcoins involved in a particular transaction?

If you have running bitcoin core, you can use JSON RPC and any programming language you want.

getrawtransaction <txid>
decoderawtransaction <hex>

Second call will return all inputs of transaction. If transaction has previous tx equal to 32 zeroes, it is coinbase transaction. You should recursively cycle through all parent transactions.

API calls list


Finding Bitcoin address I sent to I sent my Bitcoin to somewhere but I'm not for sure if it was the correct address. Is there a way that I can see what address i sent it to? BTW the transaction was done on coinbase

You can just login to coinbase then go to Accounts section and choose bitcoin and click on the recent transaction (on the top) and then next to a To (the top text) you will see the address you sent the coin to


Fee too high because of a bug in Bitkey application for Apple? I am new here, hello, yesterday evening I sold 0,99930000 Bitcoins with my Bitkey app. But I was very suprised when it went wrong, and it was seen as a minersfee which Haobtc mining as intermediar transferred it. Please help me Haobtc would not help me.

Thanks Edwin

The transaction details are here.
(304f8e03294ba3dbf0cb66ca9dc5f0a2ae99fff4f880ef252c08ed8e75f877de   0.99927577 BTC 454,889 2017-02-26 21:51:03
1HXfAYqpNnawryLgdare836GFJS9KMLa3f 0.99930000
1DouiKSPh4jqaK5YKeHmMEuKkGkvERcvjx 0.00002423)

I am also new and did my fair work of research. However looking at your scenario if the miner doesnt want to return the fee because of your accident its your problem. Generally good miners will return the fee but that isnt always the case, Its a risk of transactions with cryptocurrency. txid

https://bitcointalk.org/index.php?topic=360099


Can transaction data be altered before creating a block? I'm a novice and had this thought. I understand that data in an existing block can't be altered, as it changes the hash. But what if, before creating the block, I take transactions from the pool, alter one transaction, and then proceed to create the block? Let's say I have the most powerful hardware and finish it before other miners. Will other nodes be able to verify the transaction data inside the block? (example: say A sends 10 tokens to B, and I change that to 100. A has 200 tokens in his wallet)

You can modify it, but in doing so, you will invalidate the signature on the transaction, since the data is no longer the same as what was signed.

You could do so on transactions that don't involve signatures, but they are generally non-standard on the mainnet.

Note that even after modification, you can only update it within the bounds of the input(s) sum. You can never modify a transaction to have an output greater than the sum of the inputs.


Is there a service where you can generate public/private keys without anyone knowing? Like a tamperproof digital envelope Is there a service where it generates a BTC address with public/private key, but no one knows it until someone pays a fee to reveal it? The idea is basically, some script or some other decentralized system will generate a btc private key, then encrypt it somehow. And in order to decrypt the encoded private key, a certain fee has to be paid. But the public key is exposed publicly.

I guess the idea is akin to generating a btc paper wallet private key, and then putting a few bitcoins in it. Then seal it inside a tamper proof envelope and then display the public key on the outside of the envelope. Now you can give this envelope to anyone physically without it showing on the blockchain.

But is there a service like this?

From what you describe, I'm guessing that what you are looking for is something like Casascius coins. These display the public key but conceal the private key behind a tamper evident holographic sticker. This means that when you pass a physical coin to someone, they know that you don't have the private key, so they are the sole owner of the bitcoins at that address.

If this is what you are looking for, there are a few problems to bear in mind:

The manufacturer of the coins puts the private key behind the sticker, so you are trusting that they did not also keep a record of the private key.
You are trusting in the effectiveness of the tamper evident sticker.
Since November 2013, Casascius no longer sells these coins, although there are many in existence sold before that point.

The first point can be solved by using 2 factor authentication, so that the string that the manufacturer hides behind the sticker is useless without a password that is never shared with the manufacturer.

So what you require is possible, although sidestepping the blockchain does introduce trust in the tamper evident nature of whatever method you use to conceal the private key. If the value stored by this method is sufficiently small per item to make the level of trust acceptable, then this may not be a problem.

Tamper evident method without the physical form

If you are looking to use this approach without the physical form, then I can't see a way of keeping ownership to just a single person without either a decentralised system that is effectively a parallel version of the block chain, or a centralised system where you have to place trust in those running it.

The solution to this problem of trust is the block chain - the public distributed ledger. If you want to avoid using the block chain, then you are going to have to live with the trust problem unless you can invent something new.

Anonymity

If the underlying reason for asking this question is that you want to conduct transactions anonymously, there are a variety of ways of doing this which you can learn about by browsing the anonymity tag.


Is a bootstrap.dat virus possible? Recently I learned that someone has injected an old virus signature into the bitcoin blockchain, though it does not run the chance of infecting the computer.

  http://newsbtc.com/2014/05/16/virus-signature-uploaded-bitcoin-blockchain-causing-mse-users-grief/

This makes me wonder, if I were to install bitcoin-core and download a malicious bootstrap.dat file, would it be possible for it to infect my system through bitcoin?

No, it's not possible. With the exception of Script commands, nothing in the blockchain is executed by Bitcoin Core: it's just data. Scripts are only able to do things like hashing and arithmetic, so it's hard to imagine any sort of Script-based malware.

It's conceivable that malware (once delivered to your computer via other means) could use the blockchain to download additional malware or transmit signals to infected machines, but it seems like it'd be way more trouble than it's worth to me. (if you have any sort of Bitcoin-informed malware, the most profitable thing to do would almost certainly be to steal the user's bitcoins, not use the blockchain for clandestine messages)


What is the most accurate Classification Of Bitcoin? What is the most accurate classification of Bitcoin as a piece of computer "software"?

would it be considered:

An Operating system.
An Application.
A File.
A Library.
A Network.
A Server.
Framework.
Assembly Level Code.
Application Binary Interface.

These are just the examples that came to mind at the time of writing.

Please feel free to improve the efficiency and effectiveness of this question.

Bitcoin is a digital currency. It is described as a "Bitcoin: A Peer-to-Peer Electronic Cash System" in the Bitcoin Whitepaper.

Bitcoin Core is a software application that implements Bitcoin.

Anyone can implement a software application to interact with the Bitcoin network (network of computers that all agree on the same protocol rules). So perhaps it is most accurately described as a network that follows a strict protocol similar to email. There are many email clients, but they can all communicate with each other.

  Bitcoin is an experimental digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Bitcoin Core is the name of open source software which enables the use of this currency.

See https://github.com/bitcoin/bitcoin/#what-is-bitcoin


Transaction unconfirmed - day 12! I've got a transaction from 2017-12-06 that's still unconfirmed - i really need this money now as ive moved house - how can i get this sorted - I am will to pay for help at this point.

Can anyone please help?? Tim.

https://blockchain.info/tx/44c784d8f82d962103ffdf5d463a1460150a21cc67a0750d4a3f6a35a0d18d9a

This question is another duplicate and already answered here by dooode:
Why is my transaction not getting confirmed and what can I do about it?

You have to stop/reverse the old Bitcoin transaction you created without confirmations:
Make a backup of your wallet.dat

Run bitcoind or bitcoin-qt with -zapwallettxes=1 option.

This makes the wallet "forget" any unconfirmed transactions, thus enabling you to reuse their inputs.
Create a new transaction to make your payment and add an appropriate fee this time.

You can now send the bitcoins where ever you want or you can send them all back to yourself.


Copay wallet problem: "Could not update Wallet: Network connection error" Apparently BitPay's servers must be down because I can browse the internet but my copay wallet is stuck in this error:

Is there any way to know if it's really an issue on their end and if they're looking at it? Do they have a status twitter page or something?

(This kind of things are really unfortunate, which can hinder adoption. I guess my only way to avoid it would be to run my own bitcore node, right?)

After some hours, it started to work again. Apparently bitpay's servers were down for a bit.


Have any SPV users lost money because they accepted forged bitcoins? I'm making a list of real-life examples of occasions where bitcoins were lost to various known attacks. One of these known attacks is that lightweight (SPV) wallets can't verify whether a transaction only spends UTXOs (a requirement full nodes enforce) so lightweight wallets can be tricked into accepting bitcoins that don't really exist.

Of course, only a dishonest miner would confirm that transaction, making the attack expensive if confirmations have to be involved.

Does anyone know of a real-life example of a user who lost money to this attack, either involving an unconfirmed transaction or a confirmed transaction?  I'd prefer an example from Bitcoin, but examples from altcoins are welcome too.

I run simplecoin.cz|sk|pl|eu bitcoin exchange. We use different wallets and we made 10k+ transactions. We lost some bitcoins. Most of it was human errors. Some bitcoins were lost when transactions took days to confirm during network flooding. We encountered some double spend transactions (which did not confirm)

On other hand we never lost bitcoins when transaction had one or more confirmations.

I'm not sure if spv wallet can be fooled when transaction has confirmation already. We trade 5k$ almost every day, our conclusion is to wait for confirmation and know your customer.

There's also another risk in accepting even very small unconfirmed transaction and spending it to another customer, because like this you create whole tree of double spends which will never confirm, so you lock your funds for couple days until this toxic stuff gets pruned from memory pool. You also need to resend all this transaction again, it's paid by your time and customer happiness in the end.


How does a double spend get resolved when two miners find conflicting blocks at the same time? I was trying to learn about Bitcoin and its flow. Actually, I was stuck how the control flows in solving the double spend.

For eg. if Ta and Tb are a double spend of the same transaction with different outputs. These two transactions can flow through different path in the network, and assume flow in exactly opposite path. So Ta reaches miner Ma who creates a block and Tb reaches another miner Mb. Now, Ma may solve the block with Ta and Mb with Tb. Both start broadcasting the respective blocks with Ta and Tb to be a part of block chain.

After some time in relay some node may get both transactions and find its invalid but here already the block are relayed.
What happens in such a case and how is the double spend resolved?

Blocks form a chain; each block contains a prev field containing the hash of the block that "precedes" it.  The two blocks Ma and Mb are incompatible (the block chain is not allowed to contain two conflicting transactions), so neither can precede the other.  Hence they must be a "fork"; two different blocks with the same common ancestor.  All other miners will have to decide which fork they want to mine on; e.g. whether they want to create a block whose prev field points to Ma or Mb's block.  It doesn't really matter in this case.

Say the next block is found by Mc and points to the Ma block.  Then the chain ending in Mc is longer, and the next miner will prefer to mine on that side of the fork.    After a few more iterations, it should be clear that the chain including Ma (which has transaction Ta) is longer, and will be preferred by miners from then on.  This means transaction Tb is now dead.  (Moreover, Mb doesn't get to collect their 12.5 BTC block reward, because the block that awards it only exists on a side chain which is dead.)


Is there an altcoin generator with merged-mining support? I am wondering - is there a service similar to CoinCreator that allows one to generate altcoins with built-in support for merged mining?

Yes, http://build-a-co.in/ is an alt coin generator that supports merged mining.

In general, I think it has more settings and is easier to correct settings.


Understanding Storing Bitcoin and wallets I bought some bitcoin and have them saved on my PC on a MultiBit wallet.

I am a little confused as to how they are actually stored.

Are the bitcoins tied to my machine? So if I lose my PC the bitcoins are gone forever.

Or if I download the same multibit wallet on another computer can I enter my password and access my bitcoins from that machine?

Also what is a paper wallet?

And final question..... I have read Multibits policy on restoring wallet and the use of wallet words.  Are wallet words used by all types of wallets or is that just a Multibit specific security measure.

All simplified and intuitive answers will be of benefit as more people are starting to become aware of bitcoin and are probably thinking and asking the same things.

Thanks in advance

Welcome to the world of Bitcoin. One hint at the beginning: you raised too many questions at once, usually people here try to limit to one question, and answer it "accordingly". That makes it easier to follow up. Anyhow:

Bitcoins are not stored in a way you would have money in a wallet. The concept of Bitcoin circles around cryptographic keys (private and public keys). These keys are used to create and validate transactions, which transfer bitcoins from an address A to an address B, all noted down in the blockchain.
Your wallet is an abstraction layer, so that you don't have to work with these cryptographic keys. And every wallet has it's own idea on implementation, though there are some common rules. One of the major rules is: as long as you have the private key (on floppy, USB disk, or noted down on a paper), you are quite independant of any wallet.

Now on Multibit: if your PC crashes, your bitcoins must not be lost. You can make backups, and re-install on a new PC. Multibit has some info on the support pages on how to secure your wallet, by making backups and restores. Better read it carefully, and give it a try on a test machine  :-)
The more precise answer is: if you lose you private key (which is linked to the words of the multibit wallet), then and only then the bitcoins have very, very low probability to be somehow recoverd (all your bitcoins are lost).

On paper wallet: generally a paper wallet is a private key or words derived from the private key noted on a paper, so they can be used at a later stage to recreate a wallet (eventually with all its funds). There is a tag in stackexchange for paper wallet: https://bitcoin.stackexchange.com/questions/tagged/paper-wallet
you may find what it is, or do some web research. It has been answered before.

On Multibits use of words: it is not necessarily working in other wallets. It may work, or may not work. I haven't seen someone doing all the combinations - obviously already too many wallets out there!

My hints to all newcomers in rypto world: do some further research, e.g.:
1. the book „Mastering Bitcoin“, in many languages, by Andreas M. Antonopoulos.
2. „www.bitcoin.org“, with a description of the whole eco system, also in many languages.


First buy or sell of bitcoins What steps do I have to take to buy/sell bitcoins? What's the minimum amount of bitcoins that I can buy, and how much will I pay for transaction in a buy/sell operation?

For a start and to get to know the different exchanges and wallets you should checkout: https://www.bestbitcoinexchange.io/ (I'm not affiliated with that website).

To buy and sell Bitcoin I recommend https://gemini.com and https://xcoins.io. https://coinbase.com is popular but I'm not a huge fan of them for a number of reasons.

Just sign up and add your bank account to purchase Bitcoin. Gemini allows you to buy/sell Ethereum as well.

If you're worried about adding your bank account I would use https://xcoins.io or https://localbitcoins.com


Check if wallet is encrypted or not through RPC API How can one check if their wallet is encrypted through the RPC API without receiving an exception?
I went through the Original Bitcoin client API calls list but didn't find any command that could facilitate this functionality without resulting into an error in the response.
Any ideas or workarounds?

From the source code (rpcprotocol.h):

RPC_WALLET_ERROR                = -4,  // Unspecified problem with wallet (key not found etc.)

So you could check for a JSON-RPC return value of -4, or if you want to be absolutely sure, you can use:

bitcoind [...] -help | grep walletlock

The walletlock RPC command becomes only available (in the -help list) after encrypting your wallet.


ELI5: How does Segregated Witness (segwit) work? Can someone ELI5 Segregated Witness (AKA BIP 141)? I've been doing research and understand that there are segwit addresses, there are segwit transactions, and there are segwit nodes.

I understand that segwit basically works by removing the witness from the scriptSig and somehow it's weighed 1 weight point while other bytes are weighed at 4 weight points, but how?

How do older bitcoin nodes handle the segregated witness? Do they just not receive that data? I know that older nodes will treat those addresses as spendable by anyone since no witness is present or needed. This makes me believe the witness isn't in the transaction at all. But how? Where is the witness actually stored?

Where do segwit addresses come into all of this?

Not all unspent outputs need signature scripts. Of course, this doesn't have many uses (but puzzles. for example, proof of SHA256 collision to redeem funds) but such a thing exists. UTXO that don't need a ScriptSig are called an AnyoneCanSpend outputs. Such transactions are considered nonstandard and are not relayed in the network. However, if a miner includes a nonstandard transaction in their block, their block will be valid and the transaction will be relayed.

A SegWit-P2WSH output looks like this:

00148ca0e5d2474900bf82376926da8c5f4464bd7bd3

Does it start with a version byte? ✓
Does it have a 20-byte Witness Program*? ✓
Is the ScriptSig empty*? ✓

*Doesn't have to be. Details: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki

Congrats, that's a SegWit output! Legacy nodes see it as a nonstandard transaction, and don't relay it. The SegWit nodes check the output for the conditions above, understand that it's a SegWit output. Next, they check the transaction for a valid "witness". It's not a nonstandard transaction for them, and they relay it to the other SegWit nodes. After a miner puts it in their block, legacy nodes will understand that it's a nonstandard/AnyoneCanSpend script, and will honor it.


How does Bitcoin utilize cryptography and secure hash algorithm (SHA) to link records in the blockchain? I am wondering how Bitcoin uses cryptography and secure hash algorithm such as SHA256 to link the records in the blockchain. And if possible I think it will give me a better understanding if there is a demonstration of a figure of blockchains.

A Bitcoin block is a container data structure that aggregates all the transactions. The block is made of a header (containing metadata), followed by a long list of transactions that are included in the block. The block header consists of merkle tree root, previous block header hash, timestamp amongst other metadata.

The Merkle tree root in simpler terms includes the summary of all the transactions in the block using the merkle tree. Every transaction in block is serialized and hashed twice with SHA256 to get the transaction id or txid. These txids of all the transactions in the block is then double-hashed pairwise, with SHA256, until there is only one node at the top called a merkle root. Since this merkle root is built from all the transactions in the block themselves, the root can be thought as containing the summary of all the transactions included. An illustrative example of Merkle root calculation is shown below:

The header portion of the block is hashed twice with SHA256 to get the block header hash (in the mining process). This block header hash is always referenced in the next block in the previousblockhash field. Thus every block is linked to the previous block using its header hash forming a link that goes all the way back to the genesis block like the illustration shown below:

Since SHA256 is a one way mathematical function, there is no way to reverse engineer the data by just looking at the hash. SHA256 is also deterministic, in the sense that a particular data will always give a particular hash. Slightly changing the data will completely change the hash output.

So, if a party wants to change some data in a transaction that is included in a block somewhere in the blockchain, it will change the merkle root of that block. Since merkle root forms the part of the block header, changing the merkle root will completely change the block header hash. Since this hash is referenced in the next block, the current hash will be incompatible with the hash that was referenced and hence this block will not be accepted.

This is where proof of work in mining plays a key role. As I have said above that changing a data in a block completely changes the block header. So if you want to change a data in a past block, you will have to re-mine all subsequent blocks. So you will have to spend the electricity and compute cost to re-mine all the block AND outpace the network by forming the longest chain. The cost of doing such an action is very high, and may not outweigh the benefits that you derive from it, thus providing inherent security to Bitcoin.

Also, I would like to point out that you cannot change transaction data structure at your whims and fancies. Every transaction is signed with a private key that includes the entire transaction data as a message. So, slightly changing the transaction data will render the transaction invalid and including such invalid transactions in a block will render the block invalid. So, in a nutshell all that you can do is include/exclude certain transaction from previous blocks, or make slight cosmetic changes (like ECDSA signature malleability).


Errors running bitcoind in the background I have installed bitcoind on a new computer, and I use nohup to run it:

$ nohup bitcoind &

However, every now and then I see that the process does not exist, and I have to restart it using nohup.

Any idea what went wrong? Are there any logs I can check, and is there a better way to run bitcoind in the background than nohup?

bitcoind has a -daemon command line option that will cause it to run in the background.  That is likely to work better than using nohup.

There should be a debug.log file in your bitcoin data directory where any errors will be logged.


Please help! How do I transfer my wallet from bitcoin core to MultibitHD? I (should by now) have bitcoins in my wallet,I sent them to my wallet whilst i was using bitcoin core but after taking days to sync (and it still hasn't synced) i have given up and installed multibitHD. I have tried using blockchain to import the data file but it keeps saying connection refused even thought the password is correct and the file is fine.

Now Bitcoincore wont even open so i cannot check whether it has synced or whether my bitcoins are still there and I'm beginning to worry that I've lost my money can someone please help me transfer my bitcoin core wallet over to multibitHD!?

Put request in multibithd. Scan or put the address shown and put it in the btc core and make sure the receiving amount in multibithd is the same as the sending amount in btccore. No fees thats for sure


How New Bitcoin Addresses not using Signature ? Only witness or Very Short Signature? I have Noticed Something strange to me
Newly Used Bitcoin Addresses show repeated very short Signatures
and Multiple Witness ??
and Some not even any signature for the transaction ?
what is happening actually ?
example : https://blockchain.info/de/rawaddr/3BMEXokv2vPoEKPn7YWEhXoPYyZuzauLXJ

It looks like that API is just simply broken. If you look at the web page results (or a different blockchain explorer's API for that address, all of script and witness information is presented correctly.


Recovery of scammed funds firstly, a very, very newcomer to this space, and don't have any knowledge of its operation at all. I have been corresponding with individuals regarding recovery of scammed funds which are currently stored as BTC.  I've been told I need to pay 0.19258 BTC to activate the transaction as the account has been suspended because of missing turnover.  I have the details of the hash, which lists 18 different transactions for a total of 4.35 BTC.  Can I send this to my account?  I sure hope the answer is ýes' and if so, how do I go about it?  TIA.

firstly, a very, very newcomer to this space, and don't have any knowledge of its operation at all.

When we lack experience and knowledge, we are easy to trick. Be very very careful. Don't rely on one person to explain this. Especially not a stranger you have never met.

  I have been corresponding with individuals regarding recovery of scammed funds

I would ignore anyone who contacts me privately over Facebook or other social media private messaging.

You'll get better advice if you keep all communications in a public place like this website where many people are reading the questions and will quickly correct any misleading answers.

  I've been told I need to pay 0.19258 BTC to activate the transaction

This usually means someone is trying to steal more money from you. You don't need to pay any kind of activation fee in any normal kind of Bitcoin transaction.

In this situation I would forget about any "scammed funds". They either never really existed or are under the control of a scammer. Usually there is no realistic prospect of recovering control over this money. I would think it prudent to discontinue use of any wallet that was ever under the control of the original scammer or subsequent "helper".

  I have the details of the hash, which lists 18 different transactions

That's probably a Bitcoin address. That doesn't give you control over money, it just lets you see some transactions associated with that address. The address does not identify a person, business or place. Knowing an address doesn't give control over any money.

  a total of 4.35 BTC. Can I send this to my account?

No.

  I sure hope the answer is ýes'

Unfortunately scammers are very good at exploiting hope. They are very convincing. I would stop communicating with them - no good can come of prolonging contact with criminals.


transaction edit done by mining nodes I'm reading through bitcoin manuals and I got this question, please help me to correct my understanding.

I'm aware that changing the transaction output amount value can make the transaction unusable. What happens if the mining nodes lowers the output value to get more transaction fee, in such scenarios how the bitcoin protocol counterfeit that?

Thank You.

Most transactions contain a digital signature which signs a hash of the transaction. Usually this hash includes the entirety of the transaction, so changing any part of the transaction would invalidate the signature and thus invalidate the entire transaction. The miner won't be able to change the output values you signed, because it would change the hash.


How to solve error: Incorrect or no genesis block found. Wrong datadir for network? I am making my own alt-coin, and I have mined the first genesis block hash(after some time), Merkle hash, nnonce and time. I am running on Ubuntu14.04.

But when I run ./bitcoind I get this error

  Error: Incorrect or no genesis block found. Wrong datadir for network?

What does it mean? how do I fix it?

Here is debug.log shows:

2018-04-02 18:33:04 Booducoin version v0.8.7.4-gc1e46ab3a90b-beta ()
2018-04-02 18:33:04 Using OpenSSL version OpenSSL 1.0.1f 6 Jan 2014
2018-04-02 18:33:04 Default data directory /home/boodu/.booducoin
2018-04-02 18:33:04 Using data directory /home/boodu/.booducoin
2018-04-02 18:33:04 Using at most 125 connections (1024 file descriptors available)
2018-04-02 18:33:04 init message: Verifying wallet...
2018-04-02 18:33:04 dbenv.open LogDir=/home/boodu/.booducoin/database ErrorFile=/home/boodu/.booducoin/db.log
2018-04-02 18:33:04 Bound to [::]:9333
2018-04-02 18:33:04 Bound to 0.0.0.0:9333
2018-04-02 18:33:04 init message: Loading block index...
2018-04-02 18:33:04 Opening LevelDB in /home/boodu/.booducoin/blocks/index
2018-04-02 18:33:04 Opened LevelDB successfully
2018-04-02 18:33:04 Opening LevelDB in /home/boodu/.booducoin/chainstate
2018-04-02 18:33:04 Opened LevelDB successfully
2018-04-02 18:33:04 LoadBlockIndexDB(): last block file = 0
2018-04-02 18:33:04 LoadBlockIndexDB(): last block file info: CBlockFileInfo(blocks=1, size=241, heights=0...0, time=2018-04-01...2018-04-01)
2018-04-02 18:33:04 LoadBlockIndexDB(): transaction index disabled
2018-04-02 18:33:04 LoadBlockIndexDB(): hashBestChain=5e55391ddfe7258c5d1dc5ebf2c8ce9bdec72edf482f171a6cb04416c53be9b8  height=0 date=2018-04-0$
2018-04-02 18:33:04 Error: Incorrect or no genesis block found. Wrong datadir for network?
2018-04-02 18:33:04 Shutdown : In progress...
2018-04-02 18:33:04 StopNode()
2018-04-02 18:33:04 Flushed 0 addresses to peers.dat  3ms
2018-04-02 18:33:04 Committing 0 changed transactions to coin database...
2018-04-02 18:33:04 Shutdown : done

Question:

  when I run ./bitcoind I get this error

Error: Incorrect or no genesis block found. Wrong datadir for network?

Answer:

Delete /home/boodu/.booducoin (~/yourcoinname/.yourcoindatadir) folder and restart daemon.


If someone bought an old computer and found Bitcoins in it, could they use it (legally)? Let's say someone bought a used computers which has a copy of a bunch of Bitcoin keypairs. Is he legally allowed to transfer them?

Is this case analogous to finding a pile of cash inside a used bag?

This is going to depend a lot on many surrounding facts. Including where this happens. How you acquired the computer and whether you know who the owner is.

I'm most familiar with the law in Australia (Victoria) where stealing is defined as follows: "A person steals if he dishonestly appropriates property belonging to another with the intention of permanently depriving the other of it." I imagine many common law countries have relatively similar definitions (with important differences for edge cases, of which this is one).

If you see bitcoins as property then your example involves theft. I think most jurisdictions will define bitcoins as a form of property, if they don't there would be all sorts of tax issues. This would be the case in Australia and it would be theft.

To me I don't think this is analogous to finding a pile of cash inside a used bag. I think it is closer to find someone's internet banking username and password inside a bag you purchased. Bitcoins are not physical and the private keys (which is what you would find) merely grant you access to them. Most people would agree that doing anything with the internet banking details would be dishonest.

The difference in my example would be whether destroying the keys would be a crime. It is unlikely to be a problem with internet banking details as there is no expectation this would permanently deprive the person of their property. With bitcoin you don't know if there is a backup so you would at least be recklessly dealing with someone's property.


Blockchain Explorer says received but it's not received yet! I sent some Bitcoin to my friends wallet since 2 days ago. It says approved and sent successfully on my end. And even on blockchain Explorer it says confirmed and received. But my friend says he hasn't received any Bitcoin yet??? This is the transaction ID on blockchain Explorer

https://www.blockchain.com/btc/tx/d350a1334d10e7693b56cc8fd8d11297080e1aebd9ffed97588a4b5f0929ca93

Blockchain Explorer says received but it's not received yet!

That's not how Bitcoin works.

All computer-based wallets, including your friend's, have a copy of the blockchain (or have indirect access to a copy). If the blockchain includes your transaction, then the money has been received. All copies of the blockchain are eventually identical, only the last block or two might very occasionally differ for a short while.

Note that you can receive Bitcoin even if your wallet exists only as a secret number written on a piece of paper. The blockchain is the true record of what has been received.

If your friend says their wallet has not received the money there are at least three possibilities

They are lying
Their wallet has not got an up-to-date copy of the blockchain (i.e. is not "synchronised")
You sent the money to the wrong address somehow.


Segwit transaction in golang I tried to create transaction which spends p2sh(p2wpkh) output:

from wif I derived compressed pub key: "035476e55521c97cf0489e6c57893a99d67e84d306a69e6b6904f324c11b3cef8d".
created witness program: "813798fcae182d1a36c6b4bb5f69e03bb9ec4124".
created script: "0014813798fcae182d1a36c6b4bb5f69e03bb9ec4124" and sigscript from script which should be specified to spend this ouput: "160014813798fcae182d1a36c6b4bb5f69e03bb9ec4124".
added tx input: {hash: "863fea23ba1c176bda5e360b0be25cacc405877aa3e46a3e1c60196c3b6cd7b6", vout: 0, signatureScript: scriptSig, witeness: nil}
created pkscript for address "14s9ocrbTX3ZCybtcN1jmtdxxJwKuyM3Em" (p2sh-p2wpkh): "a914809800f62119afdcf2317882eda5efd7a9a2163487".
added txout {amount: 11000, scriptPubKey: pkscript}
calculated txSigHashes := txscript.NewTxSigHashes(tx)
decoded utxo subscript into bytes: "a914bb4d332112bde9787ac2da5954ee5a2c5fbada6987".
derived witness signature: wit := txscript.WitnessSignature(tx, txSigHashes, 0, amount, subscript, txscript.SigHashAll, wif.PrivKey, true)
result: "3045022100bae83fd9e87751350a09bc4c120b29decadb13fb389541c3025a8982906602d5022005dc688901fd27b749cfd4ce14a62587f267a070984654271454e88cc3f9ed4e01 035476e55521c97cf0489e6c57893a99d67e84d306a69e6b6904f324c11b3cef8d".
added witness signature to tx.TxIn[0].Witness
Serializied signed tx: "01000000000101b6d76c3b6c19601c3e6ae4a37a8705c4ac5ce20b0b365eda6b171cba23ea3f860000000017160014813798fcae182d1a36c6b4bb5f69e03bb9ec4124ffffffff01f82a000000000000434104b2534d287f2d9fa908319557298591143fecbd3f6497d6d11f283b80c3248c35f580ff376805418c3610256bc102c0beb3e9f745d493aed81127f5d4a4921bebac02483045022100bae83fd9e87751350a09bc4c120b29decadb13fb389541c3025a8982906602d5022005dc688901fd27b749cfd4ce14a62587f267a070984654271454e88cc3f9ed4e0121035476e55521c97cf0489e6c57893a99d67e84d306a69e6b6904f324c11b3cef8d00000000"

Even if I followed all the rules to create this transaction any try to push it into mainnet (via Blockcypher and other services) failed because of this error: "Error validating transaction: Error running script for input 0 referencing 863fea23ba1c176bda5e360b0be25cacc405877aa3e46a3e1c60196c3b6cd7b6 at 0: Script was NOT verified successfully"

So my question is where have I wrong done? Which step is wrong and how to do it in a right way?

I found that witness didn't include serializied script: that func for some reason just ingnored writing script into buffer, that means algorithm specified here(https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki, specification paragraph) ignored 5th step. So I removed if statement, and instead of (https://github.com/btcsuite/btcd/blob/master/txscript/script.go#L496) pasted writing has160 of pub key and that worked for me