Javascript library or code that can convert an "uncompressed" bitcoin private key to a compressed one I forked a pretty old brain wallet generator: https://dvdbng.github.io/memwallet/ -- Currently it generates uncompressed bitcoin private keys. Is there a javascript library that can convert an uncompressed bitcoin private key to a compressed one? Or what is the required fundamental knowledge to know in order to compress a bitcoin private key?

Update:

Oops sorry I read "public key". A private key can be converted to a public key that is either compressed on uncompressed, but raw EC private keys are always 32 bytes. That website appears to be generating what is called Wallet Input Format (WIF) which is used to transfer private keys between software applications. To convert to hex:

decode using Base58Check
drop 1st byte
If the WIF started with K or L, then also drop the last byte (0x01) which denotes the private key corresponds to a compressed public key

Example:

WIF: 5J2zgrqrMFcnWALe5foVPzaA8VLNJV8zoZn37WfQCu8DYDCVmXE

Base58Check decoded: 801cdb52e9a9fa3e089c7b8713218df4a7924b2109b159df480960ddfe73e221c3
Drop 1st byte:
1cdb52e9a9fa3e089c7b8713218df4a7924b2109b159df480960ddfe73e221c3
N/A

old:

Given a public key, e.g.

04a097026e876544a0e40f9ca836435560af4470e161bf60c23465dcb3151c947d1cbe052875211972107e25fca8dd939f1c6e749a43862673ec5cf7a8567f2d95

The 0x04 designates this as an uncompressed public key, where the next 32 bytes are the x value and the final 32 bytes are the y value of the point on the elliptic curve, respectfully.

To convert from an uncompressed public key to a compressed public key, you can omit the y value because the y value can be solved for using the equation of the elliptic curve: y² = x³ + 7, given x. Since the equation solves for y², y could be either positive or negative. So, 0x02 is prepended for positive y values, and 0x03 is prepended for negative ones. If the y coordinate is even, then it corresponds to a positive number. If odd, then it is negative. Since the y value ends in 0xee, which is even, and therefore positive, the compressed version of the public key becomes:

03a097026e876544a0e40f9ca836435560af4470e161bf60c23465dcb3151c947d

Javascript

You can use bitcoinjs-lib to convert:

const bitcoin = require('bitcoinjs-lib')

const pubkeyBuf = Buffer.from('04a097026e876544a0e40f9ca836435560af4470e161bf60c23465dcb3151c947d1cbe052875211972107e25fca8dd939f1c6e749a43862673ec5cf7a8567f2d95', 'hex')
const pubkey = bitcoin.ECPair.fromPublicKey(pubkeyBuf)
pubkey.publicKey.toString('hex')

'03a097026e876544a0e40f9ca836435560af4470e161bf60c23465dcb3151c947d'


Do multiple miners contribute to mining the same block even if they are not in the same pool Assuming that this is reliable, according to an article on investopedia on the 51 percent attack:

  51% attack refers to an attack on a blockchain – usually bitcoin's, for which such an attack is still hypothetical – by a group of miners controlling more than 50% of the network's mining hashrate, or computing power. The attackers would be able to prevent new transactions from gaining confirmations, allowing them to halt payments between some or all users.

Does the above bold line imply that all the miners are required to provide their confirmation for a transaction to be added to the blockchain? I was under the impression that even an individual could, if he completes the proof of work first, cause the addition of the block to the blockchain? What am I missing here?

I was under the impression that even an individual could, if he completes the proof of work first, cause the addition of the block to the blockchain? What am I missing here?

That it could happen that 2 blocks are found at the same time. Which usually causes the network to split into two chains, ( One part of the network is going to build/find a new hash based on block y, and the other part of the network is trying to find a new valid hash based on block X.).

Whoever finds Block Z first creates the longest chain and thus invalidating the shorter one. ( Miners who build on block Y find block Z so now block X ( which is the shortest chain) gets orphaned )= now invalid.

The same principle applies to a 51% attack, since you have majority hashpower you will always (hypothetically) find a valid hash faster then the other chain which has 49% hashpower.

In that case, no individual ( unless the individual owns 51% of the hashpower) is going to be able to "mine" a block/(or rather, - get a block added to the longest/valid chain).

Your title is something else then your question,

  Do multiple miners contribute to mining the same block even if they are not in the same pool

Well, yes, if there's only 1 chain, every miner is going to be building upon that chain, which means they'll all be looking for a block ( or rather a hash) that is going to be valid on that chain ( basically the next block?)

I wouldn't use contribute though, it's not like they share their hashpower, but they do indeed share the same goal. -> Finding a block with a valid hash that is valid on the current chain.


Unconfirmed incoming transaction for a long time I received BC from currency exchange provider. Is unconfirmed for a pretty long time. Is this standard waiting time or maybe sender did not provide enough fee? I didn't have any choice what fee he payed and I think it is not possible to pay it after the transaction...
Thanks for the input.

https://blockchain.info/address/19oaganA4BN4khDn1kno6mctxLKSmFadk4

The fees are quite low indeed. If you check the transaction instead of the address, you can notice that they are paying 51 Satoshi/Byte.

According to bitcoinfees.21.co, the recommended rate to get a transaction confirmed as soon as possible is around 220 Satoshi/byte nowadays.

So, what you can do is either wait until the transaction get confirmed, or spend the UTXO by creating a new transaction with a high fee, following a Child-pays-for-Parent (CPFP) approach.


Lag of minutes for poloniex API `returnChartData`? It seems that Poloniex takes up to 2-3 minutes (with quite a lot of variance) to compile the OHLC data (API method returnChartData) of a period that just ended. I've experimented with 30 minutes periods, so 2-3 minutes is up to 10% of a period, which is a lot!

Could it be that I'm doing something wrong? I'm using this python-poloniex wrapper, and I'm after the OHLC prices of a few BTC pairs.

No, you are not doing nothing wrong. It's internal issue of Poloniex.
Every day I see that most of cryptocurrencies have missed candlesticks. And after up to 40 min are updated.
Even on charts you can see that


Which is the relation between transactions and blocks? I don't quite understand the relation between a transaction and a block.
I imagine it as a list of blocks, and each block having a list of transactions but I have some doubts.

When I do a transaction...

It should go to a specific block?
An unconfirmed transaction is a transaction which is not inside a block?
Can the miner add the new transaction to an older block? Once a block is solved, new transactions can be added?

The initial statement is correct. The blockchain is the list of all solved blocks, essentially the ledger of all transactions completed in the Bitcoin network. Each block contains (among a few other things) a list of transactions.

When you do a transaction, it is not destined for a specific block. You merely publish your transaction to the network and it goes onto the list of unconfirmed transactions. (There is actually no one authoritative list, however, everyone on the network keeps their own list and distributes it to others to whom they are connected.) Miners (who solve the hashing puzzles required to "solve" a block and make it official) will typically include all unconfirmed transactions in the blocks they create. But they may not. They may just not have received your transaction in their part of the network yet. Or, if your transaction didn't have a fee included, they may only be willing to process transactions with fees. Technically, they are under no obligation about which transactions to include in the block. But since miners get fees from many transactions, and miners benefit from the strength of the Bitcoin network, transactions are typically quickly included in a block.

To answer your second bullet, yes, an unconfirmed transaction is one that has not yet been included in a block.

And to answer your final bullet, no, new transactions cannot be added to older blocks. The "solution" to a block is a mathematically hard puzzle to solve, and it is based on the transactions that are included. So, if you added a transaction to an older block it wouldn't be the same block any more. And the "solution" wouldn't work either, so it would essentially have to be re-mined.

And to further complicate adding a transaction to an older block, each block also includes a piece of information from the previous block in the block chain. Meaning that if you added a transaction to an older block (or modified it in any way), you would not only have to re-solve the old block, but you would have to re-solve all blocks between that block and the current block. And since no one would recognize your re-solved blocks unless you were able to create an even longer blockchain than what currently exists, it isn't realistic to be able to do so. You would have an extremely large amount of processing to and you would have to solve it considerably faster than the rest of the world was working on the old block chain. (The exception is if you have more mining computing power than everyone else in the world combined. This is sometimes called the 51% problem.)

This is all by design. The point of the block chain is that the history of transactions is unalterable and mutually agreed upon as the truth. If it were possible to add transactions into the past, you could change that history. And, for example, spend the same bitcoins twice. But because of this chaining of bitcoins that isn't possible. (It is also why most people don't consider a transaction final until it has "6 confirmations". What "6 confirmations" really means is that the block that it is included in is 6 deep in the block chain. At that point the block chain is deep that it is considered completely unalterable.


How does a Doge public key is created from a private key? I am looking for the differences between the creation of Doge public keys and Bitcoin public keys when inserting a private key.

I am trying to make a small web-app that signs messages. There are a tons of them with bitcoin. They receive a private key and creates the public key from there. When I enter a Doge private key to the input the output is still a Bitcoin public key (Starts with 1 for example instead of D).

Dogecoin uses the same public key cryptography ECC with curve secp256k1, so public key generation is the same.

  When I enter a Doge private key to the input the output is still a
  Bitcoin public key (Starts with 1 for example instead of D).

You are confusing addresses with public keys. The 1 or the D is just a prefix to an address, depending on the type of address, see https://en.bitcoin.it/wiki/List_of_address_prefixes

After you generate the public key, you have to do the following in order to get an address:

BASE58CHECK(<address-prefix> HASH160(<pubKey>))

Dogecoin uses different prefixes for the different types of addresses, see https://github.com/dogecoin/dogecoin/blob/master/src/chainparams.cpp (note these are for mainnet only):

base58Prefixes[PUBKEY_ADDRESS] = std::vector<unsigned char>(1,30);  // 0x1e
base58Prefixes[SCRIPT_ADDRESS] = std::vector<unsigned char>(1,22);  // 0x16
base58Prefixes[SECRET_KEY] = std::vector<unsigned char>(1,158); // 0x9e

Changing the address prefixes should yield compatible addresses.


Can the same target address appear more than once on transaction output? Normally, a transaction output will contain a list of address + amount.
Each element in this list has an associate output number, "vout".
For example:

Transaction outputs:

vout=0: addr=m111111, amount=100
vout=1: addr=m222222, amount=200

My question is: would it be legal for a transaction output to contain
the same target address more than once?  Take for instance the example below, where address "m222222" appears in vout=1 and vout=2:

vout=0: addr=m111111, amount=100
vout=1: addr=m222222, amount=100
vout=2: addr=m222222, amount=100

I know this seems silly.  I'm just wondering if it is the sort of
thing one might encounter "in the wild".

There is no protocol rule which forbids having multiple outputs with the same bitcoin address. Here is an example of such a transaction:

https://blockchain.info/tx-index/16459554/3baf2227efd23449822e181372389af762c26a4567362ef174fa8659cf61eb20?show_adv=true

