Saved bitcoin dat file, unfortunately converted to Adobe

Filename extensions and file associations

You can probably ignore the Adobe icon and messages from Adobe.

Microsoft windows decides on the type of a file by using the last part of a files name, the part after the last period (dot), called a filename-extension. For example something.txt is a plain text file that can be edited with Notepad. something.mp3 is a music file that can be played with, for example, Windows-Media player. something.jpg is a photograph and so on.

Microsoft Windows can also associate a particular filename extension with one particular program that understands and uses the type of file that usually has that filename-extension.

Unfortunately a lot of different programs use .dat as a filename extension - it just means some kind of raw data file. The Bitcoin Core wallet (sometimes called Bitcoin-qt) uses that filename extension - for example in a file named wallet.dat.

When you install one of Adobe's products (e.g. Adobe Illustrator), the installation process has associated the .dat filename-extension with the Adobe program and removed any association with other programs.

This is why Windows explorer erroneously shows the Adobe icon next to your bitcoin .dat file. This is why Windows runs the Adobe program (not Bitcoin core) when you click on the file.

This doesn't matter that much, you can ignore it and leave the association as it is.

If you run your wallet program by finding it in the start menu or going to its web-page etc (and not by clicking on the .dat file name) it will likely work OK despite the file-association with an Adobe program.

bitcoin (2016_09_09 22_16_58 UTC) (2017_08_22 13_54_01 UTC).dat

You don't explain what kind of wallet (or web-site service) you used to store your Bitcoins before. The rest of this answer assumes you used the "Bitcoin core" wallet. If you didn't you should stop reading this answer.

The Bitcoin core wallet stores important information in a file named wallet.dat in a place on your computer's hard-disk that is not easy to find using Windows explorer.

If you open Windows explorer and, on the left hand side, click on This PC then Windows (C:), then users, then click on your name, then at the top click into the part at the top where it says This PC > Windows (C:) > Users > Yourname. It will change to C:\Users\Yourname. Move the cursor to the end (right-arrow) and add \AppData (by typing that) and press the Enter key. Click on Roaming then Bitcoin. You should see wallet.dat.

The filename you have given is different and is not one I am familiar with. This is a long-shot but,if we assume it is a backup copy of a wallet.dat saved with a special name but the same contents, you might be able to

close the Bitcoin program if it is running.
rename the existing wallet.dat to wallet.dat.new (so that you can undo these changes)
make a copy of your bitcoin (2016_09_09 22_16_58 UTC) (2017_08_22 13_54_01 UTC).dat with the name wallet.dat
put the copy into the same folder as the wallet.dat.new
start Bitcoin.

If you did not use Bitcoin core, whatever Bitcoin wallet you were using before likely has some "restore wallet" option used in conjunction with data files created using a "backup wallet" function.

  How would I transfer them to a Trezor1?

This is a separate question, you need to get some information out of your Bitcoin wallet (out of a valid wallet.dat file) and that requires a working Bitcoin core wallet program and knowledge of the password for the wallet.


Opening wallet.dat in python, using bsddb3

open the database like this:

from bsddb.db import *

db = DB()
r= db.open("wallet.dat", "main", DB_BTREE, DB_RDONLY)

print "%s" % (db.items())


In Zcash, what statements do zkSNARKs prove?

My understanding is that the verifier is anyone that maintains the blockchain.

All nodes that fully-validate transactions will be acting as zk-SNARK verifiers.

  In particular, is the transaction graph still public?

The transaction graph for shielded transactions is as private as it is feasible to be.

When a note is created, a commitment cm to the note is made public (effectively a hash of the note). When the note is spent, its nullifier nf is derived (effectively another hash) and made public. To the person spending the note, the local transaction graph looks like this:

(... -> tx1 -> cm)[<--- note --->](nf -> tx2 -> ...)

But to all other nodes on the network, all they see is:

(... -> tx1 -> cm)                (nf -> tx2 -> ...)

That is, they see when some note was created, and when some note was spent, but without knowing the private information (and assuming they can't find pre-images for the hash functions), they can't directly link the two events. They can exclude certain combinations of transactions, however:

A note cannot be spent before it was created, so when a nullifier is published, everyone knows that it corresponds to some commitment that was published previously, but not to any commitment that was published later.
Some nullifiers and commitments can be reasonably excluded based on other revealed information, e.g. if an exchange's records get leaked, or if they are in transactions that also involve transparent inputs and outputs. In particular, if you send funds from a t-address to a z-address and then on to another t-address, you get basically no privacy. See my previous answer about this for more information.

  If I decide to send x amount of Zcash to another user, what is the statement that zkSNARKs will hide?

The specific statement (for the Sprout circuit) being proved with the zk-SNARK (and therefore hidden) is given in section 4.9.1 of the Zcash protocol spec. Summarising its parts here:

Nullifier integrity: the published nullifiers correctly correspond to the input notes being spent.
Note commitment integrity: the published commitments correctly correspond to the output notes being created.
Merkle path validity: there is a valid path from the commitments of the input notes to the commitment Merkle tree anchor rt.

This enforces that the notes being spent were previously created.

Balance: The sum of the input note values is equal to the sum of the output note values (plus any funds entering or leaving the transparent pool, e.g. fees).
Spend authority: the provided spending key for each input note correctly corresponds to the public key the note was created for.
And a couple of other correctness requirements.

This is the majority of the consensus rules that get applied to transparent transactions. The only one missing is the double-spend rule, which is still checked outside the circuit (by checking that a nullifier has never been seen before).


Whats the technical/database entity of a crypto-currency / Bitcoin?

A bitcoin, as defined in the whitepaper, is a chain of digital signatures. "To own 1 bitcoin" is by definition equivalent to the following: "in the history of transactions, as defined by the heaviest blockchain branch originating from the genesis block, there exist unspent transaction outputs that sum up to 1 bitcoin such that you have the private key(s) required to spend them".


Bitcoin mining on headless Ubuntu 12.04 server

It seems that CPU based mining is not viable any more.  Even going to other cryptocurrency, which difficulty level should rise quicker as people mining bitcoin using hardware will mine these too.

Ah well, missed the bus :)


How does CryptoNote prevent a 51% attack and double-spending?

The debates still remain whether 51% should be cause for concern. CryptoNote is protected against it in the same way Bitcoin deals with the issue. One difference is in that CryptoNote-based coins, especially the first ones such as Bytecoin (BCN), use egalitarian PoW (CryptoNight) which makes the coin CPU-minable and ASIC resistant. CryptoNight allows for fairer hashrate distribution among individual miners and ensures smooth currency emission. When it comes to mining pools, in theory, having comprised more than 50% of the coin’s network one might be able to affect the next few blocks, launching a double-spending attack by holding on to enough power to confirm the majority of transactions. However, this would take a huge amount of expense and the data about the double-spending taking place would likely appear on the block chain for all to see. Moreover, such an attack could possibly destroy the integrity of the system as a whole, causing the price to crash. This is not something anyone with a vested interest in the affected coin would want.

As for the double-spending problem, CryptoNote deals with it by employing ring signatures and key images. If a rogue user creates more than one ring signature using the same private key, these signatures will be linked together which indicates a double-spending attempt.

In order to provide linkability, CryptoNote introduced a special key image which is created by a user while signing a transaction. It is the value of a cryptographic one-way function of the secret key, or in other words it is actually an image of this key. It is computationally infeasible to find a collision (two different private keys, which have the same image). In case of double-spending attempt the system immediately reject any new ring signature with a duplicate key image. It won’t be able to pinpoint a misbehaving user, but it does prevent any double-spending attempts.

There was never a documented occasion of a double-spending attack in the history of Bytecoin (BCN) or any other CryptoNote -based coin.

Read this for more details https://cryptonote.org/inside/


it is any command line to check the ammout of coins willl be create after build the wallet?

No, there is no way to display the value of this constant. However, I am not sure that this constant is really doing what you want to do, so let me explain its meaning.

The constant MAX_MONEY is the maximum amount that can appear in an individual bitcoin transaction, for instance in tx_verify.cpp in CheckTransaction. Here, actually two checks are done:

The amount in each transaction output is checked against this value
The total across all transaction outputs is checked

So you could theoretically check that your new value is used after a recompile by submitting a transaction violating these constraints and wait for the error message.

However, what you actually want to do (if I read your question correctly) is to increase the total amount of bitcoin that can be mined. This number is not directly hardcoded, but the limit results out of the fact that every 210000 blocks, the subsidy, i.e. the amount of BTC that a miner earns in addition to the transaction fees for mining a block, is halved. This is done in GetBlockSubsidy in validation.cpp, using the parameter nSubsidyHalvingInterval in chainparams.cpp. Thus if you want to change that value (destroying consensus), you would have to make changes at these locations in the source code.


Effect on economy if Bitcoin was widely adopted

GDP would accelerate because of less transactional friction.


Validate 3rd party transactions on Bitcoin-qt debug window

Finally figured it out.

Once you have your node up and running, make sure you synced with txindex enabled. If you already synced without it, you need to reindex with txindex=1 in your bitcoin.conf file. Restart and wait a couple of hours.

Once its re-synced, open the debug console and type:

getrawtransaction "TxID" true

Example:

getrawtransaction "bf585491b06630a94e06798fdfdf1809cc64741cd5bc0d41a50e69ba5b8ddbc5" true

This will return a decoded raw transaction like this:

