How blockchain.info calculate the value transacted Having this address: https://blockchain.info/address/19tqZYnP9youKtbene2FZiZtZyJYaLeBDw

The last transaction says that this address received 0.0236 BTC

But even knowing the value in and the value out I am not able to calculate that value:
https://blockchain.info/tx/831c976cb54f27e5a496db749fc9e865c8e077006225d1dfaf61d998fe5a3186

In:
---
15Rhv2dsEjFaHzMhPsjGmFxgqCRhCmggjj (0.04583825 BTC - Output)
13LwYeB93Bmo2aWqGyK1ybtF9JiupPFVey (0.029625 BTC - Output)
1BxdV34eTe1YJBJpScGx6jRRVDQBeRf5qj (0.00696224 BTC - Output)

Out:
----
1BTvKHzbfm3RjPMxDZSsG2YYuaEHgfdJNP - (Spent) 0.00045884 BTC
1NCLWFw6F2nJ2pgBWy96K37rbx7VSLZs66 - (Unspent) 0.00239111 BTC
1D7BNbWBPuL22TW6WuoSq5sRrbPAxeJw8g - (Spent) 0.0156 BTC
19tqZYnP9youKtbene2FZiZtZyJYaLeBDw - (Unspent) 0.0236 BTC
1wLbaePtYhh2t5Cgd5NF59LX6Pooe1yLH - (Spent) 0.00920259 BTC
3HXAkXTYvtLzYuudDfNZBMSoueUtvdwXAz - (Unspent) 0.03036754 BTC

What I tried is sum all the In's and then substract the Out that has been spent and the fees.

What I am doing wrong? How I can calculate 0.0236 BTC

You do not have to calculate the in/out values to see how many bitcoins have been "sent" to an address.

You see, outputs from a transaction can be "locked" to a specific address. However, the address page on blockchain.info shows all the transactions that have resulted in an output being locked to that address.

In the most recent transaction on that page, you can see that one of the outputs has been locked to that specific address:

Out:
----
1BTvKHzbfm3RjPMxDZSsG2YYuaEHgfdJNP - (Spent) 0.00045884 BTC
1NCLWFw6F2nJ2pgBWy96K37rbx7VSLZs66 - (Unspent) 0.00239111 BTC
1D7BNbWBPuL22TW6WuoSq5sRrbPAxeJw8g - (Spent) 0.0156 BTC
19tqZYnP9youKtbene2FZiZtZyJYaLeBDw - (Unspent) 0.0236 BTC <- this one
1wLbaePtYhh2t5Cgd5NF59LX6Pooe1yLH - (Spent) 0.00920259 BTC
3HXAkXTYvtLzYuudDfNZBMSoueUtvdwXAz - (Unspent) 0.03036754 BTC

So that's where they are showing that 0.0236 has been received by 19tqZYnP9youKtbene2FZiZtZyJYaLeBDw.

I suppose showing entire transactions on an address page can be a little confusing, when it's only the outputs that are locked to an address (not entire transactions).

Here is an alternative way of viewing the balance of an address in a blockchain explorer: http://learnmeabitcoin.com/browser/address/19tqZYnP9youKtbene2FZiZtZyJYaLeBDw


How to refund bitcoin after wallet recovery? I lost my bitcoin balance after I forgot my wallet password in blockchain. Although I managed to get my wallet (same wallet with the same security phrase) recovered,my balance showed 0. Where did my bitcoin go ? Can I access them again?

Actually, you said you lost your password to your blockchain wallet, and since you have the wallet and the security passphrase,
then actually you should check the btc address in which you have the fund on blockchain.info to see if your actually balance is there


What is BIP32-style derivation? I am reading the technical "specification" for stealth addresses, available here. The core idea is described in the following paragraph:

  Using Elliptic curve Diffie-Hellman (ECDH) we can generate a shared
  secret that the payee can use to recover their funds. Let the payee
  have keypair Q=dG. The payor generates nonce keypair P=eG and uses
  ECDH to arrive at shared secret c=H(eQ)=H(dP). This secret could be
  used to derive a ECC secret key, and from that a scriptPubKey, however
  that would allow both payor and payee the ability to spend the funds.
  So instead we use BIP32-style derivation to create Q'=(Q+c)G and
  associated scriptPubKey.

I understand everything except the last sentence. As far as I can tell, Q and c are known to the payee and payer so the keypair Q'=(Q+c)G is also known to both. How does Q' allow for only the payee to spend the funds? How does BIP32-style derivation work?

I believe there is a typo. It should instead read Q'=(d+c)G=Q+cG. The private part d+c is an offset of the payee's private part d, so only known to the payee. The public part is an offset cG, known to both.


why banks are trying consensus algorithms like ripple I am wondering that why do we need consensus algorithm like ripple if all the nodes in a system is honest. There won't exist an use case of double spending. I am asking this question because recently i am reading the news that banks are using ripple algorithm to transfer money between their international branches.

Double spending doesn't just include cases where a participant tries to spend his own funds twice, but it also includes cases where two honest participants each want the same liquidity.

For example, say I have 100,000 Euros that I'm willing to exchange for 113,000 USD and there are two people who each want to take me up on that offer. Somehow, we have to agree on which of those gets the offer, and that's precisely the same issue as a double spend.

You either need a consensus algorithm or you need a central authority.


What is proof-of-stake? As we know one of the important mechanisms of Bitcoin is proof-of-work.

How does the concept of proof-of-stake work? How does it differ from proof-of-work?

Proof of stake is a proposed alternative to proof of work designed to increase network security. It's not currently implemented in the main chain (and would likely require a hard fork to implement), but alt currency PPCoin features a hybrid proof-of-stake/proof-of-work system of sorts.

With proof of work, the likelihood of mining a block is dependent on the work done by the miner, e.g. the number of hashes checked for validity by a CPU, GPU, FPGA, or ASIC. As such, over time, the blocks are split across miners proportionally to their relative hashrates. With proof of stake, blocks are split relative to current wealth, so someone possessing 1% of the bitcoins currently in existence could "mine" 1% of the proof of stake blocks.

This proposed system has a few (theoretical) benefits relative to proof of work:

Reduced long-term transaction fees

When transaction fees form the majority of block rewards, with the current proof of work system, miners would be forced to require a "minimum" transaction fee if they wish to remain profitable, as they must utilize physical and costly resources (hardware, electricity, internet, etcetera) in order to mine blocks. Proof of stake has no such limitation, as solving blocks would require no physical resources whatsoever (apart from a computer running the Bitcoin software, which is essentially negligible).

Decreased likelihood of a 51% attack

In the current proof of work system, an attacker need merely obtain over half the current network hashing capacity for a short amount of time to perform a so-called "51% attack". With proof of stake, an attacker would need to obtain over half of the bitcoins in existence, a far more expensive and difficult feat. Moreover, performing a 51% attack and likely devaluing Bitcoin significantly wouldn't be all that appealing if you are so heavily vested into it.

However, this is debatable. If a single entity could obtain, even temporarily, loans or other borrowed capital comprising over half the network, they could perform a 51% attack with very little input resources, and might well have good incentive to do so. Just as centralized or leasable hashpower dramatically increases the risk of a 51% attack on a proof of work system, centralized or borrowable wealth dramatically increases the risk of a 51% attack on a proof of stake system.

Proof of stake was first formally proposed by forum user QuantumMechanic here. Two at least somewhat complete implementation specifications have been released, one by Meni Rosenfeld and one by Cunicula; both are explained in detail on the proof of stake wiki page. Both are hybrid proof-of-stake/proof-of-work implementations, meaning that 51% of the total wealth and 51% of the network hashpower would be required to create and maintain a fork. You can find the (unofficial) forum discussion thread here.


Will any network participant be able to send to a native segwit address? Does a wallet have to upgrade to send to a native segwit address provided by the recipient or can anyone send to them, as was the case with the P2SH-wrapped segwit addresses?

In the compatibility section of BIP-0173, it states:

  Only new software will be able to use these addresses, and only for receivers with segwit-enabled new software. In all other cases, P2SH or P2PKH addresses can be used.


Self-hosted Bitcoin wallet for Linux with API? I'm looking for some Bitcoin wallet software I can host locally on my Linux server that provides either an API or webhooks for detecting when Bitcoin transactions have completed. I also need a way to initiate transactions (i.e. tell the wallet to send Bitcoins to an address).

Does anyone know of anything? I know there is coinpunk, but I don't see anything about it having such functionality.

did you look at bitcoind?
It does everything you are looking for.

-port=           Listen for connections on  (default: 8333 or testnet: 18333)

-walletnotify=    Execute command when a wallet transaction changes (%s in cmd is replaced by TxID)

-alertnotify=     Execute command when a relevant alert is received (%s in cmd is replaced by message)

http://paste.ee/p/IBU79

And all of your transactions you do via rpc  https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list

enjoy!


How do you make the unicode Bitcoin symbol show correctly in text on Linux? The Bitcoin symbol was added to the Unicode standard as ₿ (U+20BF). This shows up as a placeholder (empty box) in texts for me. What do you have to do so it will be shown in text, e.g. in the browser?

While the symbol was part of the Unicode 10.0 release, many fonts still don't have the symbol as part of their character set. You need to install a font that includes the symbol to make it show up.
One such font is GNU Unifont Glyphs. After installing the package unifont, the symbol shows up in the console and browser for me.

Corollary, many Linux distributions support inputting unicode symbols by typing CTRL+SHIFT+U, followed by the symbol's designation 20bf offset by a space or ENTER.


Should I start to buy OneCoin? I am a professional software engineer and freelancer. I have heard about Bitcoin (and recently OneCoin) a long time ago, but I was not interested to indulge in this business.

Now, a few days ago a friend of mine told me that he has started this business (one coin) and he is purchasing OneCoin and in next year he will be able to earn enough money while selling the coins he would have purchased. I don't know if this business is good for me or not.

Should I start to buy OneCoin, since I am new to this business?

No, it's a proved scam, and they use misleading promotion to associate it with Bitcoin. If you google them, you'll find out that they are accused of scamming and are under investigation by authorities. That project is not related to Bitcoin at all.