It is not common to see this as there is no point in having mutiple outputs when it can be done in one, it just makes the transaction larger and hence increases transaction fees.


how to get private key of old receiving address in blockchain.info. I have passphrase! I have mistakenly sent bitcoins to my old receiving address from Unocioin wallet and later i imported it into my wallet but it is not transferring it is asking private key. neither I' m able to send to any because it is asking me private key but i didn't know where it is? i have passphrase but how can i generate private key with passphrase?

Unocioin

Did you mean Unocoin.com?

As far as I can tell, Unocoin operates custodial wallets (via BitGo and Blockchain.info APIs), meaning that only they have access to the private keys. If this is true and you've transferred bitcoin into your Unocoin wallet, then the only way to retrieve it is to log into your Unocoin.com account (or contact their technical support for assistance).

You could also try sending a message to bitcointalk user dashingriddler who apparently is a Unocoin employee.


Electrum two factor authentication In the Electrum wallet for pc, it is possible to modify a wallet from normal password to 2fA (two factor authentication ) without creating a new wallet?

Also, the fee for the 2fA it's billed only when sending funds from the 2fA wallet to outside, and not when we receive, right?

In the Electrum wallet for pc, it is possible to modify a wallet from
  normal password to 2fA (two factor authentication ) without creating a
  new wallet?

No, it is not possible to add two-factor authentication to an existing wallet. these are two different wallet types.

  the fee for the 2fA it's billed only when sending funds from the 2fA
  wallet to outside, and not when we receive, right?

The sender always pays the fee.


How many hashes create one Bitcoin? Irrespective of the length of time required to calculate one hash, how many hash operations are required to produce one Bitcoin?

These charts show the approximate network hash rate on the left axis:
  http://bitcoin.sipa.be/

We know the network adjusts for 25 new bitcoins per 10 minutes.

Together this provides enough info to give an approximate answer to your question:

hashes per bitcoin
= (network hash rate) / (25 BTC per 10 minutes)
= (180 * Th / s) / (25 * BTC / (600 * s) )
= 180 * 600 / 25 * Th / s / BTC * s
= 2,700 Th / BTC
= 2,700,000,000,000,000 h/BTC


Where are the Main network magic bytes stored in bitcoin's source code? Bitcoin uses F9 BE B4 D9 as its main network magic bytes. I've searched the source but cannot find where these values are stored. Presumably they're computed, but I'm not sure where. Can someone tell me where they exist or are computed in the source code? I'm wanting to find this value for other altcoins.

See the file chainparams.cpp in the constructor for class CMainParams:

pchMessageStart[0] = 0xf9;
pchMessageStart[1] = 0xbe;
pchMessageStart[2] = 0xb4;
pchMessageStart[3] = 0xd9;


Where can I see the average transaction fee payed in the last 100 blocks? Is there a site that shows what's the average transaction fee payed in the last X blocks? Or just raw data about this?

I checked BlockExplorer and Sytes and they don't seem to show this information.

Blockchain.info shows the amount of fees payed each day.


What does a comparison of Bitcoin Days Destroyed say about Bitcoin vs Namecoin vs SolidCoin? The Abe blockchain explorer provides statistics for percentage bitcoin days destroyed, using the generic term "% CoinDD".  Currently Bitcoin is 36.1245%, Namecoin is 41.5547%, and SolidCoin is 47.0952%.

My guess is that the relatively high numbers for Namecoin and SolidCoin could indicate that people are cashing their mined coins in for other currencies or goods more regularly than people have historically done with Bitcoin.  What is known about the Namecoin and SolidCoin transaction cultures?

But of course Bitcoin only became really active in recent months.
It would be interesting to see comparisons of recent activity.  Are regularly updated graphs over time available for these % CoinDD values?

While Bitcoin DD% is lower it is a lower % on a larger base.  Converted to a standard unit say USD Bitcoin transactions are a magnitude higher than other coins.  The lower DD% doesn't tell us anything about the nominal amount of transactions but rather the relative days destroyed between currencies.

The lower DD% simply means that less of the older coins are moving in the bitcoin economy than other economies.  Other economies are much newer thus they don't have very old coins which due to their extreme age can skew the stat donward.    If the oldest SolidCoin miners simply mine and hold they at most can prevent a 14 days from being destroyed.  For early bitcoin miners holding onto a single coin can prevent hundreds of days from being destroyed.

As for reason why older coins may not have the same velocity as newer coins.  Some of that may be loss.  For a long time bitcoin was worth less than a cent.  Someone with 10,000 coins (a huge sum tody) may not have taken very many precautions against it and lost coins in data losses or system formats.

Some early miners may have done it simply for academic reasons rather than any investment and when they stopped they deleted (intentionally or accidentally) their wallets.

In the early years of bitcoin there wasn't much value or reason to quickly sell coins.  Now the miner may no longer even be mining and just holding the coins as a speculative investment.  Newer chains usually have an exchange open from day one.  Checking the alternative cryptography forums and exchange chats will indicate a large number of miners aren't mining alt coins for long term appreciation (which would result in low DD%) but instead are quickly selling on exchanges for other currencies including fiat.


What attacks are possible with a malicious bootstrap.dat? The standard Bitcoin client normally needs to download the entire blockchain from the p2p network when first installed, but a shortcut is to provide it with a snapshot of the blockchain (at some point in time) in a file called bootstrap.dat.  One can get this file from various sites and file sharing mechanisms such as BitTorrent.

My understanding is that the blocks taken from bootstrap.dat are not subjected to all the same checks as those downloaded from the p2p network (see this question).  Therefore, an attacker might be able to get you to accept some invalid blocks by giving you a malicious bootstrap.dat.  What, if anything, could they accomplish in this way?

For instance, if signatures are not verified for transactions coming from bootstrap.dat, the attacker might include a bogus transaction appearing to send a bunch of coins to one of their addresses.  They could then convince you that they hold more coins than they actually do.  But it's not clear how useful that would be; if they actually try to send you those nonexistent coins in payment for something, your client might believe the transaction is valid, but miners won't be fooled and the transaction will never confirm.

Are there other attacks I have not thought of?

You can fake an entire history of transactions and blocks perfectly, but unless you can get a majority of clients approved it's useless.

I'm not sure majority is defined as 51%, because there crypto is more complicated then that.

But look up how transactions get verified

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

So, basically it depends on the lower level procedures which decide which clients to confirm against and you'd need to get majority of those just to fool your client.

Because when an error is detected they all start communicating it


I need to buy a gift card for PlayStation using bitcoins or altcoins I need to buy a gift card for PlayStation using bitcoins or altcoins. Unfortunately, there is currently no other payment method. Can someone help?

https://www.bitrefill.com/ is an option, looks like they offer gift cards for the PlayStation store.


Test (r,s) values for signature generation? I have some RFC6979 test vectors, but they do not simply give me the (r,s) values before DER encoding (or so it looks?), and I haven't reached that point yet. Where could I find some (r,s) values to test against?  My "expected k" values are passing tests.  Perhaps the (r,s) values are in the "expected signatures" in those tests, but from my brief and naive overview, those "expected signatures" don't look like they are DER encoded, making it harder to find the (r,s) values if they are in there, and if they are not DER encoded (or are simply concatenated r,s values), they definitely are not matching my (r,s) values.