{
  "txid": "bf585491b06630a94e06798fdfdf1809cc64741cd5bc0d41a50e69ba5b8ddbc5",
  "hash": "bf585491b06630a94e06798fdfdf1809cc64741cd5bc0d41a50e69ba5b8ddbc5",
  "version": 1,
  "size": 225,
  "vsize": 225,
  "weight": 900,
  "locktime": 559545,
  "vin": [
    {
      "txid": "089fd283bc8e012eaa0203ebc40bb1b8888b2f0d0f0bac6664b26b250b15847c",
      "vout": 0,
      "scriptSig": {
        "asm": "304402206163b24284d24e03dc650a86e93d5dbec2dc7d66d4bf71f94ab03b147994160202202a236c07ff469ab2fa8aa2c416a467ad8845c2b5697c18ddabbda31ae7e6289e[ALL] 03e35ef46f9517547c2005c1c941c7651ecf59b44625d1239b78cc01eb2be7a72b",
        "hex": "47304402206163b24284d24e03dc650a86e93d5dbec2dc7d66d4bf71f94ab03b147994160202202a236c07ff469ab2fa8aa2c416a467ad8845c2b5697c18ddabbda31ae7e6289e012103e35ef46f9517547c2005c1c941c7651ecf59b44625d1239b78cc01eb2be7a72b"
      },
      "sequence": 4294967293
    }
  ],
  "vout": [
    {
      "value": 0.11233558,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 48167b6d7c9ae260d2f1c494705f9557c89bc3c7 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91448167b6d7c9ae260d2f1c494705f9557c89bc3c788ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "17aAau6cUvT6WCWkwGWHiTqvsVKHfZowW5"
        ]
      }
    },
    {
      "value": 0.25392682,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 c109fb3bab724bda053409ca9230f3a0f750aa22 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914c109fb3bab724bda053409ca9230f3a0f750aa2288ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1JbhNYR96VG7Do6UZjrnrt3KaXrrrZzJ6i"
        ]
      }
    }
  ],
  "hex": "01000000017c84150b256bb26466ac0b0f0d2f8b88b8b10bc4eb0302aa2e018ebc83d29f08000000006a47304402206163b24284d24e03dc650a86e93d5dbec2dc7d66d4bf71f94ab03b147994160202202a236c07ff469ab2fa8aa2c416a467ad8845c2b5697c18ddabbda31ae7e6289e012103e35ef46f9517547c2005c1c941c7651ecf59b44625d1239b78cc01eb2be7a72bfdffffff021669ab00000000001976a91448167b6d7c9ae260d2f1c494705f9557c89bc3c788ac2a768301000000001976a914c109fb3bab724bda053409ca9230f3a0f750aa2288acb9890800",
  "blockhash": "00000000000000000023c227de45c3eb30b0f9727da4fee7b6e22b66c5d2b9da",
  "confirmations": 5,
  "time": 1548119868,
  "blocktime": 1548119868
}

Here you can verify confirmations of the transaction if you're checking for transactions from a third party to a cold wallet without having to trust online block explorers.


Download Bitcoin, Etherium, Ripple rates 1min candles

A lot of exchanges have a limit on how many candles that can be returned per request.
If you can't be arsed to do several requests.

You can use:
https://cryptowat.ch/docs/api#ohlc

Example usage 1:

Fetch from GDAX - BTC/USD, 1-min OHLC candlestick after the date and time 19.12.17 00:00:00

https://api.cryptowat.ch/markets/gdax/btcusd/ohlc?periods=60&after=1513641600

Example usage 2:

Fetch from Bitfinex - XRP/USD, 1-week OHLC candlestick after the date and time 01.12.17 00:00:00

https://api.cryptowat.ch/markets/bitfinex/xrpusd/ohlc?periods=604800&after=1512000000

You can use https://www.epochconverter.com/ to convert the Unix Time stamp to human readable format.

Also btw, I found some archives here: https://api.bitcoincharts.com/v1/csv/ that might be of interest.


Is the seed everything I need to recreate a wallet?

Yes. If you specified one, the password is also necessary (e.g Trezor).
It's worth knowing that the seed covers everything (on Trezor at least) such as the bitcoin (and other coins) wallet, the 2fa secrets, password store etc.


If the website does not send them back to you, there is no way of getting your Bitcoins back. You may be able to sue them, but I am no legal advice. There is no authority that can reimburse you or transfer them to the scam website back to you.


BFL 7GH Jalapeno suddenly trips circuit breaker, what can I do?

I had one Jalapeno power supply die on me, perhaps you can source a replacement?  12V seems OK, but make sure it's rated for the amps.


Feb2018: This is a very generic question of an older request, I answer it anyhow, maybe someone will be searching for this info, just like I was doing :-)

The main point is, that the transaction is not part of the block header.
The block starts with a blocksize number of 4 bytes, a block header of 80 bytes, and a transaction counter (var_int, 1-9 Bytes). Then follows all the transactions in the block. The block header starts with a 4 bytes version field, followed by the previous block hash (32 bytes) and the merkle tree (32bytes). This is followed by three fields of 4 bytes each: difficulty, timestamp, and nonce.

In your example, the block should be composed this way:

Block size: 00000264 (612 Bytes)

Version: 01000030

prev_block: cd0594ebccfe15b205125165cc3b66986ed5b2a311cd88050000000000000000

Merkle root: 37022f7a3b9a2b199d53fbf1552be32c141892319966c3ef999d348d74cfb582

Timestamp: 7f476357

nbits: a09b0518

Nonce: ae5ae1c1

tx counter: 2

transaction: 010000000106af2297b4c9a602be8d866ce644f5a03a4485e973309a7d8a0a64fbd985d1c4010000006b483045022100c37ea6fde87034c0dcc5a62f5fdc8c5292b5b2340c327a4c5d5ff6c1f84a748102203a2ed49ecd0a30f10a1ef77704fcd2c853eecf29c3afd9eea9d44e4fd48d39a50121034ef202077f758c66ad3bf6901c844fd88df6e9889be09b963af1a89fda49f4d3feffffff0271c24413000000001976a914c619073e11f2937f344482ed78a791ec93ca8da988acc0ac0d0d000000001976a914efceeab4cc7010eb07421f7351bf2c22570a5ef488ac9c5f0600

Without the first field, this is a length of 612 bytes, which must be converted into a 4 bytes, which is placed at the beginning of the block. So the full block would be:

<block size>

01000030

cd0594ebccfe15b205125165cc3b66986ed5b2a311cd88050000000000000000

<merkle tree>

7f476357

a09b0518

ae5ae1c1

2

<coinbase ... >

010000000106af2297b4c9a602be8d866ce644f5a03a4485e973309a7d8a0a64fbd985d1c4010000006b483045022100c37ea6fde87034c0dcc5a62f5fdc8c5292b5b2340c327a4c5d5ff6c1f84a748102203a2ed49ecd0a30f10a1ef77704fcd2c853eecf29c3afd9eea9d44e4fd48d39a50121034ef202077f758c66ad3bf6901c844fd88df6e9889be09b963af1a89fda49f4d3feffffff0271c24413000000001976a914c619073e11f2937f344482ed78a791ec93ca8da988acc0ac0d0d000000001976a914efceeab4cc7010eb07421f7351bf2c22570a5ef488ac9c5f0600

Then the merkle tree needs to be re-calculated, and double sha256'd. The length need to be calculated, and put at the very beginning, and the "coinbase tx" is missing (funds calculations!).

The details of the structure can be found here in these two reference pages:
https://bitcoin.org/en/developer-guide#block-chain-overview
https://bitcoin.org/en/developer-reference#block-chain


Is a proof of work consensus mechanism that discourages mining in pools possible?

biggest mining pools which significantly decreases decentralization

Not at all. Pools contribute to decentralization. Without pools, small miners would never be able to mine feasibly, because they would never find a block. No matter how much time they spent mining, no block = no reward. Pools allow them a fair share of block rewards proportional to their work.

Would it be theoretically possible to create a proof of work algorithm that distributes the block reward to miners relative to how many shares they have submitted

It's called P2Pool


Problem caused by unconfirmed transaction chains

A few simple ideas get around the unconfirmed-tx-chain-limit you're running into:

Start with more UTXOs. Each UTXO can be used to create <25 unconfirmed child transactions. So if you need to make n payments, you'll need at least n/25 UTXOs to do so using this method.

However, you can definitely do this in a more cost-effective manner. As Murch mentioned, batch payments describe the method of creating a single transaction with many outputs. So instead of paying one customer per transaction, you can pay many customers per transaction.

Another option is to use the lightning network to send your payments. Lightning transactions are extremely cheap, and fast. If you are regularly sending small payments, I'd encourage you to consider this option.


Are there any instruments that I can use to trade bitcoin volatility?

A VIX index can easily be reconstructed.

Trading that index should be somewhat achievable with a multi-signature transaction, depending upon the limitations of the implementation.

If it is completely private without any regard for transparency at full counterparty trust, a binary option can easily be constructed.  If the BTCVIX is >= X at expiration, pay 100% to party A else pay to party B.  The possible price is (0,100)%, rationally speaking where one party "buys" at P% and the other party "sells" at 100-P%.  In reality, both parties deposit the funds into the transaction, and the winner takes all.

The problems involved with multisigs have been extensively discussed here and elsewhere, but layers can be added to the transaction to ensure smooth functioning such as posting the text of the terms of the transaction in the transaction, both parties posting margin which is returned upon exercision, a 3rd party that cosigns with one party to free the funds, etc.

The complexity thus costs skyrockets with vanilla options because of having to recreate a margin mechanism.


Both Bitmain and Braiins have now released S9 firmware that enables overt AsicBoost.


You can treat the redeemScript as the public key. The redeemScript, like the public key, is revealed entirely when you spend from your multisig address. So it will become public information, much like your public key will also become public information when it is used in an input.

The redeemScript cannot really be used to do anything particularly bad unless the redeemScript has certain conditions which allows someone to do so. For multisig, there are no such conditions. Having the redeemScript only allows you to see what the specific conditions for spending an output are, and that information by itself is not useful.


https://chainquery.com/bitcoin-api/sendtoaddress

You can use last (5th) parameter:

subtractfeefromamount  (boolean, optional, default=false) The fee will be deducted from the amount being sent. The recipient will receive less bitcoins than you enter in the amount field.


How can the government tax you using bitcoin

Governments can set up laws and regulations and then set up "departments" to monitor and enforce.

Whether it is successful or not is another question. No doubt they will have to skill up and understand how digital currencies really work, maybe monitor a few people, monitor the flow of their btc's and audit them, create some "high profile" cases to be made examples of etc.

One can draw an analogy with cash.


In blockchain, particular bitcoin why is difficulty not part of the Block but merkleroothash is

Actually it kinda is, the nBits field encodes the target threshold in the block header, which is directly related to, and more directly useful than, the difficulty itself.


Why are Bitcoin prices so different between different markets?

Mtgox has dollar withdrawal problems. So a dollar within Mt. Gox is worth (valued) less. So you pay more dollars and take your bitcoins out, hence the higher exchange rate.


Constantly getting connection interrupted

I'm doing:

minerd -a scrypt --threads=1 -o stratum+tcp://us.litecoinpool.org:3333 -O ab1jx.4:4