Deciphering cgminer interface in terminal Am brand new to mining, and wanted to download an OSX miner just to experience (fully realizing that it would not be profitable). With cgminer connected to a mining pool, I see the following interface...

... Can someone help me understand what each of the indicators mean (A, R, HW, WU, ST, SS, NB, LW, GF, RF)?

Bitcoin Forum > Bitcoin > Mining > Mining software (miners) (Moderators: gmaxwell, MiningBuddy) > CGMINER ASIC FPGA miner monitoring fanspeed RPC linux/win/osx/mip/arm/r-pi 3.9.0

Cite:

A:   The number of Accepted shares
R:   The number of Rejected shares
HW:  The number of HardWare errors
WU:   The Work Utility defined as the number of diff1 equivalent shares / minute

 AVA 0: 23C/ 47C 2280R | 77.10G/83.20Gh/s | A:120029 R:0 HW:2295 WU:1162.5/m

Each column is as follows:
Temperature (if supported)
Fanspeed (if supported)
A 5 second exponentially decaying average hash rate
An all time average hash rate
The number of accepted shares
The number of rejected shares
The number of hardware erorrs
The Work Utility defined as the number of diff1 equivalent shares / minute

The cgminer status line shows:
 TQ: 1  ST: 1  SS: 0  DW: 0  NB: 1  LW: 8  GF: 1  RF: 1

TQ is Total Queued work items.
ST is STaged work items (ready to use).
SS is Stale Shares discarded (detected and not submitted so don't count as rejects)
DW is Discarded Work items (work from block no longer valid to work on)
NB is New Blocks detected on the network
LW is Locally generated Work items
GF is Getwork Fail Occasions (server slow to provide work)
RF is Remote Fail occasions (server slow to accept work)


Aborting a three-way swap Suppose Alice has 1 BTC, Bob has 1 LTC, and Carol has 1 NMC. Alice wants NMC for BTC, Bob wants BTC for LTC, and Carol wants LTC for NMC. Assume each cryptocurrency has the same value and can be 1-to-1 transferred. They need to make a three-way swap: Alice will transfer BTC to Bob, Bob will transfer LTC to Carol, and Carol will transfer NMC to Alice. However, there is no trusted authority/intermediary.
Preliminary:

H is a cryptographic hash function. Hashlock h indicates that if A sends the contract a value s, (i.e., a secret) such that h = H(s), then the contract irrevocably transfers ownership of those altcoins from B to A. Timelock T indicates that if A fails to produce that secret before time T elapses, then the escrowed altcoins are refunded to B. Here, T is the enough time for one user to publish a smart contract on any blockchain, and for the other user to detect that the contract has been published.

Detailed swap is as follows.

Step 1: Alice creates a secret s, such that h = H(s). Then, she publishes a contract on the BTC blockchain with hashlock h (timelock 6T in the future), to transfer her BTC to Bob.

Step 2: Bob first confirms whether Alice’s contract has been published on the BTC blockchain or not. If true, he publishes a contract on the LTC blockchain with the same hashlock h (with timelock 5T in the future), to transfer his LTC to Carol.

Step 3: Carol first confirms whether Bob’s contract has been published on the LTC blockchain or not. If true, she publishes a contract on the NMC blockchain with the same hashlock h (timeout 4T in the future), to transfer her NMC to Alice.

Step 4: Alice first confirms whether Carol’s contract has been published on the title blockchain or not. If true, she sends the secret s to Carol’s contract, while acquiring 1 NMC and revealing s to Carol.

Step 5: Carol then sends s to Bob’s contract, while acquiring 1 LTC and revealing the secret s to Bob.

Step 6: Bob finally sends s to Alice’s contract, while acquiring the 1 BTC. The swap is completed.

Questions:

a) If Bot halts in Step 2, what is the result?

b) If Carol halts in Step 5, what is the result?

c) If Carol posts her contract with Alice before Bob posts his contract with Carol, what is the result?

d) If Carol’s contract with Bob were to expire at the same time as Bob’s contract with Alice, what is the result?

e) If Alice reveals the secret s before Step 3 completes, what is the result?

a) If Bob aborts before step 2, then Alice will not reveal s. 6T will elapse and Alice will get her BTC back. If Bob aborts after step 2, then Alice will not reveal s, as she has no incentive to do so - only Carol is paid, so why would Alice reveal s and lose her BTC for nothing? Again the timeout is reached.

b) If Carol aborts before step 5, Alice receives the NMC, but Carol's payment times out and so Carol does not receive the LTC (and it is given back to Bob, who will, at the end of the protocol, have both LTC and BTC). However, Bob can continue executing the protocol and receive his BTC, so Carol aborting is only harming her. If Carol aborts after step 5, she will get her LTC payment. Alice has already received her NMC and Bob can continue executing the protocol to receive his BTC.

c) This does not make any difference in the protocol.

d) This would be a problem if Alice's contract expires in 6T, but both Bob's and Carol's expire in 4T. Alice could wait until time 3T has elapsed to claim the coins from Carol's contract. As soon as s is seen on the NMC blockchain by Bob and Carol, time 4T has elapsed. In this case, Carol can no longer claim her coins, as Bob's contract has now expired. Hence, the 1 LTC is returned to Bob. However, Bob can also claim the 1 BTC. So, in case Carol sees that Bob's contract has an expiration of 4T she should refused to create her contract.

e) In case Alice reveals s prior to step 3, Carol has not yet created the smart contract. If she is rational, she will not continue executing the protocol. If both Bob and Carol are rational, Bob can take the 1 BTC and Carol can take the 1 LTC. Then Alice is left without any money. Hence, Alice can only harm herself by revealing s early.

Maurice Herlihy has written a paper on atomic swaps involving multiple parties which I recommend.

PS: Typically, stopping execution in the middle of a distributed protocol is called "aborting", not "halting". The "Halting problem" usually refers to something else in theoretical computer science.


Electrum Wallet - Is it possible to specify inputs in new transaction? In my wallet, I have bitcoins belonging to three different addresses.  I want to send the bitcoins from one of those addresses elsewhere.

This is made easier, perhaps, by the fact that the balance of that one address arrived in a single transaction.

Is there any way for me to do this?

Thanks!

Use the secondary click on a address and then the "Send from" option.


Sent Bitcoin to my electrum wallet address without hitting request first now it says its confirmed and i have no money after requesting it Sent Bitcoin to my electrum wallet address without hitting request first now it says its confirmed and i have no money after requesting it after Isent it. Can I still receive my coin

Can I still receive my coin

For privacy, many wallets use a new receiving address for each transaction but sending money to an old address should still work.
You can use one or more of the public blockchain explorers to find out the status of transactions involving the old address.

Addresses
To view a full list of addresses known to your wallet see I can't find my bitcoin address
If the address to which you sent the money is not on that list, it is possible you sent the money to someone else's address and have lost the money with no chance of recovery. If you have multiple wallets or deleted a wallet and reinstalled the same software or another, it is possible you sent the money to an address that no-one has control over (unless you were diligent in making and retaining backups of the wallet and records of the private-keys and/or recovery phrases)
If the address is on that list and shows a balance of zero, where blockchain explorers show a non-zero balance, it is likely there is a problem with synchronisation.

Synchronisation
See I didn't receive a Bitcoin Payment. What does it mean when the Client is synchronizing?
If your wallet is having problems synchronising, you won't see your money until it succeeds
An unofficial Electrum Beginner's Guide says:

You can monitor progress from the Network window. Access it by clicking on the circle to the lower right of the main window. When the block count under “Blockchain” equals the height indicated for the servers you’re connecting to, Electrum will be fully synchronized and all confirmed transactions should be displayed properly under the History tab.

If the servers that Electrum connects to are themselves not synchronising, your wallet might not know that it is not  synchronised with the main body  of the bitcoin blockchain network. -- check the blockchain height in your wallet in the network tab (blockchain: nnnnn blocks) - make sure it agrees with blockchain explorers --

Checking "balance" using another wallet
Download and install a new wallet (e.g. on another computer you own)
Watch-only
Import the address into the new wallet
Note that this doesn't mean the address is yours and gives you no ability to spend money at that address.
Full-Access
Export the Private key from Electrum

Wallet > Private Keys > Export.

Import the private key into the new wallet

Footnote, probably unrelated:
Electrum phishing & theft
According to https://electrum.org/#home currently

Warning: Electrum versions older than 3.3.3 are vulnerable to a phishing attack. Do not download Electrum from any another source than electrum.org.

There are fake versions of Electrum which steal your money.


How to get Bittrex Commission Value from API Binance has a very simple way of getting the Commission value from its exchangeInfo endpoint.

I do not see any corresponding way to get the commission on Bittrex from the API documentation, but it is relatively poor documentation and only covers v1.1

Does anyone know how to get the Commission value from the API?