# Test Vectors for RFC 6979 ECDSA, secp256k1, SHA-256
# (private key, message, expected k, expected signature)
test_vectors = [
(0x1, "Satoshi Nakamoto", 0x8F8A276C19F4149656B280621E358CCE24F5F52542772691EE69063B74F15D15, "934b1ea10a4b3c1757e2b0c017d0b6143ce3c9a7e6a4a49860d7a6ab210ee3d82442ce9d2b916064108014783e923ec36b49743e2ffa1c4496f01a512aafd9e5"),
(0x1, "All those moments will be lost in time, like tears in rain. Time to die...", 0x38AA22D72376B4DBC472E06C3BA403EE0A394DA63FC58D88686C611ABA98D6B3, "8600dbd41e348fe5c9465ab92d23e3db8b98b873beecd930736488696438cb6b547fe64427496db33bf66019dacbf0039c04199abb0122918601db38a72cfc21"),
(0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140, "Satoshi Nakamoto", 0x33A19B60E25FB6F4435AF53A3D42D493644827367E6453928554F43E49AA6F90, "fd567d121db66e382991534ada77a6bd3106f0a1098c231e47993447cd6af2d06b39cd0eb1bc8603e159ef5c20a5c8ad685a45b06ce9bebed3f153d10d93bed5"),
(0xf8b8af8ce3c7cca5e300d33939540c10d45ce001b8f252bfbc57ba0342904181, "Alan Turing", 0x525A82B70E67874398067543FD84C83D30C175FDC45FDEEE082FE13B1D7CFDF1, "7063ae83e7f62bbb171798131b4a0564b956930092b33b07b395615d9ec7e15c58dfcc1e00a35e1572f366ffe34ba0fc47db1e7189759b9fb233c5b05ab388ea"),
(0xe91671c46231f833a6406ccbea0e3e392c76c167bac1cb013f6f1013980455c2, "There is a computer disease that anybody who works with computers knows about. It's a very serious disease and it interferes completely with the work. The trouble with computers is that you 'play' with them!", 0x1F4B84C23A86A221D233F2521BE018D9318639D5B8BBD6374A8A59232D16AD3D, "b552edd27580141f3b2a5463048cb7cd3e047b97c9f98076c32dbdf85a68718b279fa72dd19bfae05577e06c7c0c1900c371fcd5893f7e1d56a37d30174671f6")

UPDATED:  The simple question that should have been asked here is whether the expected signature values in the test vectors is a concatenation of the (r,s) values?


Remaining bitcoins sent to a different address Let's say I have 20 bitcoins in address A. I sent 5 bitcoins from address A to address B. Why is that the remaining bitcoins got sent to address C that I never used or knew before.

I still get access to the remaining 15 bitcoins using the private key of A, but it doesn't show anymore in recipient address A. This is very confusing and would appreciate if someone would clarify.

Also, when I need to receive any bitcoins, which I address should I use? Original address A or address C?

Your bitcoin client must have used a full UTXO to paid for your transactions, since you didnt own the exact amount your bitcoin client created a new private key where it send the remaining ( 20-5 = 15 ) bitcoins, also you had to pay a fees to the miner who mined the block that got your transaction.

To learn more about this process you should go there https://en.bitcoin.it/wiki/Change

If you want to receive new coins, The most private and secure way would be to use a new address given by your wallet, I suggest you to learn about HD wallet who can give you automatically a new address each time you want to receive new bitcoins.


Non-profit balking at linking bank account to BitPay I volunteer as the webmaster for a non-profit and convinced them to allow bitcoin donations.  I integrated their website with BitPay and everything is working fine.  We got one large donation and a few small ones so far, despite very little publicity.

Recently I asked the treasurer for the banking info so I could link the bank account to BitPay and he balked!  We have gone back and forth on emails and the only explanation I can get is "I'm not comfortable with that".  I should mention that we have had PayPal integration for years and regularly send PayPal funds to the bank account.

So now we are accepting bitcoin with no way of getting it to the non-profit.  I don't think the organization has any expenses that can be bought with bitcoin. I would have thought if there were any objections it would have been to accepting bitcoin altogether, not at the point of linking the bank account!

I pasted the Wikipedia article on BitPay in an email to stress that it's an established company, but it had no effect.

Any advice on how to proceed?

Suggest other ways to get from Bitcoins to USD. You could, for example, sell the coins with Coinbase or Bitstamp. My suspicion is that you are dealing with someone who doesn't like having only one option. With several options, you can explain the advantages and disadvantages of each one and you both can choose the best one. If that's BitPay, you should be able to explain why that's the right choice, and that should make him more comfortable.


When are multiple transactions spending the same output in the same block considered a double spend? Here is an example of multiple transactions in the same block, all spending from the same output. I created these using the Electrum wallet, telling Electrum to spend a little bit of the BTC from the same 1AD9xV6aeQMPMzfv5Nzk8yNDgtyV3LaUkB address each time

See: https://blockchain.info/address/1AD9xV6aeQMPMzfv5Nzk8yNDgtyV3LaUkB

When I try doing a similar thing myself with Python and the Pycoin library, the second transaction gets flagged as a "double spend" when I submit it to blockchain.info/pushtx. The response I get is:

  An outpoint is already spent in [DBBitcoinTx [txIndex=101360418, getEstimatedBTCSent()=0, isGeneratedBlockReward()=false, getTotalBTCSent()=0, getHash()=1766bb1b732db7b3eef1bea27a572651ee343d79ca6c5b9e866e2f97e8df85aa, getVersion()=1, getSize()=258, toString()=BitcoinTx{hash=1766bb1b732db7b3eef1bea27a572651ee343d79ca6c5b9e866e2f97e8df85aa, version=1, lockTime=0, in=[], out=[]}, getClass()=class piuk.blockchain_db.DBBitcoinTx]] [(101355273, 1)]

Like in the first example, the total spent by all the transactions never exceeds the total available at that address, so I'm curious why this is considered a "double spend".

How should you structure a series of transactions spending from the same address so that a double spend is not triggered?

Adding my own answer after doing some research: An address and an output are different things. A transaction may have many inputs and many outputs. Here is a good visualization from bitcoin.org:

A double spend occurs when the same BTC is used to pay two different people. This will never happen on the blockchain because the Bitcoin network guarantees a consistent ledger. But, what about the unconfirmed transactions that live in the miners' mempools?

Some inconsistencies in the mempool may not manifest until they are added or not-added to the blockchain, others we can flag as invalid right away e.g. amount exceeds available funds etc; If unconfirmed transactions were not checked for validity, an attacker could flood the mempool with bogus transactions and cripple the network.

A submitted transaction that has the exact same inputs and outputs as another unconfirmed transaction in the mempool is rejected by the Bitcoin network (even if it was a valid financial transaction). For example, I could send 1 BTC from A to B, and while the transaction is unconfirmed, send another 2 BTC from A to B. As long as A has 3 BTC to cover the transfers, these transactions are consistent, but conservatively rejected by miners.

You can see this yourself with the Electrum wallet using the "Send From" option. Normally, Electrum picks valid inputs for you, but you can override this. Create a transaction specifying the from and to addresses. Then, create another transaction with same from and to (but the amount can differ). If the first transaction is still pending, you'll get the following error:


How can I make Zap synchronize with the Bitcoin network? I'm using the Mac operating system. I downloaded Lightning App and Zap from Github.

The wallet can not be synchronized with the network, how can I synchronize it and can I do it without having to download the full blockchain?

Lightning App shows me the error the network can not be synchronized...,
when I launch Lightning App it also pops up an error: Syncing to chain ... block height: 0.

When I launch Zap:

Uncaught Exception:
Error: Connect Failed
    at ClientReadableStream._emitStatusIfDone (/Applications/Zap.app/Contents/Resources/app.asar/node_modules/grpc/src/client.js:255:19)
    at ClientReadableStream._readsDone (/Applications/Zap.app/Contents/Resources/app.asar/node_modules/grpc/src/client.js:221:8)
    at readCallback (/Applications/Zap.app/Contents/Resources/app.asar/node_modules/grpc/src/client.js:283:12)

What am I missing to get Lightning to run?

To run the wallets you mentioned, you will need to also run a bitcoin node (bitcoind or btcd, most likely), and an lndnode as well. This information is listed in the README files on the pages you linked to.

I believe there are lightning network wallets that work without a local full node, but I don’t have experience with one so you’ll have to dig a bit to find one that works for you. NOTE: without running a node on your machine, you will be trusting someone else’s node in order to use the lightning network.


Bitcoin charts: Moving average or exponential moving average Right now I'm using EMA (exponential) since it lines up with MACD on Trading View. But I have no idea what numbers to use for the fast and slow EMA.  At the moment I'm using 10 and 21 since that's what I heard bots use - so I figured it's better to use what someone else is using for more predictability.

But why 10 and 21, why not 30 or 20 or 100 or 50, etc. Does it matter what chart time is being used? I've been using 1 hour and 15min.

At the end of the Day this is a very trader specific questions. Trading with a moving average system is dependent on the traders preference. If you do not understand the best way you personally should be trading, you are likely setting yourself up for failure from the beginning. I recommend you read "Trading for a Living" Dr. Van K Tharpe

There are hundreds of books written on trading with moving averages. There is no rule that works 100% of the time. 10 and 21 is traditionally used by institutions, but that does not mean you can't be successful with a 20 or 30.

You need to play with a moving average combination that works for you, and your personal trading style. I highly recommend paper trading you strategy before trading live with actual Bitcoin.

The biggest thing you need to figure out, is what type of trader you are, and the frequency of trades you want to be taking. If you are a day trader the 1 and 15 min may be what you need. If you are looking for a trade maybe once a week, the 5 and 10 might work. If you are looking to take trades over the course of weeks, 10 and 20 on daily chart. If you want a few trades a year 50 and 150 daily. Trading all of these time frames, could be over whelming, and just result in losses.

Any moving average combination can be used by any trader provided
1.) They are disciplined in the strategy
2.) Have back tested the strategy
3.) Have appropriate risk management

If you can not explain to someone exactly how your strategy approaches all three of the above points, you need to stop focusing on the moving average pair you are trading, and reevaluate what your trading strategy is.


How much space does a backup of a wallet usually take? I have a Bitcoin QT v0.8.5-beta wallet (downloaded in 2013) which I will backup before trying to export the private keys to a Electrum wallet. I have found a backup button in the QT wallet, but it doesn't describe what the backup leads to.

I have downloaded about 1/15 of the blockchain (224 weeks behind) in the QT wallet, and I have a pendrive with about 2 GB free space that I intend make a backup to. So should there be enough space on the pendrive to take the backup?

Wallet backups are a few megabytes, depending on the number of transactions it has made.


No returns on Genesis Mining contract I bought a 200H/s mining contract at genesis mining. I allocated 100% of my hash power to Monero. It's been days and I have yet to see any return on my investment yet. The graph is just flat and it looks like it's doing nothing.

I signed up last weds,and it's saturday now. Is it too soon to see any activity on this contract? Or do I just not have enough hash power for it to have any effect?

Click on payouts tab and you will see the payouts there. Disregard the graph on dashboard. The graph will populate once you reach payout threshold of .4 xmr...


Bitcoind running in vagrant can't import bootstrap.dat from external directory I am working on a bitcoin development environment in a box, and I've got the bitcoin reference implementation compiling and running so far in this vagrant environment: https://github.com/tlehman/bitcoin-vagrant

Another feature I would like to add is an optional script in /home/vagrant that can download the bootstrap.dat file to speed up downloading the blockchain. My first stab at this problem was to use transmission-cli to download  https://bitcoin.org/bin/blockchain/bootstrap.dat.torrent, and then copy it to ~/.bitcoin/, and then fire up bitcoind for the first time. This works, but it fills up the virtual machine, and it still takes a long time to get imported. On top of that, a vagrant destroy command would blow away all the blockchain data, which is not desirable, I'd like to decouple the data from the program and it's dependencies.

The way I tried to solve this was to mount ~/.bitcoin/ as /vagrant/data/ (which is mounted to a folder in the host filesystem). The problem I am having is that when I run bitcoind -daemon, I get an error saying

Bitcoin server starting
vagrant@precise64:~$ : Error opening block database.

Do you want to rebuild the block database now?

My first guess was that the ~/.bitcoin/bootstrap.dat file was corrupted, but the SHA256 of the file is d05062052be4dd6fbaeac5f17598e52f7ad545f9f938acefaf7067ecce1d7b5a, which matches the SHA256 in the torrent's readme.

My second guess was that LevelDB needs some filesystem feature that isn't present in VirtualBox's synced directories, but I am not sure what that would be.

What can I do to fix this or work around it?

With bitcoind 0.10 (current release candidate) you don't need bootstrap at all anymore as it downloads faster and more efficient than bittorrent would. Bootstrap is probably going to disappear soon. So you might not want to bother at all.


How can I confirm to whom the bitcoin address I sent a payment too? Where can I find out what company is associated to the address I sent a payment too?

You usually cannot.

Bitcoin addresses are not explicitly linked to companies or people, unless they decide to publicize that they own an address (or receive funds from it via a third-party custodian).

There is no directory or listing of who owns which address, although some companies and explorers try to tag major addresses to exchanges etc.

You can attempt to follow the BTC from that address and see if it touches a known address. That might give you a lead as to which company is being used to store/cash out Bitcoin by the company you made the payment to. However, if the company you paid has their own system and doesn't cash out frequently, you won't really find anything actionable.


How does PoW solved in miner.cpp gets transferred to main.cpp in source code? As per my understanding of bitcoin codebase, the following events happen after we solve a proof of work.

In miner.cpp, once the miner thread solves a new Proof-of-work (PoW), ProcessBlockFound basically notifies others via a signal BlockFound.
BlockFound signal calls ResetRequestCount which basically resets the mpRequestCount in wallet.h via the validationInterface.h.
(Missing Logic)
A new NetMsgType::INV is issued from main.cpp in SendMessages/ProcessMessages to all peers.
These messages are eventually dispatched to all peers via network socket logic net.cpp

I am missing the main piece of code logic between step2 and step4. Can any expert help me understand what background story is happening after step2?

If you read a few lines after the BlockFound signal, you'll see:

CValidationState state;
if (!ProcessNewBlock(state, chainparams, NULL, pblock, true, NULL))
    return error("BitcoinMiner: ProcessNewBlock, block not accepted");