From a script and it works fine.  ab1jx is my username on litecoinpool, worker is 4, password is 4.  Only 1 thread to make it sort of a background process, leave that out to run at full throttle.

I don't get accepted lines often either with cpuminer, I assume because it's so slow.  I do with my ASIC miners.  I see the restarts a lot more often.  Sometimes I get accepted (and a yay) but this is a few orders of magnitude slower than everybody else, so it comes later than everybody else and may get tossed.  Not sure if you still get credited for it.  Check your stats on the pool after an hour or so, that's what counts.

No CPU miner is going to be profitable because it burns more electricity than the coins are worth.  Unless you have free electricity like solar or geothermal.  I do it as a test load on the computer and network.  If it's winter and you heat with electricity anyway it might work out.


Can the Antminer S3 mine Bitcoin using Blake2s algorithm?

No, Bitcoin uses SHA-256 only, BLAKE2s is a different and incompatible algorithm.


What products, deals or other incentives are available exclusively to those paying with Bitcoin?

The only payment method for Bundles through Nestor Games is in bitcoins.
Items in BitPremier's showroom are available only when paying with bitcoins.  Since some of these items are not otherwise available this might indicate Bitcoin exclusivity.
Author James Altucher made Bitcoin as the only payment method for his new e-book (for a limited period of time)


How to detect that full node is in sync (using jsonrpc)?

Using the getblockchaininfo RPC command :

if initialblockdownload is true, your node is currently syncing with the network for the first time.
else :

if the headers field number is superior to the blocks field number, your node is catching up with the current state (likely after having been restarted)
else if the headers field number is equal to the blocks field number, your node is synced !

Here is the current output of the command for me :

$ bitcoin-cli getblockchaininfo
{
  "chain": "main",
  "blocks": 634379,
  "headers": 634379,
  "bestblockhash": "000000000000000000136f1b78deeebc33a9b7b33d25c2e37f5446cb33b586fd",
  "difficulty": 13732352106018.34,
  "mediantime": 1591963775,
  "verificationprogress": 0.9999999385944023,
  "initialblockdownload": false,
  "chainwork": "0000000000000000000000000000000000000000104a35fae53a5b470d8e9524",
--snip--
}


How to get passphrase from a private key?

Assuming you have a symmetrically encrypted copy of your private key, where the encryption key was derived from a passphrase, you would be trying to perform a known-plaintext attack. However, it should not be possible in polynomial time for a proper AES implementation, so I'm afraid you're out of luck.


What and where is the easiest way to convert bitcoin back to cash without showing ID?

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

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

In the U.S., Coinbase might be the simplest -- you can sell up to 100 BTC per day, with a fee of 1% and then from there the USD proceeds are redeemed to your bank.  But that is a cash-out method using the banking system, so it is not anonymous or even close.

Other popular methods include FastCash4Bitcoins.com (now BitSimple.com), which can cash out to your PayPal, Dwolla, ACH (Direct Deposit), Bank Wire, Check, bank wire, or silver bullion.

For privacy, you might consider LocalBitcoins, in which a local cash transaction occurs, face-to-face.

http://www.LocalBitcoins.com

There are dozens of cash-out methods:

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


All block hashes start with a certain number of zeroes by design. The nature of a hash is that knowing something about the output does not help you figure out what the input is supposed to be (at least in theory). So in short, no.


How to get the block hash in the chainstate leveldb?

This is a bit late, but I've been struggling with this myself so hopefully I can help out anyone who comes across this thread with a similar question:

Looks like the chainstate obfuscation key begins with an 08, which probably refers to the length of the key. If you remove the 08, you get an obfuscation key of (for the above example) 99b9c2314a85c9b6, which you'll note is the reverse endian-ness of the beginning of result_hex (as it should, since the beginning of block hashes are zeros).

So to get these pieces of data to match endian-ness, you can reverse the key above and you'll get b6c9854a31c2b999. Per this answer, to de-obfuscate data you need to append the obfuscation key to itself until it matches the length of the data, leaving us with:

result_hex = b6c9854a31c2b999b6da5ee266a8047f3c8c5fc82479ab03af9272a3a57372a2
xor_key    = b6c9854a31c2b999b6c9854a31c2b999b6c9854a31c2b999b6c9854a31c2b999

If you enter those two values on https://xor.pw/# (as the OP did) you get 13dba8576abde68a45da8215bb129a195bf7e994b1cb3b, which you'll notice is quite a bit shorter than the inputs. This is because that site omits leading zeros. Add the missing zeros in and you get 00000000000000000013dba8576abde68a45da8215bb129a195bf7e994b1cb3b, which is a block hash from around the time this question was asked.


How can I avoid re-using a Bitcoin address more than once?

Address should not be used to receive bitcoins more than once, meaning each time you receive bitcoins you should use a fresh address. Of course, once you receive bitcoins at an address, you will want to spend them in the future, and that is fine. Ideally, an address is received to once, and then later spent from once.

The 'single spend recommendation' is sort of automatically enforced: when spending a UTXO, it is not possible to spend only part of the bitcoin, the entire UTXO must be consumed. So you just need to make sure you do not re-use an address to receive bitcoin / as a change address.

Perhaps the biggest reason this is recommended is that single use of an address preserves your privacy, as well as the privacy of those you interact with.


Can private keys remain offline for their entire life?

Yes, all three assumptions are correct. You can with some effort keep your private keys offline for their entire life.

A description of how to sign transactions offline is found here: How to sign a transaction using only an offline computer?

Adding a bit of detail on Assumption 3 along the lines of Tim S.'s comment: A computer that is offline would obviously not get updates from the network, so it would also not know which transaction outputs are available for spending. This could be mitigated by importing the blockchain data to the offline computer (for example with the bootstrap.dat).

However, it would be much easier to create a two wallet setup, where one online wallet knows only the addresses, and the offline wallet has the private keys. You then create the transaction on the online wallet, which has the transactional information and sign it on the offline wallet. That's what is described in the above linked question as well.

Update in 2017: The creation of a transaction on the online device and signing on the offline device is essentially what hardware wallets such as Trezor do.


Why is it more profitable for a node with more than 51% computation power to abide by the rules in the bitcoin network

An attacker with 51% hash power could perform a double-spend (or several). He could send a large payment to someone and then use his hash power to create a longer chain that spends the same coins but sends them to himself instead, making the first transaction invalid.

It would be against his interest because playing by the rules would net him roughly 1 every 2 block rewards (that is roughly $100,000 every 20 minutes) but if he chose to perform this attack the price of bitcoin would plummet making his reward much less.


Electrum Linux run without sudoers installation

You have two options:

Install pyqt5 as root. Then, as an unprivileged user, simply download, verify the gpg sig and untar the electrum tarball download and execute run_electrum in the directory that gets created. Most dependencies are included with the tarball so this is all you will have to do.
Another option is to use the appimage version. Just make it executable and run it. It contains all dependencies. This is recommended if you don't have python 3.6 available for your distro.


Why does script need to be purged from transactions for mimblewimble to work?

The incompatibility comes down to 2 main factors:

Pruning: an important addition of the mimblewimble proposal is the ability to merge transactions across blocks. If transactions include scripts, merging becomes impossible as the script behavior is unknown. While for simple spends, it's fairly straightforward to eliminate matching amounts.
No address: in mimblewimble the equivalent of bitcoin addresses (hash of a public key) don't really exist. There may be a way to still be able to send money for a contract but it'd be difficult for a contract to send money to anyone.


Is it legal to use rented dedicated servers to mine?

It's definitely not against the law. It might be breaking the terms of service (ToS) but there's really no reason why any dedicated server hosting provider wouldn't allow you to max out the CPU. I wouldn't do business with them if they limited that. However, you need to read your hosting provider's ToS. They might forbid certain applications like IRC servers, BitTorrent, Tor, etc. If they don't list Bitcoin then you are good to go.


Are there any active Bitcoin leveraged trading platforms available?

https://icbit.se/ offers trading of futures instruments, in particular BTCUSD-12.12 (BUZ2) which enables leveraged BTC trading. However, user orders are matched only against other users (it does not utilize liquidity from larger exchanges such as Mt. Gox), and the way it works is not very intuitive.


Transactions from Bitcoin-qt wallet not entering the mempool

There should be a file called wallet.dat. It contains your private keys which allow you to send your BTC.

Warning: Before you do anything with the file create at least one backup of it. Do not send, upload or otherwise share the file with anyone. Who ever has this file can spend you UTXO (steal your bitcoin).

Since the transactions both did not propaganda you can safely send them again. There are two ways you could approach this:

Using a new version of bitcoin core

download and install bitcoin core v0.15.0.1
start Bitcoin-qt v0.15.0.1
let the blockchain sync (this might take a while)
stop Bitcoin-Qt, copy your old wallet.dat and replace the new wallet.dat in the bitcoin v0.15 directory, start Bitcoin-Qt
you should be able to send the transaction

Using Electrum to sweep the private key(s)

download and install Electrum
create a new standard wallet and from a new seed
write. down. the. 12. words!
open your Bitcoin-qt v0.8.5
navigate to help > debug window > console
type dumpprivkey [your Address] (repeat multiple times if you have more than one Address)
copy the private key
in Electrum go to Wallet > Private keys > Sweep
paste you private key and click on sweep
Electrum sends the BTC to your Electrum wallet

Both methods should work for you. However since 2. is faster (no blockchain download needed) and you already considered switching to Electrum, this method might be preferred.

Edit:
Don't delete the wallet.dat after you send your BTC. The private grants you access to the same amount of BCH (Bitcoin Cash). One BCH is at the moment worth 7-9% BTC or about $600.


I lost my wallet, can someone just help me with my investigation?

too many clues means no clue at all. there isn't no clue. you already said u changed laptop manytimes . just forget about. you can't dnothing without the backup.
but if you using some online wallet to receive that btc. you can search your email to see if there are record fromexchange or online wallets. this is the only chance. good luck.


Definition of confirmation time in blockchain.info

I believe the data presented on blockchain.info's site is collected by the following method:

a blockchain.info node hears about a new transaction. It is added to the node's mempool, and an entry that includes a timestamp is also recorded into a local database
when the node hears about a new block, it will check to see which transactions are included. It will then compare the time the transaction was first seen, with the time the block was first seen, and the difference between the two would be a 'time until confirmation'.

This chart reports the median time for transaction confirmation, but note that it excludes any transactions with zero fee.