(Note, I know the current value is 0.25%, which is currently hardcoded into my scripts. I'd prefer to fetch the current value in case it changes rather than rely on hardcoding the value.)

According to the latest Bittrex Beta documentation, there is a JSON key called "CommissionPaid", minified to "n", which would indicate how much commission was paid on a trade. From my experience, it would seem that only the new beta websocket API provides this information, which means you'd have to subscribe to that and check the feed for this value.

A comment from someone associated with the Bittrex API, at the Github link posted above, indicates that he does not believe the REST API will undergo changes, so with that, I would not expect for this key to be transferred to the REST version.


Blockchain SHA256 hash and nonce I have been reading the SHA256 hash creation with a random nonce. So, my understanding is every miner would pull uncommited transactions and would try to create a Hash of the transactions with a random nonce starting with 0 and increment from there on. So, if every node/miner is performing the same hash with the nonce sequence starting from 0, it would always be the miner with the maximum computing power always outrun the smaller ones. How would a miner with lesser computing power ever be able to create a hash quicker than the largest one?

My second question is every time a block is added to the chain, would every miner stop their current process and restart all over again since the next block would depend on the hash of the currently added block?

The block hash has to be below a certain value and the block hash depends (among others) on the nonce and on the Merkle root.

The Merkle root depends on the sequence of transactions. Note that it's a sequence, not a set, meaning the order is important.

Different miners choose many different lists of transactions. For every list of transactions with the other fields which go into the block hash, chances are there is no 32 bit nonce which will make the block hash low enough to qualify as a new block on the blockchain. So miners add a transaction, or remove one, or permute some to get a different Merkle root all the time.

I'll just calculate the time an AntMiner S9 with a hash rate of 14 TH/s takes to go through all the numbers in a 32 bit field (2^32 hashes) for you:

2^32 H / (14 TH/s) = 2^32 / 14 / 10^12 * s = 0.30678 ms

To answer your second question: Network traffic takes longer than 0.3 ms. To give you an impression on it: In fiberoptic cables, signals travel with about a third of the speed of light. With the speed of light, something travels 90 km in that time, so signals in fiberoptic cables can travel about 30 km in it. Many miners are more than 90 km away from each other and attempting to travel more than 90 km in that time turns out to piss physicists off, a lot.


How many confirmation do i have to wait before i can spend the inputs I already received? Can I spend Inputs with 0 confirmations?? If I could, are there some restrictions?

If the input is coinbase transaction, you can't spent it until it get 100 confirmations. Relevant code is here
If the input is not a coinbase transaction, you can spend it by creating a raw transaction How To Create A Raw Transaction

However, receiving input with 0 confirmation is not recommended.

  Zero-confirmation transaction vulnerability: accepting
  zero-confirmation transactions (transactions that have not yet been
  included in a block) from somebody you do not trust is still not
  recommended, because there will always be ways for attackers to
  double-spend zero-confirmation transactions. However, this release
  includes a bug fix that makes it a little bit more difficult for
  attackers to double-spend a certain type ("lockTime in the future") of
  zero-confirmation transaction.


Is it a good idea to deposit directly into a service when withdrawing from another? I have two accounts on different Bitcoin broker services. I want to withdraw from one and deposit into the other. Is it necessary to first withdraw to my own Bitcoin wallet, or can I just withdraw from one service and deposit into the other directly, bypassing the wallet altogether? What are the advantages and disadvantages of either approach?

Many services explicitly warn users against this practice, including in their withdrawal terms clauses like "you may only withdraw to an address which is controlled by you." This is likely to be due to the details of procedures used in the case of dispute resolution, but I've never seen any explicit justification for it.
The advantages of withdrawing directly are (1) saving the network fee associated with the transaction from your intermediate wallet to the receiving service; (2) overall the transaction would be faster.
The disadvantage is potentially violating the terms of services and the associated risk.
I admit to having taken this shortcut occasionally, but I would tend to avoid it for large transactions.


Lightning Network: Is it creating 3 transactions instead of 2? I'm watching this Lightning Network presentation by the original authors.  At 9 minutes in, he notes that all the network sees will be a transaction to the multisig address and then a transaction to Alice for 0.8 BTC and a transaction to Bob for 0.2 BTC.

Is all of this effectively 3 transactions?  Would it not be cheaper and clog the blockchain less by simpling having Alice send 0.1 BTC to Bob and then another 0.1 BTC to Bob and have 2 transactions instead of 3?

Is all of this effectively 3 transactions?

No, assuming you mean '3 on-chain transactions'. It is useful to make a distinction between an 'on-chain transaction' and a payment being sent. To open a LN channel requires one (on-chain) transaction, and to close it requires another.

But while the LN channel is open, the participants can send each-other an unlimited number of payments using the channel (up to their channel capacity, of course). These payments are not recorded on-chain, instead their LN nods keep track of the channel's current state. This allows for more efficient use of blockchain space, while simultaneously giving the channel participants a mechanism for sending payments efficiently and without needing to trust their counter-party, or a third party.

Further, the channel participants can also route payments to other LN users, assuming that there is a valid route with the proper capacity available. A highly connected LN graph could allow all users to make payments to each other, without needing to constantly publish on-chain transactions.


Can a desktop wallet be tracked using IP address? I'm wondering if I use a vanilla desktop wallet like MultiBit or Bitcoin Core to send and receive bitcoins, who can track my IP address and how?

Surveillance nodes in the Bitcoin network that mass-connect to many nodes within the network could pin-point and identify your node as the first relay for some of your transactions with some degree of confidence.

Receiving is not so much of an issue.

But spending from the same address consistently will enable surveillance nodes to figure out that a certain IP address is in control of some address.


Digital currencies pegged to dollar value Some digital currencies, like NuBits, declare that they peg their value to dollar or other fiat currency.

How does this work?
Under what conditions this can work?
Can this be distributed, or does there have to be trusted parties who are always willing to exchange NuBits back to dollar and vice versa?
Are there other such digital currencies? I understand BitGold value comes from real gold bars which match to tokens on blockchain, which is little different I believe.

NuBits is really interesting in how it pegs to the USD, which they explain in the white paper. I'm guessing you don't want to go hunting through there (white papers can be ... daunting), so the short version is....

If the demand for NuBits goes up (ie, lots of people want to buy Nubits, so the price for a NuBit should rise above $1 USD), the custodians of NuShares ("Shareholders") will vote to issue newly minted NuBits to satisfy the demand and therefore drive the price back down to $1 USD.
If the demand for NuBits goes down (ie, nobody wants NuBits, so the price for a NuBit should drop below $1 USD), holders of NuBits are able to "park" their NuBits (aka, keep them off the market) in exchange for dividends paid in PeerCoin, which reduces the supply and drives the price back up to $1 USD.

There's actually lot more going on here than these two things, but these seem to be the main ones. More importantly, they seem to be working as NBT has been transacting around $10,000 USD daily (as of today) and I've only seen the price fluctuate +/- $0.01 USD over the past few months.

If you want the whole story (which includes lots of other mechanisms to stabilize the peg to the USD), take a look at the price stability page on the NuBits website.

The practical conclusion here is: if you ever see NBT selling for more than $1 USD, don't buy it, because the price will be back to $1 USD soon, so you're wasting your money.


What happens if everyone suddenly adops bitcoins, or it becomes very easy to create blocks I understand that bitcoins are currently produced at ~25BTC/10 min

If I understand correctly how fast a block is created is what determines how fast bitcoins are created.

If everyone starts using bitcoins it will create huge demand and price will rise if miners can't keep up with the adoption rate.

If a new technology appears (assume accessible to everyone so the problem of attacks on the network by trying to create a longer block isn't there) this will lead to a huge supply of bitcoins.

I'm trying to understand the dynamics of these two factors.

Is there a self regulating way where a sudden huge increase in the ability to solve for the block and how fast would this be?

Would a huge demand be also somehow self regulating or will it just spike the price?

Increased demand would raise both the price for bitcoins as such, and also increase the fees rewarded to miners. So the effect would be an increased investment in mining efforts.

Technology advances would increase the networks total Hash/s rate. Which first of all would lead the network to rebalance and demand more hashes/BTC, thus keeping the output constant.

The dynamic aspect I find interesting though, is that until all miners have upgraded their relative contribution to the network would shrink, and thus their individual share of the return. They would therefore be force to choose either to quit mining (operating costs would be higher than the return) or invest in new hardware. Which in effect would lead to a pruning of miners and a reconfiguration of relative performance among the remaining.

I wonder if the economy can sustain a long tail of miners or if the major players will use such transitions to invest in enough hardware to raise the barrier to entry beyond the tail miners returns.

It would be interesting to see a simulation on http://insightmaker.com/


Is the concept of paid prioritization in blockchain against net neutrality? Since there are so many discussion about net neutrality, this triggered the question, especially since usually the proponents of blockchain and cryptocurrencies are also big proponents of net neutrality.

At least at first glance it seems true to me, the transaction fees present in most blockchain implementations => paid prioritization => no network neutrality.

Maybe there is some economic perspective that I am missing that makes this not true, or maybe that at least it resolves all the problems usually associated with an absence of net neutrality.

It has nothing to do with net neutrality.
The concept of paying more for faster service isn’t against net neutrality. It’s part of internet providers strategy for years and it’s ok as long as the speed is the same for every website or internet service you want to connect. Problem with net neutrality arises, when your provider differentiate the access to internet websites and services basing on which plan you have. So, for example I can imagine that provider makes only Facebook and YouTube working fast, but GitHub will be a lot slower (but if you buy special “developer” offer for 100$ then the speed is back to normal). This will be against net neutrality.

I would rather look at the fees in crypto currencies from the perspective different bank wire transfers. There may be standard transfers (cheaper) and express transfers (more costly but faster). There is no differentiation between clients and to whom you send money.


Blockchain for internet-of-things or is there any mining algorithm that can be utilized in low-computational power devices preserving security? Recently IBM and Microsoft showed their interest (IBM post, Microsoft post) in utilization of blockchain for internet of things development.
Let's assume that in close future the blockchain technique to be implemented in smart cars overlaying road conditions or traffic data to each other.

Since the majority of honest nodes will be low-computational power devices (maybe like raspberry pi) it will be easy for adversary to perform a double-spending attack if implemented mining algorithm will not be able to bottleneck mining capabilities of devices.

Is there any mining algorithm that can resist nodes with high-computational power to a certain extent, so the blockchain can be utilized in a network of low-computational power devices?
From security perspective is it possible to allow only certain devices connect the network (let's say if they will somehow proove that they are limited in computational power within acceptable range defined by network)?

No, not in a fully decentralized way.  Hash-based methods (like what Bitcoin uses) will always be more efficient on more efficient hardware.  Proof-of-stake methods can't be fully decentralized.
No, hardware can't prove its capabilities in a fully decentralized way.  It is possible for a device to prove its maximum distance from you using the speed of light---if you send it a ping and it replies in n seconds, you know it's within n times 300,000 kilometers of you.  You can use similar hacks to prove other things---but you can't trustlessly export that proof to other users on the network you don't directly observe the phenomena, making it useless for block chains.

I read the two articles you linked to, and I suspect they're using "block chain" as a buzz word.  There's no way to do fully decentralized mining without giving control of the block chain to the people with the most efficient hashing hardware.

Their plan is probably to install a key pair on each device, sign each device's public key with the IBM master key, and then tell each device to accept messages from other devices as long as those messages have been signed with a key that was also signed by the IBM master key.

For example, my IBM car GPS will send traffic updates to other nearby IBM car GPSes.  Those GPSes will count my update as one authenticated vote.  If other nearby IBM car GPSes send the same message, eventually the message will have enough votes to cause all nearby IBM GPSes to choose alternative routes.  This is nominally "decentralized" and it may work until some IBM sysadmin signs 10,000 public keys for himself in order to get everyone off the highway so he can get somewhere quicker.


How can you tell how many users Bitcoin has? Impossible to answer accurately, but I suppose one could come up with educated guesses and ballpark figures from the number of nodes on the network, or number of users on popular wallet services.

Due to the nature of Bitcoin there is no precise answer to this question. However, this site displays some statistics on the number of nodes in the network over time: http://bitcoinstatus.rowit.co.uk/


Chronologically sorting transactions within a block Is there any way to chronologically sort transactions within a block?

The arrow-of-time in bitcoin is achieved through the blockchain. The whole point of proof-of-work is to arrange transactions in chronological order, to prevent double-spending.

Under this light, transactions in the same block cannot be put in strict chronological order; the time each miner saw an unverified transaction varies depending on their view of the network. The only certain order is that transactions in a future block happened after transactions in a past block (a parent block) on the blockchain.

You can order transactions heuristically if you want, but this is not cryptographically secure. One way to do it is to look at when they first appeared on the network, e.g. on blockchain.info or some other such service.


Bitcoind crashes directly after starting I'm am trying to solo mine. My first problem is when I try to launch bitcoin client as server with guiminer I get this error

Invalid -rpcallowip subnet specifications.* valid are a single ip.

I looked around and it seems that I need to open bitcoind and change my rpcallowip from what I understand.

My problem then is, when I try to open bitcoind, it pops up for 1 second then crashes. I have tried to run it as admin, I have downloaded a new wallet, but I couldn't get it to work.

From what I have seen my guess is it looks like rpcallowip=192.168.0.* I have seen I need to change it to rpcallowip=192.168.0.1/24. The problem is I don't know where to change it. Also I don't know if this is even the problem. I am trying to take this one step at a time. .

I thought it was in bitcoin-di. And like I was saying every time I try to load it, it crashes.

My goal is to get guiminer to solo farm with bitcoin core as my wallet. I thought it would be an easy process.

I'm on windows 8.1 with bitcoin core v0.10.2. Using guiminer. I set up with slosh pool and got that to work. My gpu is not strong enough to do any good tho so I figured I would give a shot with solo.

I'm not sure of I'm way off. Where so I go to change it?

Thank you for the response.

Well I figured it out. I had to find my bitcoin.config file. I opened it with note pad and changed rpcallowip=* to rpcallowip=192.168.0.1/24

I was trying to do that in bitcoind. Thanks to the guy who replied and thanks to whoever edited my post :)


Bitcoin Core recovery with Just Passphrase and Wallet ID I have a wallet ID and my passphrase but I have lost access to my Wallet and Keys due to a fire. Is there a way for me to recover my Wallet? The Hard drive the Wallet was on was physically destroyed beyond recovery. the software used was Bitcoin Core.

I assume that you mean a Bitcoin address with "wallet ID". Bitcoin addresses are public information and do not give any special access. The actual keys of a Bitcoin Core wallet are stored in the wallet.dat. The password is only used to decrypt the keys from the wallet.dat. Knowing an address and the password is not enough. Without a copy of the actual keys, your wallet is not recoverable.


My MultiBit is unable to connect I have installed my MultiBit wallet and there is red "connecting" sign in left bottom corner. Wallet never connects. When I try it from another place (my friends house) everything is ok.

It is obvious that its network problem in my place. I have public IP and port 8333 is properly forwarded. I am using Mac OS X 10.8.5.

I have no idea what else to try or where to look for some error messages. Do you have any ideas what else to try or where to look for some clues?

For anybody with common problem. It was DNS related problem.

Message from console:
01.01.14 21:06:52,881 mDNSResponder[38]: mDNSSendDNSMessage: write msg length failed -1/2
01.01.14 21:06:52,882 mDNSResponder[38]: ERROR: mDNSPlatformWriteTCP - send Broken pipe


What wallets are compatible with Satoshi Dice? Satoshi Dice requires wallets to be able to receive coins from the same address they are sent.

What are some notable examples that are compatible and incompatible with this?

What are the technical reasons behind such an incompatibility?

Satoshi dice uses the same address bitcoins were sent to send them back. There no wallet that does not permit that, how could you spend coins if at first you cannot receive them. The kind of "wallet" satoshi dice is refering to is like you try to spend bitocoin from a broker service (like Mt.Gox) the address they use is not assured to be yours (and the coin will not return back to you)


Is it possible to set an overall seed for generating blocks on regtest mode? I am using bitcoin core on regtest mode to simulate sending transactions.

Is it possible to set an seed for things like generating blocks or signing transactions, so that you can recreate an exact chain of events with the same block hashes and signatures?

Generation of blocks uses the proof of work algorithm that includes a nonce that ensures randomness, if we could somehow recreate all these things the whole system of cryptocurrency would break down. The short answer is no.


Is there a 64-bit port of the original software for windows? The download page on the Bitcoin site lists two clients for the windows platform. Both clients are a 32-bit binary.

Running a 64-bit build of Windows on a multi-core processor, I find myself wondering whether a 64-bit binary exists. So ... Is there a 64-bit port of Bitcoin-Qt for Windows out there?

Short answer: no.

Long answer: It's not likely to be necessary for some time.

There are still a considerable number of people on 32-bit Windows (~23% according to the Valve Hardware Survey, which paints a good picture of forefront computer enthusiast hardware, so the market share is likely to be larger among non-gamers).
Bitcoin-Qt doesn't yet push the limits of 32-bit memory address space. On my machine, Windows 7 64-bit, the program is consuming only ~128 MB of RAM while downloading blocks (haven't sync'd in a while). On my Mac, it's about 240 MB.
The type conversion necessary may be prohibitive, if there is significant code written specifically for win32. Qt itself is obviously working fine on 64 bit, as is the most of the bitcoind codebase. There may be things here and there to work out.
More likely to be prohibitive, or at least "not worth it", is the management of the release of another package. There's already five packages managed, so including another is just that much more.


Statistically how many unconfirmed transactions get rejected? I need to analyse unconfirmed transactions and I'm interested in knowing what is the probability for a given unconfirmed transactions to be confirmed.

Depending on the model, I see two solutions:

checking for a relatively long period of time how many transactions had been submitted and checking how many had been confirmed.
searching pattern behavior in the structure of a transaction that will lead to a rejection.

For a transaction to be included in a block, the probability is related to the fee that transaction pays to the miner (higher fee = more likely) and varies over time based on demand of block space (more congested = higher fee needed). It's also unpredictable because miners can choose whatever transactions they want to, doesn't always have to be the x highest fees.

Here's some stats on current fee vs confirmation time estimations: https://bitcoinfees.21.co


Is it safe to store user's secure pass-code in database with encrypted form while creating bitcoin wallet? I would like to create a Bitcoin Wallet.

Part of the process is to store public and private keys in encrypted form in server database.

All keys I am storing is encrypted using user's passcode.

1) Is it safe to store user's passcode in encrypted form in server database.
(Thinking that User might forget his passcode so considering one recovery option)

2) Is there any kind of future possibility that I get in trouble if any kind of attack happens or by action of some intruder/admin itself(worst possibility) - the key reveal to the attacker which will lead access and open up all the pub/priv keys from database of that specific User? This way I can not give forget pass-code option to user.