https://github.com/bitcoin/bitcoin/blob/v0.12.0rc2/src/miner.cpp#L373-L375

This is where the processing actually starts. ProcessNewBlock is defined in main.cpp.


What is the official website for Bitcoin? What is the official website for bitcoin? bitcoin.com or bitcoin.org
Are other websites linked to bitcoin? What about bitcoin.info, bitcoin.help, crypto.com, blockchain.com?

There is no official website for Bitcoin. Every website mentioned in the question is either managed by an individual or a company with their bias, opinion, products, services etc.


Find all used addresses using xpub key I currently use a Ledger wallet and find it a hassle to plug it in every time I want to check my balance.

I have access to my master xpub key, how would I find out all the addresses corresponding to it? Is there any site that hosts this service and has an API?

I found a script online that does this, but it's written in PHP and is quite slow. I'm looking for something compatible with python.

You can use blockonomics, its pretty fast. It also has API to give balance of given xpub.

If you don't want to submit your xpub to server you can use https://github.com/dan-da/hd-wallet-addrs. This will select random balance API service for each address and do HD walkthrough.

Added example code using blockr api, fetches balances for 20 addreses at once, should be pretty fast

import pycoin.key
import sys
import os
os.environ["PYCOIN_NATIVE"]="openssl"
import requests
BATCH_SIZE = 20
BLOCKR_URL= "http://btc.blockr.io/api/v1/address/info"
def get_used_addresses(xpub, account_type):
  xpub_subkey = xpub.subkey(account_type)
  index = 0
  addr_batch = []
  output = []
  while True:
    addr = xpub_subkey.subkey(index).bitcoin_address()
    addr_batch.append(addr)
    if (index+1)%BATCH_SIZE==0:
      results = requests.get("{}/{}".format(BLOCKR_URL, ",".join(addr_batch))).json()
      addr_batch = []
      used_addrs = [x["address"] for x in results['data'] if not x["is_unknown"]]
      if (used_addrs):
        output.extend(used_addrs)
      else:
        break
    index += 1
  return output

def main():
  xpub = pycoin.key.Key.from_text(sys.argv[1])
  result = []
  result.extend(get_used_addresses(xpub, 0))
  result.extend(get_used_addresses(xpub, 1))
  print result

if __name__ == "__main__":
  main()


What are the mining spec differences between Bitcoin and Litecoin? Obviously, Litecoin mining requires less computational power as it it more CPU friendly, but does this mean that if you switch a GPU Bitcoin miner To Litecoin mining you will be wasting your resources?

Primarily the differences between Litecoin and Bitcoin are reduced block generation time and use of scrypt in place of SHA256.

It's not the Litecoin requires less power as much as the difficulty rate is much lower due to less mining power. Bitcoins used to be mined on CPUs, but the introduction of GPU mining essentially put that to an end.


ASICs and large memory requirements People keep saying that proof of work functions like scrypt prevent ASICs from working because of large memory requirements.

What's stopping ASIC designers from simply building ones that have lots of memory?

Theoretically, you could produce an ASIC for every possible algorithm. It's done all the time by NSA, CIA and their kind for cryptographic purposes. Why has no company produced an ASIC for scrypt or to look for Cunningham chains? Return of investment!

Developing an ASIC for scrypt is harder than for SHA-256, this is by design. So designing the electronics is going to be costly, producing and testing the first test batches is going to be expensive as well.

For such a project to be done commercially, either: a) investors see a potentially big market of buyers for such an ASIC, or b) they sense a big investment opportunity in creating such machines for mining themselves a scrpyt-based coin.

For both situations to happen, scrypt-based crypto-coins need to become more popular/used, or their market capitalization increased substantially. Now that Litecoin has become much more high-profile (and its market capitalization a big chunk), and with Dogecoin, Coinye and so many other scrypt-based coins hitting the news, that there's a lot of interest in designing an ASIC for scrypt.

What surprises me is not seeing a team of teachers/students at any college in the world designing the electronics, getting a grant to create a few batches and finally either publicly releasing the gerbers or raising seed-capital to start a company based on the effort. I've seen a number of companies start up like this, have no idea why no one has tried it.


What means "messege" in the bitcoin blockchain? [elliptic curve cryptography] I am stuck with one question in my research.
I found some mentions that bitcoin(or blockchain) is a messeging system, I played with couple curve encoding algorithms and it was like:

Curve params, priv key, pub key or coordinates + messege = signature.

Its easy to read about it but I stuck to figure out what "messege" is in the bitcoin blockchain info?
How this related to tx hashes? tx amount? what actually we encoding during the transaction and how to get this input/outut in readable format.

Thanks

The signed message will be some portion of a Bitcoin transaction.  The Bitcoin code has specific rules for what the signed message needs to be.  The signed message needs to include any data that you don't want to be modifiable by a third party, so it should include all the output addresses/scripts and the Bitcoin amounts being sent to those outputs.  The message cannot be the entire transaction, because the transaction includes the signature itself (before segwit came along) and the signature cannot sign itself.  I don't know the exact details, but you can read up on the Bitcoin transaction format to learn more.


Why is the Bitcoin blockchain designed so that a block can be unconfirmed? I have a basic question about blockchain and Bitcoin.  After a transaction is confirmed and included in a  block, it is said to have a depth (confirmation) of one.  However I've read that many companies require "multiple" confirmations (up to 6) before they consider a transaction truly confirmed.  Does that mean that a block taht is confirmed can be revoked, thus nullifying the previously confirmed transaction?  What purpose would such a behavior serve -- in other words, once a transaction is confirmed and a block is formed, what advantage is there to later "unconfirmed" taht block?

Every Bitcoin node creates it's own blockchain. When a new block is found, it is broadcasted to the network. Other nodes will only consider the highest blockchain as being the "real" blockchain.

Sometimes, two separate nodes build a block containing different transactions. Two competing blockchains now exist, it is now a race for the next block. Once the next block is found, we can reject the other inferior chain. But if that inferior blockchain manages to get two new blocks, it will be broadcasted again as the main one.

To avoid having a transaction that was once in a block, but it got replaced, we simply state how many blocks happened since the transaction as confirmations. After 6 confirmation it's considered almost impossible to alter, so we just say it's confirmed.


Can multiple people create one multisignature address, while keeping their private keys private? Is it possible for person A, person B, and person C to create a multiple signature address without one person needing to initially know all three addresses to create that public address in the first place?

Ideally 5 people somehow create an address together, maybe passing it on to each other? But only if 3 out of those 5 private keys are used, can money be gotten out of that wallet?

You need the public addresses of all persons involved in order to create the multi-sig address. So if you are creating a 3 of 5 multi-sig address you need all 5 public address.  In order to retrieve funds from that address you need signatures from 3 of the 5 people (or however many signatures you require). Check out this example here, which was a huge help for me.

bitrated.com and https://coinb.in/multisig/ have open source implementations of this as well.


How much time does it take for the bitcoin-qt window to show up in OS X 10.4? I have downloaded Bitcoin-Qt for Mac yesterday. I understand that it takes a while to "synchronise" but this site says one can access it whilst this process takes place. I have the Bitcoin in my applications folder but when I click on the icon nothing happens. A friend says he could monitor the progress of the synch, I can't see anything. What am I doing wrong?

When you open the Mac client, it first displays the loading screen for a while :

After that it displays the main screen and starts synchronizing :

Note that the client is really slow and might take a while to load. If it's still not displaying the loading screen after a minute, try opening it again. As far as I know the Mac client doesn't have any requirements for installation.

To diagnose the issue, please perform these steps :