It is potentially worth noting that some transactions are published with a low time preference, meaning the person initiating the transaction may intentionally include a low fee that will take a while to confirm, and this would drive the 'average confirmation time' up, even though the network is functioning well for it's users.


In a private blockchain network, can we delete the first N blocks and reassign the N+1th block as the genesis block?

With blockchains, you can basically do anything with a hard fork.  In the case of private blockchains, you will have a much easier time getting consensus for a hard fork, perhaps as easy as the authority running the blockchain dictating that everyone must accept an upgrade.

The genesis block is hard-coded into the software.  To re-assign a later block to be the new genesis block, you would need to hard-code that block into a newer version of the software.  This will only be recognized as valid by nodes running the newer version of the software.  Assuming gaining consensus isn't an issue, this is possible.

Another thing to be concerned with is block height, and all calculations based on it.  It's easy to modify the client to start counting at N+1, but this also may need to be taken into consideration when calculations are made.  This will effect things such as difficulty targets and halvings.  If you modify all relevant code to take this into account, you should be able to keep things working correctly.


Is there any way to listen to all transactions using bitcoind api?

Yes by default newer versions of bitcoin core should have zeromq enabled by default. Check here -> https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md

If you're using java you can use the code snippet there (using https://github.com/zeromq/jeromq ) -> How do i parse the zeroMQ messages in java?


Is Bitcoin the first e-cash scheme which solved the double-spend problem?

Yes. Bitcoin is the first trustless e-cash protocol, which solves the double-spend problem. If anyone else needs an academic source to back up this claim, there is at least this one:

Brito, Jerry ja Castillo, Andrea: Bitcoin: A primer for policymakers.
Mercatus Center at George Mason University, 2013

https://www.mercatus.org/publication/bitcoin-primer-policymakers


I suggest you look at opentimestamps. From the website:

A timestamp proves that some data existed prior to some point in time. OpenTimestamps defines a set of operations for creating provable timestamps and later independently verifying them. At the time of writing timestamping on the Bitcoin blockchain is supported, the format is flexible enough to support a variety of methods.
Anyone could realize a timestamp with the permissionless blockchain by paying the transaction fees, for your convenience we offer calendar servers that perform this operation for you. These servers are free to use and they don't require any registration or api key.


How to findout the sender of a transaction

I just answered a similar question. The relevant parts are:

It is now possible to determine the list of addresses that sent a transaction using the raw transaction JSON-RPC API calls that were released with bitcoind and bitcoin-qt version 0.7. The pseudo-code to accomplish this is:

txid = <relevant transaction id>
addresses = []
raw_tx = decoderawtransaction(getrawtransaction(txid))
for(input in raw_tx['vin']) {
  input_raw_tx = decoderawtransaction(getrawtransaction(input['txid']))
  addresses.push(input_raw_tx['vout'][input['vout']]['scriptPubKey']['addresses'][0])
}


You can definitely mine with that card. My recommendation is you look up cudaminer. With the same card as you I get about 140 khash/s mining litecoins (using scrypt). I don't remember which instructions I used to set it up.


How can I buy Bitcoins in the UK now that Blockchain.info has suspended its deposits?

For small BTC purchases in the UK, https://localbitcoins.com/ (LocalBitcoins) is the only viable option right now that I know of.

There are other methods, mostly involving bank transfer arrangements, but be very careful to figure out how much you end up paying in total fees for it. It doesn't make much of a difference with large BTC orders, but for small amounts it's a fair % of costs.


Stealth addresses how does recipient use the bitcoins?

How does the recipient use the bitcoin he receives?

Stealth addresses require you to scan all the transactions of the blockchain It is a fairly inefficient process but the stealth address implementations that I've seen have two improvements:

prefix: each stealth address has a required prefix and you must bruteforce your txid to match the prefix encoded in the stealth address. That way the receiver must only test a subset of transactions.
dual-key system: a scanning key is introduced to allow the receiver to scan whilst their wallet is locked.

  In the recipient wallet, does he have a list of those generated address (made by the sender)?

Yes. A new address is derived from the stealth address and the ephemeral key (provided in the additional output with OP_RETURN). This address is then imported into the wallet.

  How would he then use those bitcoin without revealing transaction linkability?

Transaction linkability generally means that you can not link a transaction to a published address (obfuscating the destination). The concept you're aiming at, is transaction traceability (when creating a transaction, how do I obfuscate the source output).


Who decided that segwit2x isn't going to happen?

Key proponents of the New York Agreement have rescinded their support after large parts of the community opposed their initiative for months. Theoretically, a miner could still activate the fork unilaterally, but the expected value of the Segwit2x network dropped significantly with the exit of said key proponents.


How does the wallet work, online and offline?

Although wallets indeed contain your "coins", the ability to spend them is tracked by the network. Every fully validating node keeps a list of available coins on the network. They do not know who has which, only which (Bitcoin, not IP) address (or addresses) they are associated to. In case you try to spend the same coin twice - for example because you copied your wallet to another computer, and then tried to send a transaction from each - you may temporarily confuse the network. Some nodes may first see the one transactions and some others will see the others first. However, the strength of the system is that this disagreement cannot exist for long and only one of them will be accepted after some time.

The essential thing in your wallet is not the transactions, but the keys. Each address has an associated public and private key. These private keys never leave your wallet file and are necessary to spend the coins assigned to your addresses.

Because the transactions are tracked by the network, you indeed don't need to be online to receive transactions. The next time you connect, your client will ask the network for up-to-date information. During the synchronization that follows, your incoming transaction will be fetched, and the client will detect this as an incoming payment.


This seems like a silly question. If you're going to create new software, it will work as you program it.

It will differ in exactly the ways you make it.


Is the BCH version of Schnorr signatures compatible with taproot?

No, it will not be possible to use Taproot on BCH after the hard fork. Taproot requires additional script constructions and interpretations of stack elements which the Schnorr signature algorithm by itself cannot provide. The BCH hard fork merely changes the signature algorithm for specific kinds of OP_CHECKSIG and OP_CHECKDATASIG outputs. No other changes related to scripts or the interpretation of stack elements is done.


There are certain sorts of escrow that are very difficult to implement without a trusted party. For example, an escrow system that only sends along the payment when the seller has provided proof of shipping would be impossible without a trusted third party.

However, if we change the escrow system a little bit, then we can implement it without a third party. For example, suppose we say that the buyer and the seller merely need to agree about where the bitcoins are sent. That is something that a decentralized network can check for.


Verifying a digital signature that a transaction is going to an output with value X inside a script

but in bitcoin usually the message is a hash of the previous transaction and the 'to' pubkey-hash and/or transaction? Unless i am missing something, the SIGHASH_SINGLE parameter specifically signs only the input and output of the new transaction. So, if you could create this input and output, and sign it inside an OP_CODE with a privatekey, you could verify that an output was going to a particular person inside a bitcoin script sig. Of course, the private key holding that UTXO would be unusable except for returning BTC to the user, or perhaps another pubkey could be used to spend the UTXO.

This is incorrect. Transaction signing works by:

for every input i in inputs:
    Start with a transaction skeleton that matches the transaction for non-input/output fields like tx version
    Add the input i
    Add other inputs and outputs based on the sighash flag
    Hash this update tx skeleton
    Sign the hash

The SIGHASH flags simplify specify which inputs and outputs are covered by the signature. For SIGHASH_ALL, the entire input and output set is signed. For SIGHASH_SINGLE, only the output corresponding to the index of the input is signed (for the first input in a tx, the first output will be signed). You also have additional options such as ANYONE_CAN_PAY which allow addition inputs to be added later, by only signing your input (for use with coinjoins).

By using SIGHASH_ALL | SIGHASH_ANYONECANPAY or SIGHASH_SINGLE | SIGHASH_ANYONECANPAY flags, if you already control an output, you can specify something such as:

If this output is used as an input, at least X BTC must be sent to {these|this} new output(s).

However, this restriction only applies if the final transaction uses this specific signed input - nothing prevents you from creating another signed tx that spends that same output to a different destination and broadcasting it first.

Your example fails since within the signature, you have no information about the output. The data that is signed is that of an augmented tx skeleton as a whole - you cannot use Bitcoin Script to inspect a subset of that data and validate the signature.

To take the example another way, let us say we construct a bitcoin script equivalent to:

Accept a signature and a public key
Verify that the signature is over the data (input,hash160(public_key)
Verify the signature is performed by the same key that unlocks the input being spent

This would seem to imply that we can sign the destination public key using the same private key that owns the input, and then have a script that validates both the tx signature, and the signature over the public key we claim to send to.

However, in this case, nothing prevents you from feeding a valid signature and destination public key to the script, but specifying a completely different output in the actual tx - This is because there is simply no way for the Bitcoin Script program to read and check where the tx output(s) are actually going.


How to cancel the callback url registered on blockchain.info

Does that mean blockchain.info will retry to call that bad url 1000 times before it finally gives up ?

It would appear so, and I can't see a way to cancel it, besides creating a page at that url with the text '*ok*'

To see what requests it's made already, try looking at this page and putting the bad url in the Check Callback Response Log form.


I think there are few other advantages with using blockchain such as improved peer-to-peer sharing with audit trail and no single point for cyberattack.

In saying that Iron mountain would no longer be the central point of access or holding of document and would provide the interface to accessing their documents.

Base on my limited knowledge, I won't claim to be an expert and looking for anyone with more knowledge to explain.


bitcoind sync is utilising very little CPU and bandwidth and is very slow

Make sure you are connected to enough peers (maybe >4)
Make sure you use either the default -par config value or you set it according to your available CPU cores (usually num of cores +1)
Make sure, you have fast disk access (ideally SSD). If disk access is slow (don't use NFS, NAS, etc.), it could tear down the verification process (leaving your CPU partially unused)
Try to change the default database cache size. A -dbcache of 4GB can really significant speedup the sync, though don't over-allocate if your system has not plenty of RAM to waste.


How can I calculate the bitcoin per day from mining in a pool?

To go from GH/sec to BTC/day, use this:

BTC/day = GH/sec * 1,000 * 25 * 24 * 3,600 / 2^32 / difficulty(in millions)
Because: the block reward is currently 25, there are 24 hours in a day, 3600 seconds in an hour, and the base share difficulty is 2^32.

So 100GH/s, at the current difficulty of 707 million will yield:
100 * 1,000 * 25 * 24 * 3600 / 2^32 / 707.41 = .0711 BTC/day

Note that this assumes no pool fees and no variance at all. Of course, the difficulty is increasing so the yield will drop.


Bitcoin transaction unconfirmed, while way past expected processing time

That's correct, a transaction cannot be confirmed until all its inputs (and all of their inputs, and so on) have confirmed.  (It is allowed for the transaction to go in the same block as its inputs, so that they confirm simultaneously.)

You may be able to remedy the situation by creating a third transaction that spends the second (7da9), with a large enough fee such that the overall average fee of all three transactions is at or above market rate.  Miners may be smart enough to realize that they can earn a good overall fee by confirming all three.  This is the idea of the child-pays-for-parent scheme, though it's usually used to have a transaction pay for its immediate inputs; I don't know whether the software used by most miners would detect longer chains like this one.

You can also wait for a while until other nodes have forgotten the low-fee a762 transaction, and then try to replace it with a higher-fee transaction (a double spend).  The details of doing this depend on your wallet; often it involves "zapping transactions" or "resetting blockchain" so that the wallet forgets what transactions it created, and scans the blockchain to find only those which are confirmed.  If other nodes have also forgotten the unconfirmed transaction, then it's as if they never happened and you can start again.


What options does one have to manage Bitcoins?

I am not a trader, so I don't have much advice to offer in terms of which services are best.  However, I do have some thoughts and experience with storing bitcoins.

From a technology standpoint, bitcoins are secured by the private keys held by the owner of the coins.  Private keys are cryptographically amazing, but terrible in terms of user experience.  If the management of private keys was easy to create an interface for, the internet would be a much more secure place.  Unfortunately, humans have proven really bad and managing private keys.  This is the problem every bitcoin wallet attempts to solve.

To understand your options for managing private keys (wallets), you have to understand how the security model works.  As the name suggests, private keys are meant to remain private.  Anyone who has knowledge of them has access to your bitcoins.  Meanwhile, you also never want to lose your own access to the private keys.  If you do, you lose your bitcoins.  This creates a problem with solutions that have an indirect relationship between the two issues.  If your private keys are well protected, you increase the chance that you will lose your access as well.  If your private keys are easily accessible, you are unlikely to lose them, but far more likely to be robbed.  There are some elegant technical solutions for this paradox, but no user-friendly solutions that come to mind.

Let's explore some of the options.

Web Wallets

This is the case where some online service manages your private keys for you, but gives you access to control how the bitcoins they store are used.  Personally, I would define the owner of the bitcoins to be whomever has access to the private keys.  With this viewpoint, you are not the owner of the bitcoins held in an online wallet.  You are the owner of an account with an organization who owns the bitcoins on your behalf.  The question of whether it is "safe" to store 50 to 100 bitcoins in an online wallet can only be answered by answering one or both of these questions:

Do I trust this 3rd party with 50 to 100 bitcoins (both with honesty and security)?
Can I afford to lose 50 to 100 bitcoins?

If your answer to either question is "no", then you may want to consider reducing the amount you store in the online wallet to an acceptable amount.

Hardware Wallets

These are single-purpose computers that manage your private keys for you.  Because they are usually offline devices, they go a long way towards being hacker-proof, but remember that there really is no such thing.  These sound great, and many people have started using them, but I'm personally skeptical.  These products were created from a growing demand, and rushed to market to beat out competitors.  Even if the security is perfect (which it never is), you are now trusting your wealth to the reliability of these machines.  I would recommend letting the market settle down for a couple of years, and let a few more generations come out, before trusting too much of your wealth to these devices.  You don't want the scenario where the thing won't power on, but you have your life savings stored on it.

Mobile App Wallets

These wallets are by far the most convenient for day to day use, perhaps even more so than online wallets.  You can scan QR codes to pay people, generate QR codes to be paid, and have your funds at your fingertips as you go about your day.  The drawbacks are also pretty steep.  Your funds are now only as secure as your phone.  If you get malware, you could lose your money.  If your phone gets lost or stolen, you lose your money.  If your device breaks (ex. dropped in the toilet), you may lose your money.  I view a mobile app wallet as I view a physical wallet.  You don't go about your day to day business hauling around your retirement savings.  You only leave the house with as much cash as you plan on spending that day, and try to keep it to what you can afford to lose.

Desktop Wallets

This is the case of running Bitcoin Core, or Electrum, or some other desktop-based wallet.  In principal, these are about the same as a mobile app wallet, with the advantage that you may be participating as a full-node in the Bitcoin network.  This allows you to trust transactions and blocks more than with an SPV Wallet, but doesn't really offer anything better in terms of the management of private keys.  Desktop wallets can be run on your day to day desktop, or perhaps a desktop that is usually kept offline and used only for bitcoin transactions.  Like with mobile app wallets, the security of this wallet is only as secure as the computer it runs on.  Also remember that software wallets (both mobile and desktop) have the ability to backup the wallet files, which can add to their reliability, but increase the number of ways your bitcoins can be compromised.  Again, there's always a trade off.

Paper Wallets

A paper wallet is a physical, paper document that contains a QR code of the the private key to a Bitcoin address.  You can store money in the wallet by sending bitcoins to the address, and then redeem them later by importing the private key into some other type of wallet.  This document can then be stored in a safe, a safety deposit box, buried in the woods, or anywhere else that you feel is safe from burglary and fire.  Think of this as a stack of fiat currency being held in a safe.  This is one of the safest ways to store your bitcoins, but is terribly inconvenient.  There is also the question about how the address was generated in the first place.  If you don't trust the software/organization that generated the paper wallet, then you can't trust the wallet.

Brain Wallets

A brain wallet is a way of generating a private key from a passphrase that is not stored anywhere, but rather remembered by the owner of the wallet.  It is much like a paper wallet, except that the private key is never written down.  Again, you must trust the software used to generate this address from your passphrase.  You will also most likely want to generate a passphrase, rather than use a passage from literature or a song lyric.  With computer speed and storage increasing along an exponential curve, and all the worlds books being digitized, it is not unthinkable that someone will attempt to steal bitcoins by brute forcing every known phrase from every book and song.  With cryptography, randomness is extremely important.

To conclude, diversification is always a good strategy for wealth management, and bitcoins are no different.  If you spread out your bitcoins between different types of wallets on different storage mediums, then you are less likely to lose everything, but more likely to lose something.  If you limit exposure to the wallets you use for long-term holding, you increase your security.  Just don't forget your password, passphrase, safe combination, place you buried it, or whatever.

I hope that helps.


At what prices I will be buying/selling bitcoins?

Scenario 1

Using a simpler example, if you visit bitcoin.com.au to sell Bitcoin you will get the sell price for k Bitcoins. In this example, it is a spot sell price.

Scenario 2

Using a simpler example, if you visit bitcoin.com.au to buy Bitcoin you will pay the buy price for k Bitcoins. In this example, it is a spot buy price.

Elsewhere

On market exchanges, the buy and sell price are market indicators. These are the general level of the buy and sell orders. You can creae a buy or sell order for, usually, any price you like but the indicators show current trade values.

If the exchange lists a spot price, this is usually their spot buy price, for if you wish to sell to the exchange directly without creating a market order and waiting.


How do internet wallets connected to full blockchain nodes

How do internet wallets such as Coinbase connect to the a blockchain node?

Using an API provided for that purpose. For example Bitcoin core's API

Doesn’t the node itself create a default wallet object on startup?

Not all nodes are based on Bitcoin core. Apart from the development costs there is nothing that prevents exchanges writing their own software to act as a Bitcoin node.
There are ways of running a node that don't create an unwanted wallet. (e.g. set disablewallet=1 in the bitcoin.conf file.)

How is this replaced by internet wallets which hold multiple address until account credentials.

In proprietary ways that are likely different from exchange to exchange and which are likely company confidential.


Access to exchanges' (especially Mt. Gox's) transaction history?

You can use the API to retrieve such data.


How do I go about installing a Bitcoin daemon in CentOS Linux?

I host two bitcoind RPMs (i686, x86_64) on my website which will most likely work fine for you, as they're built for CentOS 6.4. Run this command to install bitcoind :

rpm -ivh http://tvdw.eu/bitcoin-0.8.1-1.el6.`uname -m`.rpm

If you want to download them manually, the files are:

i686:   http://tvdw.eu/bitcoin-0.8.1-1.el6.i686.rpm
MD5:    5be52618594a3eaded19052197c2f6ed

x86_64: http://tvdw.eu/bitcoin-0.8.1-1.el6.x86_64.rpm
MD5:    49ba4acbf9744e96bf12342888bc347a

The packages are unsigned, so install these at your own risk (aka: some level of trust is required here).

[Edit] This is the bitcoin.spec file I use to build these packages :

Name:           bitcoin
Version:        0.8.1
Release:        1%{?dist}
Summary:        bitcoin

License:        GPL
URL:            http://bitcoin.org
Source0:        http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-%{version}/bitcoin-%{version}-linux.tar.gz

%description
bitcoin

%package qt
Summary:        bitcoin-qt
%description qt
bitcoin-qt

%prep
%setup -q -n bitcoin-%{version}-linux

%build

%install
mkdir -p %{buildroot}%{_bindir}
%ifarch x86_64
cp -R bin/64/* %{buildroot}%{_bindir}
%endif
%ifarch i686
cp -R bin/32/* %{buildroot}%{_bindir}
%endif

%clean
rm -rf %{buildroot}

%files
%doc README COPYING
/usr/bin/bitcoind

%files qt
/usr/bin/bitcoin-qt

%changelog

There's no actual compilation involved, it just puts the files in the right locations and wraps it in a nice little RPM.


can I use bit coin to pay my overseas customers

Absolutely! Bitcoin can be transferred peer to peer, to anyone over the net.

Now, you should note that:

Bitcoin is very volatile.
Bitcoin is very congested and slow these days, using litecoin or ethereum may be a better pick at the moment.

Also too, you will need to make sure your oversea customers will accept bitcoin payments. Some countries do not have a online exchange available to cash in bitcoins, so it is very important to tell your customers if bitcoin payments are ok.

tl;dr - yes, you can send bitcoin payments to anyone, in any country as long as they accept it. Then, your customer can optionally choose to cash it at a online exchange available to him for fiat cash.


Let's take a look at this block, because it only has one transaction (the coinbase): 000000000000000000eb2d0ed97a7b2cff7f1408417dca83908004beb6fd9b95

Let's grab the raw hex data:

  0000002053f7ebc735f54ac8d4ebcc1eeb3d3bdea89603bdd27431000000000000000000ff964ec70ea5a5356a04fdb044ca6c59ffda2dd6be02c63d9ea58fb6d46e01991a22bb590b310118f6df26f801010000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff3103b46707244d696e656420627920416e74506f6f6c6b2f4542312f4144362f4e59412f332059bb221ab8080000615c0300ffffffff02807c814a000000001976a914660371326d3a2e064c278b20107a65dad847e8a988ac0000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000

There are 6 things which make up the block header:

First we have the version (4 bytes), 00000020, which is reversed bytes of 0x20000000.
Then we have the previous block hash (32 bytes), also in reversed byte order, 53f7ebc735f54ac8d4ebcc1eeb3d3bdea89603bdd27431000000000000000000 which is this block.
Next we have the merkle root of the transactions (32 bytes), in reverse byte order, ff964ec70ea5a5356a04fdb044ca6c59ffda2dd6be02c63d9ea58fb6d46e0199. Because there is only one transaction, the coinbase transaction, the merkle root is just equal to that transactions txid.
Then we have the time stamp (4 bytes), in reverse byte order, 1a22bb59 which is 0x59bb221a in hex or 1505436186 in decimal.
Then we have the reversed bytes of the 'bits' field (4 bytes), 0b310118 which is 0x1801310b
And then the nonce (4 bytes), f6df26f8 which is 0xf826dff6

Then after the header, we have the byte 01 which means there is one transaction, which follows. That one transaction is just the encoded coinbase transaction, as you can see here.

Of course, only the block header needs to be hashed, not the transactions too.


I believe all the following has applied since the beginning and is still what happens.
The mining reward is not given when starting to mine but is allocated when each block has been successfully mined.
The miner chooses what happens to the mining reward. They include as the first transaction in a block a special "coinbase" transaction that has no inputs and at least one output. The sum of the outputs cannot exceed the sum of the currect mining reward plus the total of transaction fees offerred by each transaction they include in that block.
The mining reward cannot be spent until 100 further blocks have been mined (by any miner) in a chain including the mined block.
The mining reward halves every four years roughly.

Related

What is the block maturation time?
What exactly is Mining?


why ripple currency exchange trading is slow sometimes?

Nothing ever happens in Ripple unless some transaction initiates it. Precisely matching orders are permitted under some circumstances to provide enhanced liquidity. The primary purpose of order books in Ripple is to provide liquidity for payments. Having matching offers on the books permits payments in either direction with zero spread.


How can Ripple trust lines be exploited to scam unknowing people?

See the Ripple Trust Lines topics in the Ripple forum.
In this context "empty trust line" probably means a trust line with a zero balance but a non-zero limit. Such a line indicates to Ripple that you are willing to accept a balance of the specified currency from the specified issuer.
Note that the forum topic you refer to was written before the client added support for the server-side "no rippling" flag. This is implemented backwards in the client as an "Allow Rippling" checkbox which is not checked by default. What that means is that if you use the default to create two trust lines the Ripple system will not allow funds to "ripple" between them. Trust lines created before this option was present, or created with the checkbox selected, are allowed to "ripple"; you overall balance will stay the same but it can move (within the trust limits set) to/from a trust line that has "Allow Rippling" enabled. This is an incredibly powerful and useful feature.
So in short the "scam" is to get someone to foolishly extend a trust line to an account the attacker controls for a currency that they hold a balance on (or will in the future hold a balance on) and have the user check "Allow Rippling" on at least one of those trust lines. Then the attacker can make a payment that "ripples" through the victims account "taking" their positive balance and replacing it with a worthless balance they have no intention of redeeming.
To avoid this simply do any one of the following:

Only ever add a trust line to a Ripple account that you trust. Don't tell Ripple you trust someone that is untrustworthy. Only set the limit to an amount you're willing to risk.
This is incredibly basic and obvious but sadly there are people willing to blindly follow pretty "click here" picture instructions to do all kind of unsafe things to their accounts. There is no reasonable technical measure to protect these people from themselves. An attacker could just as easily claim they need your Ripple secret or your pass-phrase in order to send you a payment and some non-zero number of people will foolishly give away complete access to their account.

Leave the "Allow Rippling" checkbox unchecked unless you know what you're doing.

Or even more simply: don't randomly click things or make changes you don't understand on a system that involves your money just cause some random place on the internet tells you to.


Can I earn transaction fees by running as a full node, verifying transactions, but not mining?

Nope, transaction fees of a transaction can only be collected by including it into a valid block. And to be able to include a transaction in a valid block you have to mine a valid block.


What is the average number of transactions that a BTC wallet contains?

There is no answer for your question because you can not know which adresses are connected to which wallet.

By the way: You don't even need a wallet to send or receive transactions.


I forgot my bitcoin core passphrase. Is there anyway I can recover?

No.  The whole point of strong encryption is that it is impossible to recover the data without the passphrase.

You can:

Keep trying to brute force (maybe with faster computers, or a better initial guess at the passphrase)
See if you have a backup of the wallet.dat file that isn't encrypted
Try really hard to remember
Give up, and resolve to be more careful with strong encryption next time.


These transactions don't go through the bitcoin network, it’s just coinbase/cash app crediting one users account and debiting another.


Txindex=1: how to recognise the blockchain with this option?

You can check the debug logs (might require -debug flag) and see if it is indexing transactions:

$ tail -f ~/.bitcoin/debug.log

You can also try to get a transaction by txid, and if it returns transaction data, then the blockchain has been indexed for transactions (might have to wait for sync to complete):

$ bitcoin-cli getrawtransaction {txid}


I chatted to Wladimir about this. He hasn't switched to a new key, he's just using a separate key to sign binary releases.

Additionally, he has signed the new key with the old key, so there's an audit path.


What hardware requirements does a SPV client have?

Bandwidth - You need to receive an 80-byte header about every 10 minutes. In addition, if you want to spend, you will get SPV proofs that range about 500-1000 bytes per utxo. In other words, the bandwidth requirements are really tiny.

Storage - Each block header is 80 bytes, as of this writing, there are less than 430,000 blocks, so 80 * 430,000 = 35.4 MB. 100 MB should last you another 15 years.

RAM - The main usage of RAM is to do SHA256 and ECC signing/verification operations. A minimal CPU with not much RAM (512 MB) can do both without a problem.


How do different blockchains communicate?

Cryptocurrency exchanges are generally taking custody of your funds while you are using their service. You send a deposit of fiat to their bank account or cryptocurrency to an address under their control and after this payment has been confirmed, they credit you a balance on their platform. When you trade one currency for another, they only update their liabilities to you in their database. Only when you withdraw, they send you the corresponding cryptocurrency to your address or wire you fiat.

As you see, the exchanges simply accounts for what they owe you and there is no need for various blockchains to communicate beyond the exchange sending and receiving payments in various currencies.


What are Fidelity bonds and how do they work in Joinmarket?

What are Fidelity bonds?
Fidelity bond is a type of insurance contract designed to protect from losses caused due to forgery, theft etc. Normally used by employers in form of business insurance which generally covers the dishonest activities performed by its employees.
Background:
First ever mention of fidelity bonds. The idea is basically invented by Peter Todd: https://bitcointalk.org/index.php?topic=134827.0
Old idea for combining fidelity bonds with mixers: https://bitcointalk.org/index.php?topic=172047.0
Suggestion that is very close to the fidelity bonds idea in Joinmarket. He talks about requiring a deposit from makers, but nobody is able to come up with a way to make such a deposit decentralized and trustless: https://www.reddit.com/r/Bitcoin/comments/2zc5tc/joinmarket_increase_the_privacy_of_bitcoin_and/ctk37hn/?context=1
Adding fidelity bonds in Joinmarket:
Chris Belcher has opened a pull request which adds Fidelity Bonds in Joinmarket: https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/872
Almost everything is included in the commits and reviews can be helpful in removing bugs (if any) and merge it soon. The only major feature missing is having yield generators announce fidelity bonds held in cold storage.
The changes to the joinmarket protocol are backward-compatible. You can read docs/fidelity-bonds.md for more details. Below is a summary from it:

Fidelity bonds are a feature of JoinMarket which improves the resistance to sybil attacks, and therefore improves the privacy of the system.

A fidelity bond is a mechanism where bitcoin value is deliberately sacrificed to make a cryptographic identity expensive to obtain. The sacrifice is done in a way that can be proven to a third party. Takers in JoinMarket will have a higher probability to create coinjoins with makers who publish more valuable fidelity bonds. This has the effect of making the system much more expensive to sybil attack, because an attacker would have to sacrifice a lot of value in order to be chosen very often by takers when creating coinjoin.

As a maker you can take part in many more coinjoins and therefore earn more fees if you sacrifice bitcoin value to create a fidelity bond. The most practical way to create a fidelity bond is to send bitcoins to a time-locked address which uses the opcode OP_CHECKLOCKTIMEVERIFY. The valuable thing being sacrificed is the time-value-of-money. Note that a long-term holder (or hodler) of bitcoins can buy time-locked fidelity bonds essentially for free, assuming they never intended to transact with their coins anyway.

The private keys to fidelity bonds can be kept in cold storage for added security. (Note: not implemented in JoinMarket yet)

Financial mathematics of JoinMarket fidelity bonds: https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b

How many coins to lock up and for how long?

Fidelity bonds UTXOs are valuable as soon as they confirmed. The simplified formula for a fidelity bond value with locked coins is: bond_value = (locked_coins * exp(interest_rate * locktime))^2

At any time you can use the orderbook watcher script to see your own fidelity bond value.

Consider also the warning on the bitcoin wiki page on timelocks

At the time of writing fidelity bonds are not deployed yet in the wild, but I would recommend locking as many coins are you're comfortable with for a period of between 6 months and 2 years. Perhaps at the very start lock for only 1 month or 2 months(?) It's a marketplace and the rules are known to all, so ultimately you'll have to make your own decision.


Does a thin client testnet wallet exist which allows offline signing?

Testnet transactions have the same format as mainnet transactions, so you can just create a raw transaction on your online testnet wallet, and get it signed by Electrum with a private key it thinks is associated with a mainnet address (the version byte is different, so the same hexadecimal private key will generate a different address on the testnet and on the mainnet, but the signature will still be valid).


Calculating EMA on multiple time periods - right or wrong?

The normal approach is as you suggest, to update the average regularly - that's pretty much the definition of a moving average. For example Bollinger Bands are a similar metric and use a moving average which is continually updated. A true moving average would be updated with every trade made but it makes sense to break it down into periods of 30 seconds or a minute.


How do I know one transaction has confirmed?

If you have txindex=1, you can call getrawtransaction <txid> 1 to receive a decoded tx object, which will include the number of confirmations and the blockhash.


Is anyone using the blockchain (or other core Bitcome technology) for device registration?

As mentioned in the comments, I can certainly see the benefit of using the immutable recording function of the blockchain to identify and record parameters, in this case MAC (media access control) addresses, which are unique to each device.

Here a few challenges which will need to be overcome:

having a device's MAC details would be fantastic for tracking ownership, for example, in the case of stolen goods. However, anyone with even IT basic knowledge knows it's trivial to change a MAC address; so whilst the blockchain is immutable the data (ie MAC) addresses is not
privacy concerns also arise. Without going in to too much detail, it's problematic to say the least to be sharing one's identifying information on a public ledger if one had less malicious intentions (eg identification of MAC address for a stolen iPad, which could then be used to match up with social phishing (social engineering) with Apple Tech Support to match an owner's name with the stolen device)
The MAC address (or similar identifying number) should be encrypted, ideally. Homomorphic encryption allows for manipulation of data without decrypting it, and will be of great use for secure cloud based access. That being said, we're still a long way off meaningful use cases of homomorphic encryption in conjunction with blockchain ledgers


There are two things to backup/save, both can be found in the client under "Wallet -> Security".

The first and most important is your "secret key". Your public key is your ripple address that is r0123456789ABCDEabcde, your secret key is in a similar format but starts with 's', something like s0123456789ABCDEabcde. Write this down or save it somewhere safe. With just this your funds and trust lines can be recovered into a new wallet.

The other thing to save is your wallet. It's stored encrypted and contains your contacts as well as your secret key. The client will let you make an explicit copy into a local file that you can save as you wish. As with the secret key you do this via "Wallet->Security" in the client.

On account creation (and whenever you login) you can set the "Fetch wallet from" option to one of "Payward", "Payward and Local Browser" or "Local Browser". The middle option, both, is the default. It means that an encrypted copy of your wallet is stored at https://blobvault.payward.com (seen/set on the Advanced->Options page) and somewhere in your browser (?where?). The payward option allows you to access your wallet from any device and the local copy makes you not depend on payward being up/accessible at all times.


You are given the hash of the left child itself, and when combined with the computed hash of the data you are given, you can compute the hash of that block (typically referred to as a node). With that hash, you hash it with a provided hash of the left child in it's parent. Then with that node's hash, you hash it with the provided hash of the parent's right child in order to get the root.

If all of the provided hashes for branches that you do not have are correct, and the data is in the merkle tree, then the root hash you end up with will match the root hash that you are given.


If I install the Bitcoin progam on my computer, that simply means that I will be mining Bitcoins over time?

No, the Bitcoin software allows you to receive, hold and send bitcoins. To mine you need specific hardware and software - for most people it is not recommended to bother.


How can I access the mnemonic in the mobile copay wallet?

You should be able to view your mnemonic within the Android App under Settings > Bitcoin Wallet: Personal Wallet > Security: Backup.


Why the difference in send/receive fees on localbitcoins.com?

This is specific to LocalBitcoins.

From the website,

  In order  to divide the costs of handling Bitcoin transactions in a
  fair manner we are introducing deposit fees for incoming transactions.
  At the same we will lower Bitcoin sending fees for all customers.

  Deposit fees will be larger than the new sending fees, generally we
  expect it to be about 3x the amount of sending fees.

Thanks!

https://localbitcoins.com/blog/new-bitcoin-network-fee-model/


How can I verify the PGP signature of https://liteaddress.org on Windows?

These steps can be simplified if you use UNIX, as most of the tools are already available. However I assume you use Windows.
For PGP explanation, search for videos on youtube.

These steps are for the webpage bitaddress.org.

For the PGP part:
1. Download and install Gpg4win.
2. Go to bitaddress.org and click on the link at the bottom to go to Github Repsitory.
3. On their Github page, click on 'CHANGELOG.txt.asc', then click on the 'raw' tab.
4. Right-click and save as.
5. Run Kleopatra(Gpg4win).
6. Click on Decrypt/Verify tab.
7. Find the CHANGELOG file you just downloaded and 'open'.
8. Now click on the 'search' tab, since you are missing the public key to verify the message.
9. The public key for ninja should have been found, click to import it.
10. Click OK/YES when asked to certify the fingerprints, we know it is the correct ones since the key fingerprint is posted on https://bitcointalk.org/index.php?topic=43496.0 .
11. You will be asked to create a account, click yes.
12. Type whatever you want(not important).
13. Create a simple password.
14. Click 'finish'.
15. Select all the IDs, and then tick the box ' I have verified the fingerprint'and next.
16. Click certify.
17. Enter the password you just created.
18. You will get certification successfull, click finish.
19. Now you will be shown if the contents inside CHANGELOG is valid.
20. If you get "The signature is valid and the certificate's validity is fully trusted." Then we know that the file content is authentic and hasn't been tampered with.
21. So now we know that the file CHANGELOG.txt.asc inside their Github is authentic. We can process to the SHA256 part.

For the SHA256 part:
1. Go to bitaddress.org and right-click and save as 'Webpage HTML only'
2. Download and run QuickHash.
3. In QuickHash go to 'file' tab and select SHA256 as Hash Algorithm.
4. Click 'Select File' and select the html file you just downloaded.
5. A SHA256 HASH value will appear.
6. Now go to bitaddress.org again, and at the bottom of the page click at the link to GitHub Repository.
7. Once in their GitHub, click on the file 'CHANGELOG.txt'.
8 At line 29 you will find
"bitaddress.org-v3.3.0-SHA256-dec17c07685e1870960903d8f58090475b25af946fe95a734f88408cef4aa194.html".
9. Do the "dec17c07685e1870960903d8f58090475b25af946fe95a734f88408cef4aa194" match with the SHA256 you got from QuickHash?
10. If matched, then the HTML you dowloaded is valid and authentic, if not, then something sketchy is going on.


How to check my address balance in regtest?

The argument for getbalance is not an address. It is for an account, which is not the same as an address. To get the entire wallet balance, do getbalance with no arguments.


Where can I find code that allows me to calculate Z1 and Z2 from an ECDSA signature?

According to Nils's post, the z values are the hashes that get signed in the ECDSA formula.  Background on what data goes into these hashes can be found on the OP_CHECKSIG wiki page and Krzysztof Okupski's excellent developer reference PDF.

Bitcoin Core's code for generating the hashes is here.  Any other Bitcoin application that signs transactions (or verifies signatures) must have a compatible function (at least for the default SIGHASH_ALL), so you should be able to find an implementation in pretty much any popular programming language.


Is it useful to have miners work on the same block instead of parallel solo mining?

It doesn't really matter all that much. A set of workers working for the same block or each working for an individual block yields you the same profit on average. The only downside is that in order to mine for blocks you either need to have bitcoind running, or join a pool. If you want to mine a few blocks at once, you will need to be running a couple bitcoind instances. The easier setup is to just have one bitcoind running and have all your miners connect to it.

Well, that's the ideal situation anyway. Realistically, you won't ever mine a block this way. You can check out my mining calculator and plug in your numbers. How long is your time to generate one block? Can you wait 5 times that? Probably not. You ought to join a mining pool to get smaller rewards more often. But do it fast, as soon ASIC miners will go in and make your profits really small.

When you'll be joining a pool, logically you'd have all your workers connected to the same pool. Connecting to multiple pools wouldn't change your profits, perhaps it would smooth out your earnings a bit, but the change would be insignificant if you are using big pools.


In a way, yes.  Each block contains the differences of each address and the result becomes the current UTXO set.


Is there a command line Bitcoin CPU miner for Windows?

You can install the standard Bitcoin-QT client, navigate to

\Program Files (x86)\bitcoin\daemon\

and then run

bitcoind -gen=1

However this isn't recommended except on the Test network because it is next to impossible to generate any coins this way on the production network.


What alternatives are there to hardcoding checkpoints into the Bitcoin client?

Checkpoints serve two purposes:

They hardcode a historic part of the chain
They allow us to disable a check (expensive signature checking) in that historic part.

I personally dislike the first part, as it requires users to trust the software they're downloading contains the right checkpoints. Of course, they're already trusting the code anyway in much more substantial ways, but just requiring some piece of data to be updated frequently in a trusted way, to keep up with the block chain validation performance feels wrong to me. Of course, we can't have the second part without the first. Or can we?

There is a proposed idea, which isn't is implemented, to modify the synchronization mechanism to consist of two steps:

In a first step, only headers are downloaded and verified, in much the same way as blocks are now downloaded and verified. This will result in the client knowing the best valid chain of blocks, except it won't know whether the transactions in it are valid.
In a second step, the actual blocks along this chain are downloaded and verified.
Such a mechanism has several advantages, including being able to distribute the synchronization over several nodes, and not risking downloading side chains (sometimes called orphans).

In addition, it could have a rule "Do not validate signature checks if a block has N blocks on top of it". Since the client already knows there is a valid chain before doing the full transaction validation, there is no need for checkpoints to prevent getting a wrong chain.

Of course, this will have to be thought about a lot before implementing it, but I believe it will allow us to not rely on checkpoints anymore.

EDIT:
Benefits of checkpoints can be realized in better ways like assumevalid .

Recent versions(>= 0.14) of bitcoin core come with option --assumevalid <safe-block> . This gives the benefit of skipping signature validation upto the safe-block without hardcoding the history. If another heavier chain is seen which does not contain the safe block, the bitcoin software will correctly reorg to the other chain.
More Info: What are the trust assumptions in --assumed-valid in bitcoin core 0.14?


How to derive the private key associated with a Coinbase multi-sig vault address

I did some digging into Coinbase's offline multisig tool to figure out what the user seed actually was and their derivation paths. It turns out the user seed is just that, a seed that is used to get the Master Private Key. This is done by hashing it with HMAC-SHA512 where the key is the string Bitcoin seed and the data is the binary form of the user seed (which means decode it and get the binary data).

To do this with pybitcointools, we first decode the WIF user seed with decode_privkey and re-encode it with encode_privkey in order to get the binary form. Then we pass that into bip32_master_key to get the bip32 master key from that seed. And from there, just call bip32_ckd to get the extended private key of whichever index child we want. Lastly we extract the actual private key with bip32_bin_extract_key and encode that with encode_privkey in order to get it into WIF form which can be imported and used in other wallet software.

The below code does all of this for you and will print out the extended master private key derived from the seed, the extended public key derived from the master key (which should match the public key you have), the extended child private key, and that child key in WIF.

Replace the values for USER_PUB, USER_SEED, and I with your actual user public key, user seed, and child index that you want. The values I have here are real and will work.

from pybitcointools.deterministic import bip32_ckd, bip32_master_key, bip32_bin_extract_key, bip32_privtopub
from pybitcointools.main import decode_privkey, encode_privkey

USER_PUB = 'xpub661MyMwAqRbcEzdGMFKZXuVwbyHY2zKhiw6YFTrULfNBF53QVfXyoAiKMZKWkQA5444NXtLj9HPmgyN1xLCiJJ9dKAy4nLZJ87trHRnwUDb'
USER_SEED = 'L3XCYcQ2pwY3YTuwyPXzWsvVtGnCp4zL2ajP3XQt2pVhPuKiVM7r'
I = 14

user_seed = encode_privkey(decode_privkey(USER_SEED), 'bin')
priv = bip32_master_key(user_seed)
derived_pub = bip32_privtopub(priv)
child_priv = bip32_ckd(priv, I)
assert USER_PUB == derived_pub
print "Master Private Key corresponding to seed: " + priv
print "Master Public Key corresponding to seed: " + derived_pub
print "Extended Private key at index " + str(I) + ": " + child_priv
print "WIF format of that key: " + encode_privkey(bip32_bin_extract_key(child_priv), 'wif_compressed')


How does SPV prevent double spending of UTXO?

In a bitcoin transaction, A's address is not scanned for spendable Unspent Transaction Outputs (UTXOs). Full nodes simply check if the inputs of the transaction are really unspent. There is no scanning of addresses involved.

UTXOs are stored as the transaction id (txid) and the output index of the transaction that created them. You cannot reference the outputs to be spent by address, the address merely specifies which private key must sign the input script in order to claim the UTXO.

Suppose you advertise addr1 for donations, and you receive 3 donations D1,D2 and D3 on that address. You have 3 UTXOs and not 1. The only thing is that they can be claimed by same private key. Hence, there is no looking around for previous transactions. Wallet has to specify which UTXOs it is consuming.

SPV allows a lightweight client to verify that a transaction is included in the Bitcoin blockchain, without downloading the entire blockchain. To verify that a transaction is in a block, a SPV client requests a proof of inclusion, in the form of a Merkle tree branch. It does not check for double-spend on it's own. Rather it relies on the full node servers it is connected to do so. To prevent from being cheated from single server, they connect to multiple servers to get the block headers.
From Bitcoin Wiki:

  The level of difficulty required to obtain confidence the remote node is not feeding you fictional transactions depends on your threat model. If you are connecting to a node that is known to be reliable, the difficulty doesn't matter. If you want to pick a random node, the cost for an attacker to mine a block sequence containing a bogus transaction should be higher than the value to be obtained by defrauding you. By changing how deeply buried the block must be, you can trade off confirmation time vs cost of an attack.

You might also want to look into Fraud Proofs which would allow full nodes to prove that information propagated on the network is invalid, e.g. allow full nodes to point out double-spends to thin clients.

Another Reference: Thin Client Security


Assuming you sent the amount to the correct address you have nothing to worry about. This is expected for a wallet that has to download and verify the whole blockchain. Other wallets use SPV that only verifies transactions for your addresses and thus they do not have to download the whole blockchain. Examples of SPV wallets for the desktop are Multibit and Electrum.

After syncing you will see the balance reflected but you could also immediately check if the coins arrived to your address correctly with a block explorer. E.g. go to Blockchain.info or BlockExplorer and search for your address: you will see the amount on that address, the number of confirmations, etc.


Bitcoin unconfirmed trasection to cancel

It is not possible to 'cancel' a published transaction. After you publish a transaction to the network, all of the nodes will relay your transaction, so that eventually they (should) all know of your transaction. If you tried to publish a 'cancel request', you would have no guarantee that every single node would hear about that request, and even if they did, they may not be incentivized to listen to it. So 'cancelling' a transaction is not part of the protocol.

Your transaction included a low fee, and so it has not yet confirmed. Eventually, the network's nodes may all 'forget' about your transaction, so you could then re-spend the coins to an address you control. Take a look at this question for more info on unconfirmed transactions.


Found the answer here:

http://forums.debian.net/viewtopic.php?t=105858#p506223

worked beautifully for me..


I would like to know, if using txindex = 1, will solve my problem with transactions that are not found.

Yes, getrawtransaction only works for transactions with unspent outputs, unless txindex is enabled (in which case it will find every transaction). gettransaction only works for your wallet transactions.

  Using txindex = 1 and -reindex, how long does it take to finish?

It depends on your hardware, but it can be between hours and days on low-end hardware. Using a larger -dbcache will massively speed it up.

  Fullnode will have to download again the 130GB?

No. It just reprocesses blocks you already have on disk.

  Will increase storage?

Yes, a few gigabytes.

  OBS: My real problem is that there are some transactions that have been made to my wallet and my fullnode can not find it.

Your wallet has nothing to do with getrawtransaction. You can always use gettransaction for your own transactions, though.


ScriptSig content during signature (quadratic hashing)

It's like that because that is how Satoshi wrote the code for it and it has never changed. It can't change without some sort of fork, and thus far, no fork has happened to change it (although segwit will once it activates).

However doing it this way allows for people to more easily do multi-party transactions like CoinJoins. They don't require you to know the scriptPubKey of everyone else's inputs, you just sign what you are able to sign. You don't know the scriptPubKey's and you don't care, all you need to know is the scriptPubKey for the input that you are signing. This makes it much easier to participate in multi-party transactions especially for those using lite wallets as they don't have the UTXO set.


Which iPhone bitcoin wallets let you scan a watch only address and sweep addresses?

There are other wallets on iOS but these additionally support xpub import, so you can generate addresses for recieving, without private keys:

BitWallet
ArcBit


you should download the bootstrap.dat - this will take the time for the blockchains to catch up from days to two hours... google it.


There are several reasons for this:

We don't want a dependency management tool to automatically download software from the web. There is always a risk of some backdoor inserted by someone malicious in case we do not manually verify each 3rd party component.
We would like to keep the build scripts as simple and low level as possible to maintain full control of the build output. Specifically, we would like to make sure the build is 100% reproducible from source so that anyone can rebuild it to make sure the published source code is the one used to build the published binaries.
We don't particularly like Maven.


Bitcoin does not have the concept of account balance. Anyone who can provide a valid signature to the locking script of a particular transaction output can spend those bitcoins. As a result when you spend your bitcoins in a transaction, you have to include the transaction id and the output no. from which you earned those bitcoins. The nodes maintain a set of unspent transaction outputs (UTXOs) in the memory to check that this transaction output that has been referenced in the input has not been spent previously (this prevents double spending.)

If you want to send X BTC to a particular address, you will need to reference enough transactions in the input so that sum of all those unspent bitcoins >= X. This referenced transactions can come from different addresses. You just need to provide valid signature with your private key to show that you are the owner of those bitcoins.


Decode script return different value from my relative timelock

decodescript has this behavior because integers in Bitcoin are little endian. So decodescript is telling you what number the script interpreter would use when it processes your script.


what is type of wallet with 18 words seed?

18-word phrase

I believe Coinomi was a wallet which would accept an 18-word seed phrase. There will be many others.

Coinomi lets you choose the length of your seed-phrase from a list of valid lengths: 3 6 9 12 15 18 21 24

35 random letters

Private keys are usually longer

Addresses can be 35 letters long but usually start with a digit or with bc1

See https://en.bitcoin.it/wiki/List_of_address_prefixes

Perhaps this is a passphrase for the seed-phrase - the BIP39 specification allows for an optional passphrase. Some wallets have an "option" button which may allow you to enter a BIP39 passphrase - though they may call it a "seed extension" or something else.


Are Bitcoin / Cryptocurrency free & paid "Faucets" illegal in the USA?

The trade of cryptocurrencies for other cryptocurrencies is not regulated in the United States under FinCEN guidance or IRS guidance, as of August 12th, 2014

Cryptocurrencies are designated as property under IRS guidance, and property generally enjoys like-kind treatment to defer capital gains until that property is exchanged for US Dollars (or other fiat currency) and kept in US Dollars for a certain period of time. These are property regulations and a consequence of designating cryptocurrency as property.

As such a 'paid' faucet would not be money transmitting, or incur a tax event. And there are no other prohibitions on cryptocurrencies in the United States (from a federal standpoint, state and municipal governments may have leeway to make up something else).

A free faucet, on the other hand, may incur a tax event of some type (income?), but the amount is typically very small and sanctions against amounts that small are an afterthought.

Not advice.


Convert 12 word seed with passphrase -> 12 word seed without passphrase

No, this is not possible.
The mnemonic and passphrase are put through PBKDF2. Any change in the input results in a completely different output.
While it is possible that there exists some 12 word mnemonic that just happens to hash to the same seed as your original mnemonic + passphrase, this would require bruteforcing all possible mnemonics to discover, and would not be derivable from the original mnemonic in any form - a hash collision would be completely unrelated.


I don't see the problem, or what compromises privacy exactly?

Say you have UTXO A1 and B1 of 0.001, (I've never used Coinjoin so i'm just assuming here.)

Now you put both A1 and B1 through Coinjoin, Now you have A2 and B2.

How would combining the outputs of A2 and B2 compromise the privacy of outputs A1 and B1?
You used CoinJoin to break exactly that chain right?

Put the balance of the change adresses all individually through coinjoin mixing sessions and then combine the outputs? That way the chain is broken, and due to them being linked only after the chain was broken, privacy isn't compromised?

If they're too low of an amount to be send to Coinjoin, i'm afraid it's just dust, and they should be frozen to prevent them from accidently being spent  in the future when tx fees might be lower again.