So considering both option Shall I store User's pass-code or not?

What is the best practice to implement this security feature in bitcoin wallet ?

Best practise is to only store a hash of a password, not the password itself. You should also include a random salt before hashing. You should be aware of which well-known hashing algorithms are no longer considered safe for this use.

Encrypting the password before storing it is not a good strategy because you end up with one encryption key, stored somewhere as plain-text, that can unlock all user's passwords. This is a gift to hackers.

You need to take care of how you hold the password in memory for use when encrypting and decrypting other data (keys etc). For example, you need to be sure other processes and plugins can't see into your processes' memory space and that before being released, any allocated memory is cleared. This should be automatic with most modern systems but it is your responsibility to be certain of this.

Yes, amateur attempting to write security code is probably a good way to destroy your business, destroy your reputation and put yourself in the way of civil or criminal proceedings for negligence.

To be honest this question might be better asked on somewhere like Security.stackexchange. There's nothing Bitcoin-specific about this.


Does the protocol ensures that private keys are unique? There is a very very low chance for the same private key to be generated. (source)

However, what happens when my generated private key matches a private key that is already used?

Does the protocol reject private keys if they are already used?

If not, what kind of damage will be done?

However, what happens when my generated private key matches a private key that is already used?

Then you got lucky, and can spend someone else's coins.

  Does the protocol reject private keys if they are already used?

No, how should it? Keys can be used more than once in normal operation.

Fortunately, it is extremely unlikely that this ever happens. See also these two related questions.


Would it be possible to retarget difficulty in real time? Could the mining difficulty adjust in real time, not only when blocks are found?

(NOTE: Not asking about retargetting after every block but continuously as a function of time.)

I'm worried about how Bitcoin (and many other cryptos) change the difficulty. The basic idea is that the difficulty is adjusted every N blocks (N=2016 for Bitcoin and N=1 for Monero). That is, a difficulty can change only when a block is found. The problem is that if hashrate suddenly drops significantly, say 99%, then it would take 100x more time than normally to reach new lower difficulty. The drop could happen if the price of the coin drops and thus mining isn't anymore profitable. Network slows down and the price goes even more down and thus even more miners stop mining, and thus the coin might die. This seems like a very unstable system to me. I don't see much incentive for anyone to mine bitcoin if the price drops dramatically. The only incentive for some people to mine would be that they have lots of coins and they don't want the system to die. Not sure if this is enough.

To avoid this problem, could the difficulty adjust in real time, not only when blocks are found? That is, the difficulty requirement for a valid block would depend on the time it was found. The difficulty would decrease as a function of time, thus eventually a block will be found very easily. For instance, if 2 hours has passed since the last block, the difficulty could have already dropped to 1% of what it has been for the previous blocks.