Go to Activity Monitor (it's in the Utilities folder) and see if Bitcoin-qt is running. It should be.
Open Console (also in Utilities) and see if there are any errors about Bitcoin-qt.
Restart your Mac. It may help.


Blockchain.info customer service Anyone know the the blockchain.com direct/ live customer service? I had submit several request with same problem , what i get is only the standard answer from blockchain.com which i feel is total nonsense.

Long story short , there is a transaction d69c2c14897a516917932f0ed0c2e04ed0380c63709d103d66541e6c77e34406 which shall be already confirmed, but blockchain.info shows unconfirmed transaction and the BTC cant be credit which the wallet also belong to blockchain.com. Therefore need help on the live/ real customer service.

Below are the standard template i get as reply.

  Friday at 12:28
  Please check transaction d69c2c14897a516917932f0ed0c2e04ed0380c63709d103d66541e6c77e34406.
  By using other platform ( at least 3 ) this transaction had been confirmed but not on blockchain.info. Unfortunately the 0.2 yet to debit in to 18hBv8j15E4iDJ7V7pKKiJN4hGvyRZCvkb wallet, it was suppose to as the transaction had been confirmed.

  confirmation 2.JPG (60 KB)
   confirmation 1.JPG (70 KB)
  Avatar
  Tanya

  Saturday at 07:10
  Hello,

  I'm sorry to hear about this trouble you're having. I can give you a little more information on how transaction confirmations work. An unconfirmed transaction will eventually either be accepted into a block by a mining pool and confirmed. Or it will be rejected by the network, if not rebroadcast, usually within 7 days. If it eventually is rejected, don't worry, the funds will remain on the address they were sent from. At this point, we can only recommend that you wait to see if your transaction is accepted into a block.

  Like all wallet providers, Blockchain has no control over the speed of confirmation, and unfortunately cannot expedite transactions. This is always dependent upon the network of miners.

  We do everything we can to lessen the number of pending transactions. For this reason, your Blockchain wallet utilizes dynamic bitcoin fees that are dependent upon current network conditions. To learn more about how this works read our blog here: https://blog.blockchain.com/2016/03/16/introducing-dynamic-fees/.

I realize this question was asked a few years ago, but for anyone else with a similar issue: If your wallet isn't working the way you want it to, just create another wallet using a different service. There's no reason you need to get them to fix anything unless you want them to. They aren't stopping you from transferring your funds because they have no control over your funds.

Always make sure you have your private keys or seed saved securely somewhere in case your wallet disappears or breaks in some way. That way, you can set up a new wallet to access the very same funds any time that becomes necessary.


Problem to link to libsecp256k1 on ARM architecture Trying to compile with g++ -o addr 69_addr2.cpp $(pkg-config --cflags --libs libbitcoin) is getting me this error:

/usr/bin/ld: /home/pi/libbitcoininstall/lib/libsecp256k1.a(libsecp256k1_la-secp256k1.o): in function `secp256k1_num_mod_inverse':
/home/pi/GitBen/LibbitcoinBen/build-libbitcoin/secp256k1/src/num_gmp_impl.h:128: undefined reference to `__gmpn_gcdext'
/usr/bin/ld: /home/pi/libbitcoininstall/lib/libsecp256k1.a(libsecp256k1_la-secp256k1.o): in function `__gmpn_sub':
/usr/include/arm-linux-gnueabihf/gmp.h:2190: undefined reference to `__gmpn_sub_n'
/usr/bin/ld: /home/pi/libbitcoininstall/lib/libsecp256k1.a(libsecp256k1_la-secp256k1.o): in function `secp256k1_num_set_bin':
/home/pi/GitBen/LibbitcoinBen/build-libbitcoin/secp256k1/src/num_gmp_impl.h:49: undefined reference to `__gmpn_set_str'
/usr/bin/ld: /home/pi/GitBen/LibbitcoinBen/build-libbitcoin/secp256k1/src/num_gmp_impl.h:49: undefined reference to `__gmpn_set_str'
/usr/bin/ld: /home/pi/libbitcoininstall/lib/libsecp256k1.a(libsecp256k1_la-secp256k1.o): in function `secp256k1_num_get_bin':
/home/pi/GitBen/LibbitcoinBen/build-libbitcoin/secp256k1/src/num_gmp_impl.h:34: undefined reference to `__gmpn_get_str'
/usr/bin/ld: /home/pi/libbitcoininstall/lib/libsecp256k1.a(libsecp256k1_la-secp256k1.o): in function `secp256k1_num_set_bin':
/home/pi/GitBen/LibbitcoinBen/build-libbitcoin/secp256k1/src/num_gmp_impl.h:49: undefined reference to `__gmpn_set_str'
/usr/bin/ld: /home/pi/GitBen/LibbitcoinBen/build-libbitcoin/secp256k1/src/num_gmp_impl.h:49: undefined reference to `__gmpn_set_str'
/usr/bin/ld: /home/pi/libbitcoininstall/lib/libsecp256k1.a(libsecp256k1_la-secp256k1.o): in function `secp256k1_num_get_bin':
/home/pi/GitBen/LibbitcoinBen/build-libbitcoin/secp256k1/src/num_gmp_impl.h:34: undefined reference to `__gmpn_get_str'
collect2: error: ld returned 1 exit status

Why is there a reference to the build-libbitcoin directory?

I installed libbitcoin in /home/pi/libbitcoininstall and the other directory is just the git where the automatic install script placed all the files.

So, this process should be finished. Why do I even get a print with that directory?

The installation went without error.

I am doing this on a Raspberry (should it matter?)

The small program I try to compile is from a textbook:

#include <bitcoin/bitcoin.hpp>

int main()
{
  bc::ec_secret secret;
  bool success = bc::decode_base16(secret,"038109007313a5807b2eccc082c8c3fbb988a973cacf1a7df9ce725c31v14776");
  assert(success);

  bc::ec_point public_key = bc::secret_to_public_key(secret);
  std::cout << "Public key: " << bc::encode_hex(public_key) << std::endl;

  const bc::short_hash hash = bc::bitcoin_short_hash(public_key);

  bc::data_chunk unencoded_address;
  unencoded_address.reserve(25);
  unencoded_address.push_back(0);
  bc::extend_data(unencoded_address, hash);
  bc::append_checksum(unencoded_address);
  assert(unencoded_address.size() == 25);
  const std::string address = bc::encode_base58(unencoded_address);

  std::cout << "Address: " << address << std::endl;
  return 0;
}

It seems like pkg-config found libsecp256k1 in the build-libbitcoin directory. which is part of libbitcoin, so they probably build libsecp25k61 there.

The reason your code doesn't compile is because your libsecp was compiled with libgmp enabled, now this is a dynamic link.
So if you're trying to create a binary here you need to add -lgmp and if it's not in your system libs you'll need to also give a location to the .so file

Another option would be to recompile libsecp with libgmp linking disabled.


where is bcc in electron cache has electron cache 2 history pages: bitcoins and bcc?
in a youtube video I see only one history page with a sending and receiving tab: what is this:bitcoins or bcc?
I want to start a wallet with 0 bitcoins and 1 bcc via a seed of an old blockchain.info wallet.

First of all, your BCC balance won't be shown in Electrum, Electrum shows only the BTC balance.

But there's a changed version of Electrum that supports BCC, Electron Cash (NOT Electrum Cash), and that one doesn't show the BTC balance.

Guess which one is Electron Cash, which one is Electrum!

Here are their icons, the one on the left is Electrum, the other one is Electron Cash


Multisig address with a specific required signature Is it possible to create a multisig address such that it has 3 public keys attached, needs 2 signatures to create a transaction, but one of the signatures must be from a specific public key of the 3? If so, how?

redeem:

<pubkey3> OP_CHECKSIGVERIFY OP_1 <pubkey1> <pubkey2> OP_2 OP_CHECKMULTISIG

scriptSig:

OP_FALSE <sig1> <sig3> <redeem>

or

OP_FALSE <sig2> <sig3> <redeem>


Passphrase requirement for old version of QT wallet I have an old wallet.dat file which was encrypted in October 2012. I don't have the exact passphrase but I have a rough idea. I was wondering if anyone knows how to get the passphrase requirement for this specific version (it would help with my guessing). I looked through the source code for Bitcoin-Qt version 0.7.0 and 0.7.1 but all I was able to find was this

  ui->warningLabel->setText(tr("Enter the new passphrase to the
  wallet.Please use a passphrase of 10 or more random
  characters, or eight or more words."));

Which is line 33 of askpassphrasedialog.cpp file. I don't think this is a strict requirement for the passphrase although it helps. I would like to see the code which sets the passphrase requirement if possible. Any help would be greatly appreciated!

p.s. Does anyone know if it is possible to decrypt an old wallet without downloading the entire blockchain?

I went through more files and it looks like only the guideline exists for the passphrase. The passphrase requirement of 10 or more random characters or eight or more words were not strictly enforced. Just in case other people were looking for the same information.


How do I run two instances of bitcoind on the same linux machine with different conf files? I want to run two instances of bitcoind on my machine.

I know my bitcoin.conf file is in ./bitcoin/bitcoin.conf, and I know (thanks to this thread) that I need to change my .conf file to point to different data dirs and RPC ports, etc.

However there is only one .conf file.

How do I go about pointing my second bitcoind instance to a new bitcoin.conf file? I copied the directory with the compiled code to a new directory, I am making the assumption that compiled code can be copied into another directory and it will work without problems.

Change the -datadir flag to a new absolute location. Each instance will follow the bitcoind.conf in their respective directory.


What is the relationship of the Lightning Network and the Bitcoin protocol? Is Lightning running on the Bitcoin protocol or on another blockchain?
Is is something like a sidechain?
Where are the bitcoins in the Lightning Network stored?

Is lightning running on the bitcoin protocol or another blockchain?

The Lightning Network operates on the Bitcoin blockchain. However it has its own network protocols and protocols with transactions. It merely uses Bitcoin transactions.

The Lightning Network can be ported to different blockchains so long as they support a similar feature set to the Bitcoin blockchain. For example, the Lightning Network has been successfully used on Litecoin too.

  Is is something like Sidechain?

The Lightning Network is not a sidechain.

  Where bitcoins in network are stored?

They are in transactions, just like everywhere else. There is no such an object as a Bitcoin. Rather a "Bitcoin" is just a value in an unspent transaction output. Those exist on the blockchain. When using the Lightning Network, the Unspent Transaction Outputs for your Bitcoin are still on the blockchain. The main concept of the Lightning Network is that the transactions that spend those UTXOs are not broadcast to the Bitcoin network immediately but rather kept private between two parties who are transacting with each other. It is only broadcast when the two parties no longer wish to transact with each other.


Difference between block hash and transaction hash in bitcoin-core Is there a logic based on which one can determine if a given 32-bit hash corresponds to a transaction or a block without enquiring a bitcoin-client?

In other words, how do I differentiate or validate a given 32-bit hash as a transaction or block identifier?

I understand, that a valid block hash is restricted by the difficulty limits (that offer lower and upper bounds). Is there something similar to validate a transaction hash?
Reference: How is difficulty stored in blocks?

This is not possible, both are sha256 hashes, and contain no markers as to their origin.


Copay wallet no longer available on the Google Play store This URL where the Copay wallet used to be now just shows "We're sorry, the requested URL was not found on this server." Why was it removed? Was there a security issue? Is this going to affect the app installed on my phone?

In early September, Google removed Copay and a number of other Bitcoin wallet apps from the Play Store. I don't think we know why exactly those apps were removed, but things like that do seem to happen from time to time in the crypto world. More recently (late November), it was revealed that a hacker had managed to inject code into Copay that could steal users' wallets. I don't think those two events were related, but if you have funds stored using Copay I'd definitely recommend taking steps to make sure that your version of the software does not have the vulnerability. See here and/or contact BitPay support for more information.


How do payment processors like bitpay work? How do payment processors like bitpay work?
As far as i understood you can only have one address per key pair, so do they generate a whole new pair for every payment? Or can this be done using HDWallets?

They generate a private key and an address corresponding to that private key everytime you see BitPay's payment page (even if you don't pay they keep the private key and that private key is generated only for one payment). When they receive payment to that address, they send your money from that address to their main wallet.


Bitcoin transaction confirmed and spend but not funds recieved Transaction id
2d581849f11fd34a7d82a6913f78eaf19802bcd0c20aca5905f0d9aeab5f0832

Can someone plz advise what's the status

As per the transaction id you have given, you can see the status here:

https://blockchain.info/tx/2d581849f11fd34a7d82a6913f78eaf19802bcd0c20aca5905f0d9aeab5f0832

And you can see that the transaction is complete, infact you have used the funds already.


"Restore" addresses with the privat key I have a very simple question, but didn't find a answer with google.

When i backup only my private key, it is possible to restore my addresses with bitcoins on it?

Example: I have generated 1.000 address not in the Client. Then some one sent 3 BTC to one of these addresses. Get the Bitcoin-Client the address with the 3 BTC automatically or only when i import the address?

Wait...
One private key <=> one address.
You can restore by import privkey to bitcoind.


After last bitcoin is mined, can miner(s) with nefarious reasons kill bitcoin by holding fees thereby deflating Bitcoin eventually to zero? Just hypothetically speaking, once there is no more rewards and we transition entirely into transaction fee regime, if a miner (or group of miners) with unlimited supply of electricity, computing resources and sole intention to kill bitcoin decides to mine and hold up all the fees they collect and never again releasing those fees back into circulation (they have other means to pay their expenses and their primary goal is to kill bitcoin), wouldn't eventually they end up with all the bitcoin ?

This would be fantastic for everyone but the attacker.

First, everyone who held bitcoin would be rich. As bitcoin became more and more scarce, the price would go up. The attacker would have to offer full value for every bitcoin it managed to acquire, so it's no different from an attack where you buy all the bitcoins.

However, as the distribution becomes more and more skewed, the value of bitcoin will eventually crash because people couldn't get it.

Once that happens, everyone who likes to use bitcoin for payments or as a store of value, now all fantastically rich, would simply migrate to a different system. The attacker would have bought every bitcoin all the way up the rise in price.

Of course, this would be so obvious to all involved (at least eventually) that it would never get this far. Whether the result would be changing the mining algorithm, restoring the block reward, or something else, I can't predict. But likely the mere threat of changing the mining algorithm would be sufficient to end this.

A related, but more realistic, attack involves someone with 51% of the mining power taking all the transaction fees for themselves by refusing to mine on top of blocks mined by anyone else. As a monopolist, they could increase the transaction fees to as much as the "market" would bear. This faces the same problem -- everyone else can threaten to change the mining algorithm. If decentralization is the value proposition, such a chain would have no value proposition -- so why would anyone pay high fees to use it?


How to create a brainwallet with bitcoinjs? This is how to create a brainwallet with bitcore

const Bitcore = require("bitcore-lib");
// const Mnemonic = require("bitcore-mnemonic");
// https://bitcore.io/api/lib/crypto
let brainsrc= 'satoshi'
let input = new Buffer(brainsrc)
let hash = Bitcore.crypto.Hash.sha256(input)
let bn = Bitcore.crypto.BN.fromBuffer(hash)
let pk = new Bitcore.PrivateKey(bn).toWIF()
let addy = new Bitcore.PrivateKey(bn).toAddress();
console.log('The brain wallet of '+brainsrc+' \nAddress: '+addy,' Private key:'+pk)

For bitcoinjs, I only know how to create random address:

// https://github.com/bitcoinjs/bitcoinjs-lib/blob/v3.3.2/test/integration/addresses.js

const bitcoin = require('bitcoinjs-lib')
var keyPair = bitcoin.ECPair.makeRandom()
var secret = (keyPair.toWIF())
var addr = (keyPair.getAddress())

console.log('The brain wallet of '+brainsrc+' \nAddress: '+addr,' Private key:'+secret)

How to do it?

First of all, don't use 1 word seeds, that will be too easy to brute force...

index.js

const bitcoin = require('bitcoinjs-lib')

const brainsrc = 'satoshi'
const hash = bitcoin.crypto.sha256(Buffer.from(brainsrc))
const keyPair = bitcoin.ECPair.fromPrivateKey(hash)
const addr = bitcoin.payments.p2pkh({ pubkey: keyPair.publicKey }).address
const secret = keyPair.toWIF()

console.log('The brain wallet of '+brainsrc+' \nAddress: '+addr,' Private key:'+secret)

output:

$ node index.js
The brain wallet of satoshi
Address: 1xm4vFerV3pSgvBFkyzLgT1Ew3HQYrS1V  Private key:L4XnHhvLC1b4ag9L2PM9kRicQxUoYT1Q36PQ21YtLNkrAdWZNos6

Examples can be found on the git repo: https://github.com/bitcoinjs/bitcoinjs-lib#examples


Won't DNS records reveal who Satoshi is? Fine, we don't know who he is. I get that. But he did register bitcoin.org, and as a result had to use a credit card. So the original domain registrar must know who he is, no?

Assuming that Satoshi himself registered the domain with his or her own personal information, and/or used a credit card tied to his or her real name, then it is likely that the registrar maybe have knowledge of the real identity.

HOWEVER,

It is not known if Satoshi used his or her real name to register.
It is not known if Satoshi used his or her personal payment information when registering.
It is unlikely that a registrar that specializes in privacy would ever divulge the above information or even its existence without a court order.
It is possible that the registrar may not have retained records dating back to then, so it is possible that the above information was known but is no longer retrievable.

DNSHistory.org began tracking bitcoin.org in early 2011, well after Satoshi exited. It does not track registrant information. WhoisRequest.org tracks NS back to September 2008, but only tracks nameserver changes. Who.is yields the known fact that the domain was registered with the AnonymousSpeech registrar and the registrant information as DigiRock, a Japanese domain registrar and hosting provider. This was likely a proxy registration.


Merchant address re-use? I understand that one way a merchant would likely use Bitcoin is to create a unique receipt address for every customer, so when a given address receives payment, the merchant can know exactly which customer sent in payment.

Ideally, these addresses would get used one time, and then thrown away.
But the world isn't an ideal place, and customers sometimes (frequently) make mistakes.

To prevent Bitcoin loss, would a merchant need to keep every address (and associated private key) forever?  Doesn't that become burdensome?

To prevent Bitcoin loss, would a merchant need to keep every address (and associated private key) forever?

Yes.

  Doesn't that become burdensome?

Not really. First of all, private keys and addresses are fairly small, so they don't take up that much space. Putting them into a database can make access very quick and easy so that's not much of a problem. Furthermore, merchants already have to keep the private keys around in order to spend the coins from those addresses later. It is uneconomical for them to immediately forward the funds to some other storage address as they will incur transaction fees for doing so.


How can I do CPU mining on testnet? I'm trying to do cpu mining on testnet to debug coinbase transactions in my application.

Tried running GUI miner, I get the below output:

2014-07-31 11:31:51: Running command: poclbm.exe testnetuser:test123456@localhost:18332 --device=0 --platform=0 --verbose -r1
2014-07-31 11:31:51: Listener for "Default" started
2014-07-31 11:31:53: Listener for "Default": No PyOpenCL
2014-07-31 11:31:53: Listener for "Default": Not using OpenCL
2014-07-31 11:31:53: Listener for "Default": Nothing to mine on, exiting

I tried UFASoft miner, set the listening port to 18332 but nothing happens.

What is the easiest way to do cpu mining on testnet?

Is there another way of getting coinbase transactions in my testnet wallet?

Even on testnet the difficulty is sufficiently high that it will take you a long time to mine anything using cpu. (Lots of people testing ASICs, presumably.)

Your best bet is probably Testnet in a box. Then you can cpu mine just by using ´setgenerate true´ in Bitcoin Core.


How did these 3 tx make it into a block in the main chain? http://blockexplorer.com/block/000000000000051b42fd09195c75da7a084df7593f47ad18139cdc9cd83a112e

The last three tx have a inputs with script_sig "1".  This is invalid right?

According to protocol rules https://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messages it seems like the block (even if mined) should have been rejected by peers.

  16.1.4: "Verify crypto signatures for each input; reject if any are bad"

What am I missing?  Thanks!

The script page of the bitcoin wiki tells us that:

A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero)

To validate a transaction's input, first the input's scriptSig is run, then the scriptPubKey of the output it's trying to spend is run.

The transactions in question have a scriptSig of '1' and the outputs they're spending have a  scriptPubKey of OP_DUP OP_DUP OP_DUP.  Running these will cause a '1' to be put onto the stack, and then for the '1' to be copied three times, ending up with a stack of: [1, 1, 1, 1].  The top stack item is non-zero, so it's fine.

To address your question about crypto signatures, while it's true that any OP_CHECKSIG in either script has to pass there was none in these scripts, so none of them were bad.

The current version of the client rejects "non standard" scriptPubKey scripts in the individual transactions that it receives from the network, and refuses to pass them on, but doesn't appear to do the same for transactions in already-mined blocks that it receives.  So this block was likely mined by the person who made this transaction, using custom software.

Anybody seeing those outputs could have immediately claimed them.  Note however that these easily-redeemed outputs were created and redeemed in the same block, leaving no risk of someone else redeeming them.


If I offer a higher transaction fee, will my order get processed faster? I was reading the wiki and it seemed to sugest that the transaction fees didn't play to much of a role in determining the priority of an order but rather the actual size in bytes and the previous amount of wait time are used.

  priority = sum( input_value_in_base_units * input_age ) / size_in_bytes

but if I was a miner and I had the choice between two orders of equal size, I would always pick the one that offered the higher fee.

So for all of you miners out there, would my orders on average get processed faster?

Also it could just be that the current mining software does not discriminate based on fee size, but is it possible to write a miner which does?

DannyHamilton from bitcointalk says

At a minimum.  0.0001 BTC per kilobyte.  That would put you ahead of all transactions that are considered "low priority" which don't include a fee by all miners (and pools) that choose to use the reference implementation.
Given how low the exchange rate has been lately, you might even consider a fee of 0.0005 BTC per kilobyte.  This would put your transaction ahead of everyone that is using the 0.8.3 reference implementation for fee calculation and even with everyone using the older versions.  At the moment this works out to about 3.5 cents for an average transaction.

So the answer is yes, offering a higher transaction fee does speed up your transaction. Heres a link to the bitcointalk discussion.


Does blockchain.info wallet or mycelium wallet use Bitcoin core? And if so what version? I am asking because on a website it was talking about invalid blocks and how you should have a newer version of bitcoin core for some reason.
https://bitcoin.org/en/alert/2015-07-04-spv-mining

When you use Mycelium you're not running a node on your phone. Instead they run a few Mycelium servers, which include Bitcoin core nodes. They will have updated by now (probably around the date of this alert).

Blockchain.info is notorious for running old or non-standard node software causing all kinds of corruptions in their block explorer, but also sometimes in their wallets. But even for them I'd be surprised if they haven't updated by now.

In general this alert is only still applicable if you're running your own node with one of the old versions mentioned.


Nonce usage in ECDSA signing algorithm I'm trying to understand the signing function secp256k1_ecdsa_sig_sign(), and I'm curious about the nonce usage here.

static int secp256k1_ecdsa_sig_sign(const secp256k1_ecmult_gen_context *ctx, secp256k1_scalar *sigr, secp256k1_scalar *sigs, const secp256k1_scalar *seckey, const secp256k1_scalar *message, const secp256k1_scalar *nonce, int *recid) {
  unsigned char b[32];
  secp256k1_gej rp;
  secp256k1_ge r;
  secp256k1_scalar n;
  int overflow = 0;

  secp256k1_ecmult_gen(ctx, &rp, nonce);
  secp256k1_ge_set_gej(&r, &rp);
  secp256k1_fe_normalize(&r.x);
  secp256k1_fe_normalize(&r.y);
  secp256k1_fe_get_b32(b, &r.x);
  secp256k1_scalar_set_b32(sigr, b, &overflow);
  /* These two conditions should be checked before calling */
  VERIFY_CHECK(!secp256k1_scalar_is_zero(sigr));
  VERIFY_CHECK(overflow == 0);

  if (recid) {
    /* The overflow condition is cryptographically unreachable as hitting   it requires finding the discrete log
     * of some P where P.x >= order, and only 1 in about 2^127 points meet this criteria.
     */
     *recid = (overflow ? 2 : 0) | (secp256k1_fe_is_odd(&r.y) ? 1 : 0);
  }
  secp256k1_scalar_mul(&n, sigr, seckey);
  secp256k1_scalar_add(&n, &n, message);
  secp256k1_scalar_inverse(sigs, nonce);
  secp256k1_scalar_mul(sigs, sigs, &n);
  secp256k1_scalar_clear(&n);
  secp256k1_gej_clear(&rp);
  secp256k1_ge_clear(&r);

  if (secp256k1_scalar_is_zero(sigs)) {
    return 0;
  }

  if (secp256k1_scalar_is_high(sigs)) {
    secp256k1_scalar_negate(sigs, sigs);

    if (recid) {
      *recid ^= 1;
    }

  }

  return 1;
}

I'm familiar with the standard ECDSA, but what exactly is being done with the nonce here and why?

Thanks!

Answered by Pieter Wuille in comments:

  That's just ECDSA. The nonce is the randomness for the signature, and has nothing to do with the message being signed. An ECDSA signature is a pair (r,s) where r is the X coordinate of kG, and s = (m+r*x)/k (where k=nonce, m=message hash, x=private key, G=curve generator).


Does bitcoin.conf expand environment variables? I would like to store my Bitcoin RPC passwords and usernames in environment variables, like:

rpcuser=$RPC_USER
rpcpassword=$RPC_PASSWORD

Is this supported in bitcoin core? Can environmental variables be parsed from my bitcoin.conf file?

No, bitcoin core does not expand environment variables in bitcoin.conf.

See here to see how options are parsed.

You can expand environment variables as arguments for bitcoind:

$ bitcoind -rpcuser="$RPC_USERNAME" -rpcpassword="$RPC_PASSWORD"


why did blockchain.info misstate the value of this transaction Here is a transaction to SatoshiDice for 0.01 BTC:

But examine the corresponding entry in blockchain.info:

They think this:

Total Input 0.01974 BTC
Total Output 0.01973 BTC

But that is innacurate!

it's acually:

Total Input 0.011 BTC
Total Output 0.010 BTC

Why can't they (blockchain.info) see that while SatoshiDice can?

Is it because the transaction is at this point still unconfirmed?

The input and output totals claimed by blockchain.info are correct.  But the BTC 0.00973 output is presumably going back to another address owned by your wallet, as change.  Blockchain.info has no way of knowing which output is the "real" destination and which is the change, so it reports the total of both.

SatoshiDice knows which of the two outputs was sent to it (because it controls that address and not the other one).  So they only report the amount that actually went to them.

This has nothing to do with whether or not the transaction is confirmed.


What concerns arise from the heavy miner concentration in China? As per an Business Insider article last year, approximately 73% of the hash power comes from China. Over 50% just by the top 3. If coordinated, they could cause havoc. Is that a concern to anyone?

I do not think it is not as simple as having 51% of the Hash power, and immediately causing "havoc".

The power of more than 51% of the Hash power comes from the ability to create an alternate chain of greater difficulty than the public chain.

A Secret Pool that has more Hashing Power than all the known transactions could be working on a fork in secret, and could unveil that forked blockchain at some point, declaring it to be the "one true chain".  This could create double-spends, and reverse earlier transactions, and otherwise cause chaos.

But the other miners would have to accept this mysterious, much longer chain that suddenly appeared.  That seems unlikely.

We know that forks and orphan blocks are part of the mining process, and maybe could even deal with a forked chain of 4 or 6 blocks.  But if a mysterious blockchain suddenly appeared that was at serious odds with the public chain (dozens or hundreds of blocks long), everyone involved would very likely reject it.   The rogue miners would then have invested substantial hash power, costs, and opportunity cost for a chain that ultimately may get rejected.

I'm not saying its an entirely impossible attack. But such an attack would have a substantial risk of failure.  It's much easier and less risky for someone with that much hashing power to just earn an honest living through honest mining.

As long as the Chinese Miners are regularly submitting blocks to the public chain, we can be reasonably confident they are not working on another forked blockchain in secret.


Verifying old blocks I have a question about an implementation detail - when are old blocks verified by each full node? I.e. when will I be "caught" if I change the contents of an old block (and thus break the hash chain)

From what I've seen, the possible answers include: when it's downloaded and when you do a -rescan.

However, does a full node regularly verify the integrity of the chain from start to finish?

(I'm aware that changing the history on my node doesn't do any good, as those verifying my future transactions will have the correct chain and thus refuse any attempts to double spend)

when are old blocks verified by each full node?

never unless rescan=1 command-line option passed to

  From what I've seen, the possible answers include: when it's downloaded and when you do a -rescan.

yes, on downloading also of course

one of my .dat files is broken (some garbage in contents) but bitcoin-qt works well because it uses UTXO, not blocks themselves

  if I change the contents of an old block (and thus break the hash chain)

this depends what do you mean.


What happens if a transfer is made to a unused address from the keypool? The bitcoin-qt client generates 100 addresses from the start. But they are not shown in the "receive"-list (only one).

If I export such address with pywallet and send something to it. Will it be recognized?

As long as the key is mathematically valid, which it will be, then it will be recognized.  The blockchain simply keeps track that someone sent coins to that address. It doesn't need to know anything else about it--the address isn't "registered" somewhere in advance Your wallet will contain the private key for that address which means that you will be the only one able to receive and spend the bitcoins which belong to that address.


How nodes solve cryptographic hash by random guesses in bitcoin network I searched for a lot. Previous answers on the bitcoin stack exchange did not answer my question.
Well, According to my research, Any node can collect a set up unconfirmed transactions into a block and broadcast to the rest of the network as a suggestion for what the next block in the chain should be, by solving the cryptographic hash by random guesses. Moreover, the hash function creates something like a 32byte number might be using SHA256. So, I want to know who creates random numbers? and how nodes do guessing?
Please let me know if my concept is wrong. I will appreciate your guidance. Thanks

Moreover, the hash function creates something like a 32byte number might be using SHA256. So, I want to know who creates random numbers? and how nodes do guessing?

It's a 32-bit number. There are only 2^32 possible values for a 32-bit number, about 4 billion, and realistic bitcoin mining hardware attempts trillions of hashes per second. So miners are just designed to try all of them which typically takes much less than a second.
Of course, the odds of any of them producing a valid block are very close to zero, given that only one miner succeeds on average every ten minutes. So the vast majority of blocks that miners attempt to mine turn out to be unmineable and the miner must try all 2^32 possibilities on a different block.


Bitcoin full node installation on Raspberry Pi3 not working I'm trying to setup a Bitcoin full node including GUI & wallet based on guide on raspnode.com but I got stuck at the this point:

'i@raspnode~/bin/bitcoin$ make -j2'

having this error:

Making all in src
make[1]: Entering directory '/home/pi/bin/bitcoin/src'
make[2]: Entering directory '/home/pi/bin/bitcoin/src'
  CXX      bitcoind-bitcoind.o
make[3]: Entering directory '/home/pi/bin/bitcoin/src/secp256k1'
make[3]: Leaving directory '/home/pi/bin/bitcoin/src/secp256k1'
  CXX      libbitcoin_server_a-chain.o
  CXX      libbitcoin_server_a-checkpoints.o
In file included from /usr/include/boost/thread.hpp:24:0,
             from scheduler.h:15,
             from bitcoind.cpp:15:
/usr/include/boost/thread/future.hpp:3188:0: error: unterminated #if
 #if ! defined BOOST_NO_CXX11_RVALUE_REFERENCES
 ^
/usr/include/boost/thread/future.hpp:3164:0: error: unterminated #if
 #if defined BOOST_THREAD_PROVIDES_FUTURE_CTOR_ALLOCATORS
 ^
In file included from /usr/include/boost/thread.hpp:24:0,
             from scheduler.h:15,
             from bitcoind.cpp:15:
/usr/include/boost/thread/future.hpp:16:0: error: unterminated #ifndef
 #ifndef BOOST_NO_EXCEPTIONS
 ^
/usr/include/boost/thread/future.hpp:8:0: error: unterminated #ifndef
 #ifndef BOOST_THREAD_FUTURE_HPP
 ^
In file included from util.h:18:0,
             from bitcoind.cpp:16:
tinyformat.h:104:1: error: expected unqualified-id before ‘namespace’
 namespace tinyformat {}
 ^
tinyformat.h:109:1: error: expected unqualified-id before ‘namespace’
 namespace tfm = tinyformat;
 ^
In file included from util.h:18:0,
             from bitcoind.cpp:16:
tinyformat.h:150:1: error: expected unqualified-id before ‘namespace’
 namespace tinyformat {
 ^
bitcoind.cpp:191:1: error: expected ‘}’ at end of input
 }
 ^
In file included from bitcoind.cpp:15:0:
scheduler.h:80:87: error: expected unqualified-id at end of input
     bool shouldStop() { return stopRequested || (stopWhenEmpty && taskQueue.empty()); }
                                                                                ^
scheduler.h:80:87: error: expected ‘}’ at end of input
Makefile:7351: recipe for target 'bitcoind-bitcoind.o' failed
make[2]: *** [bitcoind-bitcoind.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/home/pi/bin/bitcoin/src'
Makefile:8357: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/pi/bin/bitcoin/src'
Makefile:668: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

PLEASE HELP!

Looks like libboost is not installed?

Try:

apt install libboost-all-dev -y

Then rebuild:

./autogen.sh; ./configure; make


Most efficient way to calculate fee from getrawtransaction? I would to get the fee when I search for a transaction using getrawtransaction, but the JSON-RPC does not return this.

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

So to achieve this, my idea is to:

Call getrawtransaction for each vin, and save the output value for each one.
Sum all the output value for the vins, and subtract the sum of the vout values to give you the remainder.

I know this will work, but I dislike having to call getrawtransaction for each vin (as this JSON-RPC call will be made 200+ times for some transactions).

Is there a more efficient way? Or is this currently the only way to calculate the fee for a transaction using bitcoin-cli?

  Aside: Why doesn't getrawtransaction return a fee field, like the transactions in getrawmempool and getblocktemplate do?

To calculate fees.
Take sum of all vouts.For every vin there will be prev txid and outputindex,
Get this txid with getrawtransaction or some other way,go to vouts of this new tx at index, here you will get amount,
Repeat this for every vin.
Take sum of this vins.
Take difference between vin and vout you will get fees.

To avoid calling ever time you need to store txids somewhere or user something like insight.


How to perform CPU mining on bitcoin TESTNET on Linux? I need approximately 100 Bitcoin Testnet to run an experiment on the lightning network.

Any suggestion on how to run CPU mining? Should I use cgminer?
Make any sense to perform solo mining on testnet?

Currently I am running a full testnet node with bitcoind on a linux environment.

It's almost impossible to mine Testnet BTC with CPU, but there is a generatetoaddress command in Bitcoin Core:

bitcoin-cli generatetoaddress nblocks "address" ( maxtries )

If you want to continuously mine on Linux, create a bash loop:

while [ 1 ]
do
    bitcoin-cli generatetoaddress 1 "2N5fJkfCv4cF6vsa5QQJnsazBKWNXynn9zp" 10000000
done

Documentation: https://bitcoin.org/en/developer-reference#generatetoaddress


Trouble CPU Mining with CGMiner and CPUMiner on Ubuntu Server 12.04 I just started mining within the past week on my laptop but I am trying to set up 2 dedicated mining servers to run 24/7. I've been using UfaSoft's CPUMiner on Windows 8 on the laptop, but I cant seam to get it to work on either of my servers.

I am running a Dell Dimension 433c with a 600 MHz Pentium Pro with 256 MG RAM & a Dell Dimension L1000R with a Pentium III again with 256 MB RAM both with Ubuntu Server 12.04 LTS x86 installed.

I downloaded the source code for both UfaSofts CPU Miner and CGMiner directly from the developer's website, downloaded all the dependencies needed for a rig without any GPUs and did a #make install for both.

With UfaSoft I keep getting Error 80072550 when ever I try to mine.
With CGMiner, It won't initialise and says that all devices are disabled. A friend of mine told me that it was picking up a GPU and was then disabling the CPU miner as a response but I think he may not know what he's talking about.

Any help that I can get would be greatly appreciated.

It's pointless. With that kind of hardware, it would take you on the order of a month to mine a dollar's worth of Bitcoins, and the electricity used would cost you many times that.


Why does script need to be purged from transactions for mimblewimble to work? What is the compatibility problem between script and mimblewimble usage on the main chain?

Is there a way that Bitcoin can adapt to allow both mimblewimble and features like multi sig, atomic swaps and time-lock transactions?

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.


Accidentally shutdown system while Bitcoin Core client was synchronizing My computer was accidentally shutdown while Bitcoin Core was synchronizing and it is now giving the error fatal error please see error log. Please tell me what is the solution to this problem.

giving an error as ' fatal error please see error log' ... what is the solution to this problem.

Step one is to do as it suggests. The location of the error log depends on the platform (Windows probably %APPDATA%\bitcoin, Linux probably ~/.bitcoin)

If all else fails, just install some wallet software elsewhere and re-import the private key you carefully backed up for just this sort of situation.


Where is the code that specifies when a block is released? I'm not sure how this exactly works. So roughly every 10 mins a block is released to the network. How is this done?

Does my bitcoin client signal this? Would that mean in theory if there was just one user, one client, you would just mine alone?

Every time a block is successfully mined, the miner releases it immediately. The mining difficulty is adjusted over time to keep the average block release rate at roughly ten minutes. Successfully mining a block is so difficult that all the miners in the world only successfully build a single block, on average, once every ten minutes.


Is there a reason SatoshiDice & BitLotto use 0.00543210 BTC, and not 1 satoshi, to customize pay-to addresses? SatoshiDice and BitLotto allow players to customize where winnings are sent by including an extra 0.00543210 BTC payment to the desired address as part of the entry transaction.

Is there a technical reason they don't use a single satoshi (0.00000001 BTC) value instead?

Well, what that is called is a hack.  It is a hack to make the system work in a way that is wasn't meant to work.

By definition, hacks aren't thought out very well and often aren't the optimum method -- if not outright flawed.  But they do in many instances, fix the immediate need.

In most every bet to BitLotto and SatoshiDICE there is an output address for change.  These services can't know if that change was meant to be the alternate pay-to address or if it was just the change.   One Satoshi would be a bad choice for this "special indicator" as that happens naturally quite often.  An amount that doesn't occur very often would be an amount like "0.00543210".  The frequency of change being 0.00543210 is much, much lower than it being 0.00000001 BTC.

But the chance is not zero.  If I have a coin with 0.25543210 BTC on it and I sent a 0.25 wager, I'll get back 0.00543210 as change.  Since that change is for an address in my own wallet, then even though SatoshiDICE might send the winnings to that change address I'll still receive them.  But the normal mode for these services is to always pay back to a sending (input) address, so returning to the change address frequently becomes a service issue as it is harder to understand how it works.   So ideally, this special number is one that wouldn't normally get be used for change.

But if instead I had actually made both a payment of 0.00543210 to someone and a bet to SatoshiDICE in the exact same transaction, then the winnings would go to that someone and not back to me.  If I know that 0.00543210 is of special significance with SatoshiDICE I'll know to never make a transaction with that amount in it when I'm also including a SatoshiDICE bet.  If the number were something else, like 0.00814271, that also would be infrequently used naturally, but it also wouldn't be one that I would recognize and might accidentally be an amount I would pay in this hypothetical bet statement that I combine with real-world payments.

So I'm going to come to the conclusion that to eliminate even the extremely rare chance that the payout goes to the wrong party, these services chose an easily recognizable amount so that it might save a person from making that mistake.  This amount would also preferable be a low value so that it doesn't suck too much betting capacity from the bettor's wallet with each use.

What is an amount that serves both those aims?  0.00543210.


How to recognize which output is used as input for a new transaction I want to find out which address's coins will be used in a transaction.

I have the txid of a transaction.
In vin I see the txid of the input transaction, but how can I know which output of this transaction is used?

I am using rpc calls called from php.

This is the transaction for which I want to know from which address the coins come:

    "txid" : "6470db622271c3a2910affae11f11d08b278ba790ee13180fbf1b151bd1bb0f5",
    "version" : 1,
    "time" : 1464138669,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "21129d09deaf685e2d95eec49f6481a2d148183f0dbf226942cfbbf698a7cdea",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "304402205626172faba89dc29d97a1f1638a6341387bc39a2444706a7f6ed95b51b1048102204f64e3c967149bf386b05fb10da0d52257d75074e012abb6ec034d1a00ef5a2701 032200b135d5c1301db7d8afa971871ad24d499e7ac0c15cb374a8e950c7b3d4ae",
                "hex" : "47304402205626172faba89dc29d97a1f1638a6341387bc39a2444706a7f6ed95b51b1048102204f64e3c967149bf386b05fb10da0d52257d75074e012abb6ec034d1a00ef5a270121032200b135d5c1301db7d8afa971871ad24d499e7ac0c15cb374a8e950c7b3d4ae"
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 15499.99310000,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 ea491757c90b6e83e208b00fcccab53f9aff37b1 OP_EQUALVERIFY OP_CHECKSIG",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "Ad8fKrKKNiFEv2TY5tSFp6WXXvWtGehKFX"
                ]
            }
        },
        {
            "value" : 500.00000000,
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 bb265fe2e77350425890fb5ad6abda3e28394e20 OP_EQUALVERIFY OP_CHECKSIG",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "AYqRygUrwzeh371VZffxu5Emo6XZczxiYQ"
                ]
            }
        }
    ],
    "blockhash" : "000008d45d6cb4ad076c7edfac237917f751a94ea01cd1c0d5d9ca5c4d5ab8cd",
    "confirmations" : 277
}