The difficulty requirement of block N at time T would be a decreasing function of T and depends on the timestamps and difficulties of past blocks somehow. For instance, the difficulty could be a exponentially decaying function of time since the 10th last block and the mean difficulty of those 10 blocks. The difficulty of a mined block must be at least as great as given by this function in order for it to be valid. So the timestamp of a block becomes an important part of the block data.

Would this idea make sense? Is it implemented in any coin? Or is there some reason why it is not a problem that the difficulty adjusts when a block is found?

It's a security property that the difficulty is not retargeted quickly, not a technical or design limitation. It prevents a case where you can isolate a node, or a portion of the network, wait a brief period, and then mine at a vastly lower difficulty in order to defraud those users. If the mining rate drops, the fees rise, and more miners are incentivized to join the network- it's a self balancing system.


What are the most historic code changes on bitcoin core? I was looking through the pull requests on bitcoin core's github and was looking for some of the major changes to the code.

https://github.com/bitcoin/bitcoin/pulls?page=10&q=is%3Apr+is%3Aopen

The oldest one is from Feb 14, 2016 but I'm sure historically significant changes to the code were done since.

Any one know of any?

Does any one constantly (like everyday) review all commits outside of the bitcoin core team?

The oldest one is from Feb 14, 2016 but I'm sure historically significant changes to the code were done since.

Indeed, date opened is not always a good indication of controversy or significance, it could also mean a change which has received very little review due to its insignificance, or very little rebasing/nit-fixing due to lack of time by the creator. It's common for more important changes to be the focus of more urgent review allowing them to be merged sooner. Perhaps you should try sorting by number of comments or number of reactions, but even then it depends what you deem "significant".

  Does any one constantly (like everyday) review all commits outside of the bitcoin core team?

By definition, someone who is actively involved in the review of PRs would be considered part of the "team". There is really no team, just volunteers, anyone is free to come and help out on GitHub, no requirements or prerequisites. Many users help out in this way, and you could be one of them :)


During a IBD : Initial Block Download by a full node, from where is the blockchain downloaded? I understand that a full node requires to do an IBD before being able to verify transactions. So, it downloads the ledger upto now, which is known as Initial Block Download.
But what I don't understand/know is, from where is the blockchain information being downloaded? Are other full nodes contributing in this activity, or is this information stored somewhere, and is retrieved from there?
Any help appreciated!

Yes, they download blocks from other nodes they connect to.
In Bitcoin Core you have the choice between being a pruned node or not. In both cases all blocks are downloaded and fully verified, but in pruned mode old blocks are deleted after a while after being verified. This has a number of implications, but one of them is that a pruned node does not help new nodes perform IBD.


What's the best way to get rid of 1 satoshi dust? I recently noticed an old address of mine had 1 satoshi sent to it in some dust spam transaction. The thought of this satoshi bloating the UTXO set for everyone bothers me. I'd like to "destroy" it, but I don't want to combine it with other inputs in a separate transaction for privacy reasons. Ideally I can "spend" it in a transaction with no outputs so it just goes to the miners, but I've tried doing this on Electrum and it won't allow transactions without any outputs. I haven't tried it with bitcoind yet, but my node is pruned so I'm not sure importing the private key would work since I can't rescan far back enough.

Another good option would be to somehow sign this input and allow someone else to aggregate it with a bunch of other dust outputs and "donate" them all to the miners, but I figure this is not currently possible.

Any recommendations on a clean, simple way I can destroy this satoshi without compromising privacy?

In the current environment, I doubt that you can.  Blocks are full these days, and the block space needed to spend your UTXO, whether as its own transaction or as one input of many similar transactions, could be used instead for a transaction with a much more lucrative fee than 1 satoshi.

I think your "aggregated" strategy would only work if one of the other participants was very generous and donated a sufficiently large fee to raise the average for the whole transaction to a competitive level.  You'd be getting a free ride in that case.

In theory, one could spend the dust in a transaction having only an OP_RETURN output, either of value 0 (thus leaving the 1 satoshi as a fee) or of value 1 satoshi (thus destroying the satoshi).  However, nobody is going to mine it on the BTC mainnet, as mentioned above, and for that matter nobody is going to relay it either, since it's dust.

(Incidentally, it appears that spending the UTXO in a transaction with a single P2PKH output of value 0 does not accomplish this; such an output remains spendable (!) so it doesn't reduce the number of UTXOs.  Example on the BCC testnet.  I wasn't expecting that.)


Deduct fee from transaction amount I am using sendtoaddress API call.
The problem is that I need to specify amount that includes fees.
For example, if I withdraw 1 btc, I need bitcoind to deduct fees from that amount and in example to send 0.999 as transaction amount and 0.001 as fee (or any other fee amount that recommended for this transaction)

Please, help and tell if that possible to achieve such result.

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

You can use last (5th) parameter:

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


When computing the hash, do you need anything after the number of difficulty bits? I'm going to screw up a lot of the terminology here.  I'm trying to understand the Bitcoin algortihm and wanted to use this JS miner -- https://github.com/howardchung/jsminer .  Specifically, I'm trying to understand how to build the data that someone attempts to hash.  They attempt to do this in the JS miner by the following

    var header = version + prevhash + merkle_root + ntime + nbits + '00000000' + '000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000';
    curr_block.data = header;

I'm following most of this, using the Bitcoin wiki as a reference, but what I can't figure out at all is what are these last two numerical constants -- '00000000' and the bigger one beginning with "0000008".  I have seen these come up in other examples but I can't figure out why these are needed or if these are hard-coded values in the JS miner that shouldn't be there in real life.  Any help is appreciated.

The first 00000000 is for the nonce. The nonce is changed in order to get a different block header without reselecting transactions. It is what is used primarily for finding a valid block hash.

The long string of bytes beginning with 0000008 is SHA-256 padding. It is not actually part of the block header and whatever is doing the SHA-256 hashing should figure out and append this padding for you. It is part of the pre-processing step for SHA-256.


Does bitcoin-qt support jsonrpc? After some time away, and a dead Vista PC, I have come back to Bitcoin and installed the latest (0.5.1-beta) on Windows 7. (Don't worry, I didn't lose my wallet.)

On my old machine, using bitcoin.exe, I was able to connect on port 8332 and send a jsonrpc command to back up my wallet. However, I have now forgotten the command-line parameters (if any) I used for this.

Here are the (redacted) contents of my bitcoin.conf file:

rpcuser=xxxxxxxx
rpcpassword=xxxxxxxxxxxx
gen=0
rpcallowip=192.168.2.6
rpcallowip=127.0.0.1
paytxfee=0.01

The principal symptom is this (from python):

  IOError: [Errno socket error] [Errno 10061] No connection could be made because
  the target machine actively refused it

Using bitcoind.exe, however, "it all works".

Any suggestions?