This transaction is referenced in vin:

{
    "txid" : "21129d09deaf685e2d95eec49f6481a2d148183f0dbf226942cfbbf698a7cdea",
    "version" : 1,
    "time" : 1464138667,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "0b2b23719e83482bf98d0d3770a523a2c730ea75104a53dd5fa704f0c6d8c6b8",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "3045022100f01c5764fdfbc2e845f87d7e7ed4675027bea854278764d39ce6592f048eeeeb02200fb7d0e2f95720237659d464cfd314881995235222754734792fd14f1cde797301 02e02c24b096413d31648eae4f41e78294c78390a0499e151530d1d388d1edb1a2",
                "hex" : "483045022100f01c5764fdfbc2e845f87d7e7ed4675027bea854278764d39ce6592f048eeeeb02200fb7d0e2f95720237659d464cfd314881995235222754734792fd14f1cde7973012102e02c24b096413d31648eae4f41e78294c78390a0499e151530d1d388d1edb1a2"
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 15999.99320000,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 6e43b6760addf0a08af83cf1f3fac7e81d404f2a OP_EQUALVERIFY OP_CHECKSIG",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "ARpu6N2Bf24JmmRy2gbZfPr8xJqdHbvimY"
                ]
            }
        },
        {
            "value" : 500.00000000,
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 bb265fe2e77350425890fb5ad6abda3e28394e20 OP_EQUALVERIFY OP_CHECKSIG",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "AYqRygUrwzeh371VZffxu5Emo6XZczxiYQ"
                ]
            }
        }
    ],
    "blockhash" : "000008d45d6cb4ad076c7edfac237917f751a94ea01cd1c0d5d9ca5c4d5ab8cd",
    "confirmations" : 277
}

There are two vout and I don't know how to find which one is right.

A vin contains both a txid and a vout.  As you've correctly identified, the txid part is the transaction that contains the unspent transaction output (UTXO) being used for this input.  The vout part is a zero-based index for which output on the transaction is being used.

For example, if vout is 0, this input points to the first output of the transaction.  If vout is 3, it points to the fourth output.  Think of the these parts of the vin structure as being an address for a particular UTXO on the blockchain.


In Peercoin style Proof of Stake, can one person 'stake' for another's address? The parameters included in the staking are listed here:

// ppcoin kernel protocol
// coinstake must meet hash target according to the protocol:
// kernel (input 0) must meet the formula
//     hash(nStakeModifier + txPrev.block.nTime + txPrev.offset + txPrev.nTime + txPrev.vout.n + nTime) < bnTarget * nCoinDayWeight
// this ensures that the chance of getting a coinstake is proportional to the
// amount of coin age one owns.
// The reason this hash is chosen is the following:
//   nStakeModifier:
//       (v0.3) scrambles computation to make it very difficult to precompute
//              future proof-of-stake at the time of the coin's confirmation
//       (v0.2) nBits (deprecated): encodes all past block timestamps
//   txPrev.block.nTime: prevent nodes from guessing a good timestamp to
//                       generate transaction for future advantage
//   txPrev.offset: offset of txPrev inside block, to reduce the chance of
//                  nodes generating coinstake at the same time
//   txPrev.nTime: reduce the chance of nodes generating coinstake at the same
//                 time
//   txPrev.vout.n: output number of txPrev, to reduce the chance of nodes
//                  generating coinstake at the same time
//   block/tx hash should not be used here as they can be generated in vast
//   quantities so as to generate blocks faster, degrading the system back into
//   a proof-of-work situation.
//

I don't see anything that proves ownership of the coins that were staked in a particular output. I assume there must be something, though, or else anyone could stake with anyone else's UTXOs. What am I missing?

Maybe it is just a requirement that there be a transactions spending the output be included in the block? If so, then if someone created that initial transaction, then they could give it to someone else and let them do the manual labor of checking once per second to see if their stake succeeds?

Look at lines 401 and 402 of the code you linked to. The block must be signed with the key that can spend the UTXOs.


Where is bitcoin.conf location on MacOS with Bitcoin core v0.15.1 After doing some research it is supposed to be under ~/Library/Application Support/Bitcoin/

But on my computer there is no Bitcoin.conf under ~/Library/Application Support/Bitcoin !

So where do I find Bitcoin.conf?

Bitcoin.conf usually arent come with it so you have to make one manually by making a file and naming it bitcoin.conf

After you made it, you can use the link below to use the configuration as template

LINK

Hope the answer above is what your looking for