(BTW sorry for the weak tag; I don't have enough karma to create my own)

After reading the fine manual, I added these lines to bitcoin.conf:

server=1
rpcport=8332

and it appears to be working.


What are the potential attacks against ECDSA that would be possible if we used raw public keys as addresses? According to this answer about why addresses are hashes rather than public keys there are potential attacks that are possible if you have the public key rather than the address, what are these attacks? If one was writing a cryptocurrency would you advise against the addresses being the public key encoded in base58 with a checksum on the end? why?

The theory
It is assumed that in order to forge an ECDSA signature you need to compute the private key for a given public key first (this operation is known as the "discrete logarithm" (DL), and its hardness is the basis for ECDSA's security). In order to do so, you must actually have the public key.
Once you have the public key, it is assumed that you need at least 2128 operations to compute its private key. That's an enormous amount (if every computer in the world could do one relevant operation per clock cycle it would take over 100 million years; in reality it'd be orders of magnitude more than that). However, that is assuming that there are no fundamental breakthroughs in algorithms to compute the discrete logarithm, or quantum computers. A sufficiently powerful quantum computer (not anything anywhere near what already exists) may be able to do this computation much faster.
By using an address that contains a hash of the public key rather than the public key directly, the actual public key is not revealed to the world until the output is spent by its owner. Barring any (spectacular) vulnerabilities found in the used hash functions (SHA256 and RIPEMD160), even a quantum computer cannot trivially find a public key from a hash function. However, the 160-bit hashes used are still considered relatively weak in this case (280 operations on a sufficiently powerful quantum computer).
In short: the argument is that by using public key hashes, the ability for someone with a DL break, or a hypothetical quantum computer, to steal coins is made harder.
In practice
What I write in this section is my own opinion, and presumably not everyone agrees with it.
I believe this (often repeated) advantage of hashed public keys is marginal at best, and a false sense of security at worst. There are several reasons for this:

The argument only applies until the output is (attempted to be) spent. Once someone tries to spend a pay-to-pubkey-hash output, they reveal the full public key. With minor cooperation from miners, the original transaction could be delayed temporarily to give the hypothetical quantum computing attacker time to find the private key and steal the coins.
Address reuse was, and still is, very common, and apparently hard to avoid. Whenever addresses are reused, their public key is revealed on the first spend, making all future ones vulnerable still.
Almost all interesting things that people do with Bitcoin (including multisig, 2FA, escrows, payment channels, BIP32 accounts, ...) involve sharing public keys with other parties. It's an illusion to think that in such a world any security is gained by using public key hashes - as public keys are revealed all the time still, often without people even knowing about it.
Even if you restrict yourself to carefully not rely on any of these techniques and keep all your public keys actually secret until spent, there are over 5 million BTC (my own research) stored with publicly known public keys. I cannot imagine that BTC retains any value if those become practically vulnerable to theft (or even just credibly believed to be vulnerable).

This doesn't mean we have a problem. Sufficiently powerful quantum computers are far away - if they're feasible at all for the enormous number of q-bits needed to solve these problems. This gives us time to slowly migrate to schemes that are actually quantum resistant (by not using ECDSA or similar cryptography at all). This is not yet done, as currently existing quantum-resistant schemes come with very large keys and signatures, and various other caveats. This makes them very unappealing fow now, but research on them is proceeding rapidly, and, if needed, they exist.
Should you use public key addresses?

If one was writing a cryptocurrency would you advise against the addresses being the public key encoded in base58 with a checksum on the end? why?

Advice on other cryptocurrencies is off-topic here, but the Taproot proposal for Bitcoin would effectively do this. Its outputs (and thus addresses) contain a full public key, because it comes with numerous advantages (it's smaller, cheaper, and makes a number of more advanced protocols on top a lot easier).
The Bech32 address format is used for these types of outputs, which has a number of advantages over Base58 (easier to transliterate/compare, stronger error detection, more extensible, smaller QR codes, ...).
Disclaimer: I'm a co-author of both the Taproot proposal and the Bech32 standard.
TL;DR: public keys should be public.


Has there been any cases of bitcoin being stolen without getting access to the owners private key? With this question I want to exclude cases where someone is fooled to send BTC to a person (e.g. because social engineering or malware on their PC).

I have seen some arguments in comments to this Seeking Alpha article that claim that bitcoins cannot be stolen if their rightful owner is the only who has access to the private keys.

Has there been any cases of bitcoin being stolen without getting access to the private key?

For example: assuming that there is some exchange somewhere that allows a BTC buyer to manage their private keys outside of the exchange. Could it still be possible for e.g. a hacker to steal the BTC by manipulating the data at the exchange (outside of the blockchain).

Yes, for example, a company named Bitcoins Reserve lost 100 BTC when an attacker hijacked the CEO's email address and sent instructions to the CTO requesting a client withdrawal while instead providing their own Bitcoin address.

This and other incidents are described here: https://bitcoinmagazine.com/articles/cautionary-tales-bitcoin-security-1422491521/


How do I get transactions from the Bitcoin Blockchain with bcoin? Is this possible with bcoin? Do I need a full node to get transactions or does it work with an SPV?

SPV Node

SPV node watches your addresses on network broadcasts.
So on SPV Nodes you won't be able to grab other transactions then your address. It communicates with other peers, fetches your transactions using bloom filters and then watches pool broadcasted transactions. So you only get transactions that are addressed to your wallet.

Full Node

With fullnode, there are two places bcoin looks for tx:

Mempool
Chain

Bcoin will always return transactions from mempool.
If you want to get transactions from chain, either by address or by transaction Hash, you need to enable indexing: index-address and index-tx respectively.

You can check RPC docs: RPC-Docs


How does ASICMINER use the blockchain to record share ownership? My understanding is that ownership of ASICMINER shares (direct ownership, that is; not passthroughs) is recorded somehow in the blockchain, itself.

How does that work, exactly?  How can I confirm that a person claiming to have 300 shares available for sale actually owns 300 (or more) shares?   I also see people saying they "received their satoshis transaction" (in addition to their dividends payment).  I suspect that is somehow related, but that can hopefully be clarified in an answer as well.

ASICMINER management (generally friedcat on Bitcointalk) keeps records of all ownership of shares in their database. The only way to confirm ownership is either through friedcat's acknowledgment or by receipt of dividend payments. Share owners' bitcoin addresses are tied to their shares for dividend payouts.

If a share owner wants to transfer his ownership to someone else, he must provide friedcat with the new bitcoin address. With auction sales, this is typically done through a third-party escrow service for the safety of both buyer and seller.


Peergroup download of the blockchain stalls? I'm using bitcoinsharp to build my client. I try to download the blockchain in a peergroup network. Download starts, but when progress is 98%, the download is stopped & the client is waiting (2 hours without any change). The size of the downloaded blockchain file is 4.5 MB.

I use the following code:

PeerGroup peerGroup = new PeerGroup(blockStore, @params, chain);
peerGroup.AddAddress(new PeerAddress(IPAddress.Parse("84.38.65.102")));
peerGroup.AddAddress(new PeerAddress(IPAddress.Parse("83.23.15.71")));
peerGroup.Start();
peerGroup.DownloadBlockChain();

Any ideas?

The library is abandoned 7 years ago, and I don't see that anybody picked it up for maintenance https://github.com/search?utf8=%E2%9C%93&q=bitcoinsharp&type= Try to base your application on a library that is still maintained.


How is the bitcoin 21 million cap implemented? Just to check what would take for that limit to be changed. (not that I want to be changed, quite the opposite). I know the total number of bitcoin reward is halved every 4 years.

So does the verifying nodes check if the number of rewarded bitcoins match the distribution schedule?

Every node in the Bitcoin network checks every block it receives and validates any transactions in it. As coin generation is a transaction that is included in the block, it is also checked. Same as a node would not accept a transaction that does not balance its inputs and outputs (for example, by spending more coins than it has), neither would it accept a block reward different, than the one that is scheduled to occur (50 coins currently, half of that for some number of blocks, and then other fractions of that amount). The nodes know what rewards to expect based on the block number, as it is set to half based on that number.

To change it you would have to (convince people to) change all the clients, exactly like any other protocol change.


Are change addresses generated on the fly or pre-generated with wallets? What is the precedence in terms of generating new addresses?

Do wallets generate 10 on the go, then switch them out or do they generate a new one, each time the old one has been used?

Also, do they generate new change addresses as soon as they see that a transaction will need a change address?

There are different possible approaches.

Most current wallet software uses HD wallets, where keys and addresses are generated as needed from a master seed.  In this case, a change address would likely not be generated until it is needed.  A new address would be generated for each new transaction as this is better for privacy.

With Bitcoin Core, prior to the implementation of HD wallets, the default was to pre-generate 100 addresses and store the keys in wallet.dat as a "keypool". Change addresses would then be taken from the keypool, again using a new one for each transaction.  This was done so that each time you backed up wallet.dat, you would also be able to protect the keys for transactions you hadn't yet made.  Without this behavior, you would have to back up wallet.dat immediately after every new transaction - and if your disk crashed between the transaction and the backup, you would lose coins.

Some wallet software used to only generate one address and use it for all incoming transactions as well as change.  This is no longer common, though some wallets still provide it as an option.


Settling offline transactions Use Case

My use case is around a scenario where both customer and merchant possess offline wallets with a balance that has had confirmation on the blockchain.

To begin with, let us say that, the merchant and the buyer's wallets show balances of 20 BTC and 10 BTC respectively. These balances are the one that are confirmed on the block-chain.
Then, let there be multiple transactions between the merchant and buyer such that the balance is always updated locally in the wallets only.
All of the transactions, in 2 above, happen in an offline mode; i.e. no access to network. The period of no access can run into days.
Sometime, in the future, when either/both of the wallets are online, all the offline transactions are published to blockchain and are confirmed.

Blockchain Sync

There are two things that can happen at this point.

First, the wallets are so secure that, all updates (credits and debits) happen locally without ever having to 'sync' up with the blockchain. The only time the wallets may sync with blockchain is to post the transactions and their sequence; and, also to update their wallet with the credits that happened since the last time the wallet went online. Or, regulatory pressure requires posting transaction data every set frequency.

Second, all credit updates are made to the wallets via the blockchain. This requirement is enough motivation to seek network connectivity; even if it is once in a week or fewer.

Question

In either case, we are looking at a scenario, where a value, confirmed by blockchain, is used in transactions offline to be confirmed online later. How do we implement this?

Analogy

Bus conductors may issue tickets with an offline machine to passengers who board the bus at various points throughout the journey. When the bus reaches its destination, the machine is used at the depot to arrive at a list of tickets sold and the amount collected thereof. Thus, this is an example of an offline transaction where transactions are 'settled' when 'connectivity' is eventually available.

Spawned off of: https://bitcoin.stackexchange.com/a/41356/6975

I'd say there are number of issues at play here. If the system is "offline" then the only update you'll have to balances is whatever was last stored. The assumption here is both sources are trusted, and the system in the middle is trusted. Might as well make it a centralized asynchronous system. You'd have far more control and less reliance on 3rd party tools at that point.

The system proposed would be "nice" but a solution in the meantime would be to develop an internal ledger. You know party A, and party B. You know their balances, and you trust their transactions. This system assumes you know their keys as well, or can obtain them as needed.

Based on the most recent balance store your transactions in a normal DB. Running balance, again based off most recent information. Whenever the node is able to connect, update the current balances (trust but verify), check any previous transactions you may have submitted for failures (lack of gas, improper transaction, lack of funds etc), then process the transactions.

If there are A -> B and B -> A transactions then you could resolve transaction balances internally (assuming that is legal for what's intended). Otherwise you can put in all kinds of logic to resolve each transaction. To summarize:

Use an internal system for tracking what's what. What's been paid, what needs to be paid.
When node connects, get as much info as you can. Current balance, confirmed transactions from previous submissions, transactions that are still waiting to be confirmed. Identify transactions that outright failed for whatever reason (this is assuming a short 'up time' for connection with the node. It wouldn't stay connected long enough to see transactions hit the first block), still sitting in mempool (not enough gas to be picked up and go stale), etc.
Process based off the information above. Transactions will ultimately be resolved or unresolved. A FIFO can be used to resolve the oldest transactions, or if the ideal situation is to resolve the greatest number of transactions first regardless of age then a large transaction may get backlogged while many other transactions get taken care of.

This is all a matter of striking a balance of "trust" vs "timing". If i own 2 wallets, and i'm the only one with the keys, i could run every transaction in a back end system tracking what "it should be" and resolving it whenever i want.

The provided suggestion is a balance between available technology(and circumstances), security, and accuracy.


Can I mix P2PKH and P2WPKH inputs in the same transaction? I'm trying to increase my knowledge of bech32 and SegWit and to that end am working my way through this explanation.

Here's a hypothetical situation I'm trying to understand. Let's say Jamal has access to a a couple of UXTOs.

UXTO #1: 10 BTC (P2PKH)
UXTO #2: 10 BTC (P2WPKH)

Further, let's say Jamal wants to send 11 BTC to Tyrone. Tyrone provides a bech32 address of BC1_XXX.

So when Jamal constructs his transaction, he'd have:

Inputs:
    UXTO#1 10 BTC (P2PKH)
    UXTO#2 10 BTC (P2WPKH)

Outputs
    BC1_XXX 11 BTC
    BC1_CHANGE 9 BTC (a newly created P2WPKH address)

(assume zero transaction fees in this example)

Is it acceptable to mix P2PKH and P2WPKH inputs in the same transaction as described above? None of the examples I've viewed thus far have covered this scenario.

and next...

Regarding the article here: It indicates that there are two supported transaction formats:

(a) nVersion|txins|txouts|nLockTime
(b) nVersion|marker|flag|txins|txouts|witness|nLockTime

...and then later states that:

  If all txins in a transaction are not associated with any witness
  data, the transaction MUST be serialized in the original transaction
  format, without marker, flag, and witness. For example, if none of the
  txins are coming from segwit UTXO, it MUST be serialized in the
  original transaction format. (exception: coinbase transaction)

My questions are:

When would I encounter a situation where "all txins in a transaction are not associated with any witness data"? It says this situation would arise if "none of the txins are coming from segwit UTXO". But even in the case where the inputs came exclusively from P2PKH (not P2WPKH) UTXOs, wouldn't I still have witness data (i.e. the signatures) that need to be "segregated" at in the 'witness' portion of the transaction? Or is it saying that if all inputs are non-segwit, it means the transaction itself is non-segwit, and I should therefore use format (a) -- despite having segwit output(s)?

Is it acceptable to mix P2PKH and P2WPKH inputs in the same transaction as described above?

Yes, absolutely. In the same way that you can mix multisig and P2SH and P2PK inputs in the same transaction.

  When would I encounter a situation where "all txins in a transaction are not associated with any witness data"

When you're not spending any SegWit outputs.

  But even in the case where the inputs came exclusively from P2PKH (not P2WPKH) UTXOs, wouldn't I still have witness data (i.e. the signatures) that need to be "segregated" at in the 'witness' portion of the transaction?

No, those signatures would be "witness data" (in an abstract sense), but they're not segregated. Spends of P2PKH outputs require a pubkey and signature in the scriptSig of the inputs - not in the separate witness section.

  Or is it saying that if all inputs are non-segwit, it means the transaction itself is non-segwit, and I should therefore use format (a) -- despite having segwit output(s)?

Exactly. When you're using P2SH, nobody even knows the outputs are SegWit outputs, so it clearly can't matter. All that matters is whether any witnesses are needed for spending.


Wallet Out of Sync and Bitcoin transfer I bought bitcoins and sent them to the wallet, however the wallet is not synchronized and as a result I cannot see my bitcoins. Will I be able to see them as soon as the synch process finishes or have I lost them? And if I did, is there any way I can recover them?

In case of an offline wallet such as Bitcoin-Qt, you will need to be synchronised/update before you see your wallet balance correctly. The Bitcoin client will download the whole blockchain if it is the first time. Once it has been downloaded and you synchronize daily, it will be much faster to do so.

There is an existing answer on this post.


What stops miners from manipulating "target" difficulty in the block header? I am relatively new to understanding the fundamentals of the Bitcoin network, and I couldn't find the answer to my question.
I understand how mining difficulty/target is decided and calculated in the block header. (hashrate of previous 2015 blocks...)
Since the larger the target is, the easier it is to mine the new block,
what stops a miner from cheating by giving himself a large target, so that he can mine this new block very fast? Does every node check the target value when they are validating a new block?
Thank you

The difficulty target in the block header has to match the currently required difficulty. This value is derived and checked by each node individually from the timestamps and difficulty statements of previous blocks. Then, the block hash of a new block has to adhere to this given difficulty target. If either of the two requirements is not met, other nodes will reject a block as invalid.
So, if a miner ignored either of the rules, they'd of course be able to do that, but then their blocks are simply not accepted by the Bitcoin network.


Can private keys be exported more than once in Electrum client so long as the've not been spent? Assuming one exported the private keys from one's offline Electrum wallet to a CSV file (also offline), they obviously have not been 'spent'. The whole thing was done offline. My question is this: if I were now to go online and try to spend the bitcoins covered by those private keys, are the bitcoins still there? Or does the exportation of the private keys to the CSV file equal the spending of those coins so far as the Electrum client is concerned? To put it another way, can the private keys be exported more than once so long as they have not been spent? I'm hope I'm explaining myself clearly.

[I recently made my first Bitcoin purchase and I did so into an Electrum wallet, which I am currently keeping on an offline computer. I could not see my private keys anywhere and was unsure that I'd received them and so I exported them to the CSV file purely to ascertain that I had, in fact, received them. (I would not do so on any future purchases, now that I'm confident that the private keys would be there to be generated from the seed since they are plainly more secure unexported from an encrypted wallet than on a CSV file, but, hey, my first time and no evidence or explanation that I indeed had received them ...] - Terrylei

It seems like you don't understand how Bitcoins, private keys and bitcoin addresses work, so I'll make it simple:

As I explained to you here https://bitcoin.stackexchange.com/a/11479/2467 , you should not (more like MUST NOT) export your private keys from an Electrum seed. This can compromise all your private keys.

Your private keys are derived from your seed every time you make a payment to sign the transaction. So there's no need to see them, the client calculate them for you, use them, and hide them again. all you need is to keep your seed safe.

If you want to know the balance in your offline Electrum wallet's addresses you can use a seedless wallet on an online computer. To do that look for your Master Public Key in the offline Electrum, and restore from your MPK on an online computer.

You don't need your private keys to know the balance on their public addresses anyway. Public addresses are public and if you have already received on them, you can check their balance on Blockchain.info


Did pools verify constantly the ouput of createrawtransaction when they build their coinbase transaction? Pools creates their own coinbase transaction to pay their selves, and they begin the PoW by hashing different Headers, what prevent a hacker from changing the createrawtransaction with different output (His bitcoin adress instaed of the pool bitcoin pool adress)?
How pools can know that the header they are providing for miners contains a merkle root which contains a coinbase transaction created with a valid ouput (Their bitcoin adress and not another adress)?
Thanks

With the Stratum V1 protocol in use today (and the Stratum V2 protocol as it is currently proposed), mining pools actually send the parts of the coinbase transaction to their miners for those miners to modify. Specifically, they reserve space in their coinbase transactions for miners to use as an extra nonce. Those miners will construct the coinbase transaction, insert their extra nonce, compute the merkle root (they are given merkle branches to be able to complete the merkle root), and then create the block header.
However when the miner submits their work, they are only submitting the pieces that they added - namely the nonce, the timestamp, and the extra nonce. The pool will then reconstruct the coinbase transaction with the given extra nonce, reconstruct the merkle root, reconstruct the block header, and verify that the block header meets the PoW requirement for that miner. If the coinbase transaction had been modified by the miner, or by an attacker who sits between the pool and the miner, then it is unlikely that the block hash they calculate for that submitted share will meet the PoW requirement for that miner.
It is unlikely that miners are using createrawtransaction for creating their coinbase transactions as it is unable to do so anyways. createrawtransaction does not allow the caller to set an input's vout to be the right value for a coinbase transaction. So mining pool software are most likely creating the coinbase transaction internally rather than outsourcing it to bitcoind. In that case, they will be using the correct outputs. If they aren't, then either something is manipulating the coinbase transaction after the pool sends it but before the miner receives it, or the attacker is able to directly modify the pool software's memory.
In the first case, the PoW checking I described earlier is the protection. In any case, the pool can't really do much about an external entity (by external, I mean external to the pool software, it could still be running on the same compromised machine) modifying the coinbase when they send it out. In the second case, the pool can't protect against that as the attacker can just always make the software think that their coinbase is correct.


How do you create a scriptsig for a new raw tx? Could someone please explain how to do this is in a detailed step by step manner that correlates to a real linked transaction such that a n00b can comprehend?  Is it just copy and paste a particular identifiable portion of the previous tx from the raw tx thereof or is it more elaborate?

Okay, turns out my research has led me to answer my own question, mainly from here though it did lack a bit of explanation or didn't explain, I think, as clearly as it could.  So here's my reading/interpretation/translation thereof.  (Go to that page to see the source of my data if need be).

NOTE:  This process may have changed after the addition of "segwit" either in its "lock-in" or its "activation".  I cannot speak to that.

A Quote from that page:

  The final scriptSig contains the signature along with the public key for the source address (1MMMMSUb1piy2ufrSguNUdFmAcvqrQF8M5). This proves I am allowed to spend these bitcoins, making the transaction valid.

Step 1.  The signature in a given transaction will begin with 473044
(these are standard from what I can see).

Step 2.  Then you must append 0120 to the end of that number to get 4730440120

SIDE NOTE: There are variations upon this which are demonstrated in old transactions and may still exist where you do NOT put that in and you put a different number instead.  I cannot account for and or explain those instances except to say that the "01" designates this as the first integer, and "20" designates the integer length of 32 bits (the "20" is in hex, just convert it to integer to get 32).  32 bits means there are 64 hex alphanumeric characters (0-9 and or a-f).

Step 3. Then you must append the hex value of "r" from the ECDSA signature (which is 2cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff713), resulting in:
47304401202cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff713

Step 4. Then you append '0220' to the end of the previous code, resulting in
47304401202cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff7130220

SIDE NOTE: There are exceptions to adding merely "0220" that may exist or have existed in previous transactions throughout the block chain.  The only tool I can give to explaining them is the "02" is in reference to the "second integer" and the "20" designates the integer length of 32 bits (the "20" is in hex, just convert it to integer to get 32).  32 bits means there are 64 hex alphanumeric characters (0-9 and or a-f).  This is just as the "0120" is.  So if there is a third integer I think it would be preceeded by a "03" and if the integer is longer or shorter than 32 bits (or 64 hex alphanumeric characters) then the "20" should be changed to the hex value of half the number of the hex alphanumeric characters.  Just count them, divide by two, then convert decimal to hex to get the correct number to place here, if the need were to arise.

Step 5. Then you must append the "s" value from the ECDSA signature (which I will not get into in this post) which is 6c6624d762a1fcef4618284ead8f08678ac05b13c84235f1654e6ad168223e82
Resulting in:
47304401202cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff71302206c6624d762a1fcef4618284ead8f08678ac05b13c84235f1654e6ad168223e82

Step 6. Next you append a '01" which is "SIGHASH_ALL".  I don't know what that really means or fully stands for.

Step 7. Append "41" which is "Pushdata41".  I don't know what the really means or fully stands for.

Step 8. Append "04" to reference the type of public keys you are going to represent for the public key that this transaction is coming from.

NOTE:  "04" is in reference to a particular uncompressed "public key".  Bitcoin usually uses "02" at this point in time.

STEP 9. Append the X value followed by the Y value of the public key, in this case the values are:
14e301b2328f17442c0b8310d787bf3d8a404cfbd0704f135b6ad4b2d3ee7513
and
10f981926e53a6e8c39bd7d3fefd576c543cce493cbac06388f2651d1aacbfcd

NOTE:  If you were using a compressed public key, you would only show the first one.

Result:
47304401202cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff71302206c6624d762a1fcef4618284ead8f08678ac05b13c84235f1654e6ad168223e8201410414e301b2328f17442c0b8310d787bf3d8a404cfbd0704f135b6ad4b2d3ee751310f981926e53a6e8c39bd7d3fefd576c543cce493cbac06388f2651d1aacbfcd

I did not go into the S or R creation as I felt that they should be done in a separate post to keep things organized.


BITCOINJ: how to make my wallet aware again about change of my transaction status after my server restart? Using bitcoinj, my server created a transaction and it was broadcasted on the blockchain. I can get its history using: walletAppKit.wallet().getTransaction(txHash)

It is in Pending state.

Then I stopped my server before the transaction get confirmed.

Then I started the server again, and I was still getting Pending status when calling walletAppKit.wallet().getTransaction(txHash), although the status is well confirmed on explorer like https://live.blockcypher.com/

I understand that when server was down, there was no more listener for change events on that wallet/transaction. But the question is how make my wallet aware again about the new change of my transaction status after my server restart?

(I am on TestNet by the way)

Try synchronizing your wallet again, you can delete the file .spvchain


Bitcoind estimatesmartfee I am trying to get transaction fee for sending all btc to another account.
I use estimatesmartfee to get tx fee, I have total btc amount of 0.0195btc, so I pass 0.0195, but I get JSON integer out of range (code -1)

estimatesmartfee expects the number of blocks you want the tx confirmed in as the parameter, not the amount of BTC you are sending.

Try estimatesmartfee 5 to get an estimate for confirmation in the next 5 blocks, for instance.


Send payment from one user to another via API? I am looking to have users on my website submit their  bitcoin id and be able to accept bitcoin from other bitcoin user as donations.

I am brand new to this. I'm using PHP.

So basically this is what I want to happen.

User A signs up on my website and gets a profile

User A enters their bitcoin address that they want to accept payments to

User B goes to User A's profile and selects to send bitcoin to them

My backend PHP code facilitates the payment from User B to User A and gets notified of a successful transaction.

From what I'm reading there are multiple places someone can have a wallet. Is there a centralized way to send to and from any wallet?

If User A enters their bitcoin address to where they want to receive payment, User B can directly send to User A. There's no need for you to facilitate the transaction.


Is it possible that the authors of Bitcoin have an alternative way of generating bitcoins? Is it possible that the Bitcoin creator (or developers) have an algorithm that allows computers to generate coins easily, but intentionally published only the current difficult mining algorithms. And, in that way, have left themselves a backdoor way of generating bitcoins once the algorithm became popular?

Your question is equivalent to asking, "Does SHA256d have a trapdoor?"

SHA256d is a well studied algorithm.  It's believed not to have a trapdoor.

If the creator of bitcoin has a way to break SHA256d, stealing all our bitcoins would be the least of our worries.


Compiling Maxcoin and its clone cryptos throw an error I compiled Bitcoin, Dogecoin, and many other pow/pos cryptocurrencies without a problem. I usually compile daemon and then windows-qt wallet using qt 5.2.

But maxcoin and its clones like Helixcoin and galleoncoin always throw this particular error once I have compiled and run on windows 8. QT4.8.5

the procedure entry point memmove s could not be located in the dynamic link library msvcrt.dll

coin daemon compiles and runs without a problem. And I downloaded their pre compiled windows-qt wallets from official websites and they work fine.

this is my config for compilation

BOOST_LIB_SUFFIX=-mgw48-mt-s-1_50
BOOST_INCLUDE_PATH=C:/boost-1.50.0-mgw
BOOST_LIB_PATH=C:/boost-1.50.0-mgw/stage/lib
BDB_INCLUDE_PATH=C:/db-4.8.30.NC-mgw/build_unix
BDB_LIB_PATH=C:/db-4.8.30.NC-mgw/build_unix
OPENSSL_INCLUDE_PATH=C:/openssl-1.0.1c-mgw/include
OPENSSL_LIB_PATH=C:/openssl-1.0.1c-mgw
MINIUPNPC_INCLUDE_PATH=C:/
MINIUPNPC_LIB_PATH=C:/miniupnpc-1.6-mgw
QT4.8.5

This is the source I am working on
    https://github.com/HelixCoin/

I have already looked through all of the files and I do not understand the cause of this error. And there is not much help on internet.

So I finally decided to give up trying to use qt 4.8.5 and helixcoin and galleoncoin github sources. And used qt 5.2.0 with slothcoin source from github. Which worked fine. And qt wallet started without a problem. Though I still dont understand why was qt 4.8.5 not including the msrvct.dll file. maybe that these libs were never included in qt 4.8.5? Seems to be compile fine on windows 8.1 and ubuntu 12.04 :)


In a chain split scenario (not soft fork), a miner has to confirm transactions from both chains? In a scenario where a chain split occurs (two miners find a hash), would miners have to work with both chains until one of then become larger (more PoW)? i.e. Would they have to validate transactions from both chains as 1 confirmation until then?

No they don't. Miners only work on one chain.

In a chain split scenario miners are divided: some work on a chain and the others work on an other chain (both chains are correct, but they have a different last block). The miner who find the next block makes its chain the correct one because it's now the longest.


Bitcoin trading in Cyprus Hey guys is there any way to find out how much trading in bitcoin goes on within an individual country? I'm specifically looking for info on the country of Cyprus.

Here is a link from where you can get some ideas about Cyprus trade of Bitcoins. https://localbitcoins.com/country/CY


What is the default relaying policy for RBF double spend transactions? Let's say I broadcast a transation tx0 signaling RBF replaceability. Later on, I realize it has a small amount of fees, so I send another transaction tx1 that spends the same inputs than tx0, but this time with higher fees.

Which is the default bitcoind/bitcoin-qt behaviour regarding the relaying of tx1? Would all nodes broadcast the new version of the transaction or does the relay policy depend on the mempoolreplacement parameter? Do any special rules apply to the relaying of the replacement transaction?

I have seen that Peter Todd's RBF proposal included a NODE_REPLACE_BY_FEE service bit. Is anything like this included in the current version?

Nodes will only relay if mempoolreplacement hasn't set to false (most nodes probably do relay because the default is true).
There are serval rules for accepting a replacement after BIP125 (check the BIP for more details). In general: The replacement must pay greater fees than the transactions it replaces - if we did the bandwidth used by those conflicting transactions would not be paid for.


I built a miner, got a hash block, now what? Where do I send it? So as an exercise I want to build a mining client, just because I'm curious.

I understand that I'm supposed to create a hash, but once I have the hash, where do I send it?

How do I submit it back to the block chain?

To submit a valid block to the block chain you don't use the hash, just the block. That's the block header plus the transactions.

Use bitcoind's submitblock RPC call.

> bitcoind help submitblock
submitblock <hex data> [optional-params-obj]
[optional-params-obj] parameter is currently ignored.
Attempts to submit new block to network.
See https://en.bitcoin.it/wiki/BIP_0022 for full specification.

So you hex encode the block and send it as lone parameter to submitblock. That's all.

As the help text says, submitblock is further documented in BIP22


How much is this in GH/s? I Hope i can get some help from you.

when i have 2.43 TH, how much is this in GH/s?
I'm complete confused, cause i tried to find out, how much is this.
Can someone tell me how much GH/s this is at two decimals?

Also i was looking for Hashcalculator on web, but i dont find any calculator where i can change my hashrates to other...

I find this, but i dont know if its right.

1 MH/s = 1,000 kH/s
1 GH/s = 1,000 MH/s = 1,000,000 kH/s
1 TH/s = 1,000 GH/s = 1,000,000 MH/s = 1,000,000,000 kH/s

and how much is 2.43TH/s in GH/s with 2 decimal

2.43 TH/s is 2430.00 GH/s. The conversion chart you have is correct.


How do I use my Bitcoin-Qt wallet address on Blockchain.info? My Bitcoin-Qt client is still synchronizing with the network. I'm unsure of how to use my Bitcoin-Qt wallet address on Blockchain.info. I've put my address on Blockchain.info as (watch only), but how do I get full access to my wallet on Blockchain.info?

I do have a passphrase and the wallet is locked. Does Bitcoin-Qt need to be fully synchronized with the network for me to be able to access my wallet?

You have to unlock your wallet, export the private key for your address and then import it to Blockchain.info. You don't even need Bitcoin-Qt then, because they store your privkey and your money!


getblockcount is returning incorrect count I am very new to bitcoin but finally managed to get it all installed and compiled. I am following along with Mastering Bitcoin.

There is an example to use getrawtransaction as follows:

bitcoin-cli getrawtransaction  0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2.

I get the error no such mempool transaction. Using block explorer, this transaction appears in block 277316.

I noticed that when I run bitcoin-cli getblockcount, I only get 180024, which was mined in 2012. Why am I getting such old data?

I get the error no such mempool transaction. Using block explorer, this transaction appears in block 277316.

Unless you're running with the -txindex command line option, or a txindex=1 line in your bitcoin.conf file, getrawtransaction only works for mempool transactions (not transactions already in the blockchain).

  I noticed that when I run bitcoin-cli getblockcount, I only get 180024, which was mined in 2012. Why am I getting such old data?

Presumably your bitcoind is still synchronizing with the network. This may take hours (or even days, on slow hardware).