In Bitcoin QT 0.12 for Windows, how do you whitelist an IP address? I believe the answer is that you enter the command line option whitebind for IPV4 or whitelist for IPV6.

When I tried it, I first got a message that I needed to include the port, so I included the port, but then I got an error message saying "Unable to bind to {IP.Add.re.ss:Port} on this computer (bind returned the error The requested address is not valid in its context. (10049))."

I did a search for whitelisting multiple IP addresses and didn't find any results, but through experimentation, I determined that repeating the command line option multiple times works, at least to get the errors I describe above.

There are 4 options (either command line or in the bitcoind.conf file) that have to do with whitelisting. I myself have only used whitelist where you simply specify the IP address (IPv4), without port number.

-whitelist=192.168.10.20

According to the documentation you can also specify a netmask, which I haven't used yet, but should be in this format if I'm not mistaken:

-whitelist=192.168.10.0/24

  -whitebind=
         Bind to given address and whitelist peers connecting to it. Use
         [host]:port notation for IPv6

  -whitelist=
         Whitelist peers connecting from the given netmask or IP address. Can be
         specified multiple times. Whitelisted peers cannot be DoS banned and
         their transactions are always relayed, even if they are already in the
         mempool, useful e.g. for a gateway

  -whitelistrelay
         Accept relayed transactions received from whitelisted peers even when
         not relaying transactions (default: 1)

  -whitelistforcerelay
         Force relay of transactions from whitelisted peers even they violate
         local relay policy (default: 1)


Why did the remaining money go to another address? I'll try to be short.
I gifted 1 BTC to a friend several months ago. She is a completely non-technical person. She tried to send a small fraction of that 1 BTC to her brother, and either she seriously messed something up, or fell a victim to some attack.. I never had a reason to use the Blockchain Explorer, but now that I want to try and figure out what happened to her 1 BTC, this is what I see when looking up her Wallet's address in there:

1) A transaction where I send 1 BTC to her:

{transaction id xxxx}              ===>    16WE..<her address> (Spent)   1 BTC
1HHj..<my address> (N BTC Output)          1HHj.. <my address>(Unspent) N-1 BTC

That's what I've expected to see - I've started with N BTC, spent one, it's now in her wallet, and I got N-1 left.

And here's the 2nd transaction (of the only 2 associated with her wallet):

2)

{transaction id zzzz}               ===>    14vg..<her bro's address> (Unspent ???!)  0.0001 BTC
16WE..<her address> (1 BTC Output)          15Hn..<WTF? who's that?!> (Spent) 0.9999 BTC

Well, F&#@. Whatever they did (I should've looked over her shoulder...), the dude got the fraction of the 1BTC which was intended for him - but why the rest ended up in some wallet other than the originator's (as it happened in (1) above).

I don't she'd unknowingly did the "advanced send" stuff, which does allow multiple target wallets.. but anyway, she's not technical, but she ain't dumb to place some random wallet into the 'To:' box.. and being very new to the whole explorer business, being a little confused, but I want to know what happened. Why her bro's wallet has "Unspent" next to it, unlike in the first transaction, is just one of the questions. Where could the second wallet come from is another, obviously.

Thanks!

What you are observing is a change address.

The wallet created a new address for itself to send the change of spending the 1 BTC to. This is so that it is non-obvious to the rest of the world which is which. The 0.9999 BTC is still hers to spend, just assigned to a different address.

And it is working: if you didn't know she was sending to her brother or his address, you would not be able to infer anymore how many BTC she holds.

  I never had a reason to use the Blockchain Explorer

You generally never have to. The problem is that explorers do not know your wallet. They present a lower-level view of what is going on in the system than your wallet does, which can be confusing.

Read more: Why does Bitcoin send the "change" to a different address?


A more updated address clustering method? say i have a transaction details of one address from blockchain info. is there a more updated heuristics for address clustering ? i.e. if a transaction has 2 output which address belongs to a different entity and which one belongs to the same entity(if there is any)
thanks

Many wallet software obfuscate the information about payment and change address in order to protect the privacy of the user. When you see block explorer websites showing addresses in the outputs as change addresses, they are merely guessing as there is no sure shot way of knowing. Some of the techniques used to identify change addresses are below. I have also mentioned the current steps taken to prevent detection of such change addresses.

Sending change back to the same address: If you send the change back to the same address from which you are initiating the transaction, then there is high likelihood of that address being a change address. This is mitigated by preventing address re-use.
Change goes back to the same address type: If you initiated a transaction from a native segwit address (addresses starting with bc1) to a P2SH address (starting with 3). In some wallets, the change will be sent to the native segwit (bc1) address as that is the default for your wallet, thus leaking which output is the change. This is prevented by making the change address match the format of the payout address in order to mask privacy.
Coin selection: Assume you want to make a payment of 5 BTC for your coffee (let's hope that the coffee is that good :-)). Your wallet contains two UTXOs: 4 BTC and 3 BTC. To make a payment of 5 BTC, you will have to use both UTXOs and send 2 BTC change back to yourself. Now, the person looking at this transaction would think that if you wanted to make a 2 BTC payment you would have just used your 3 BTC output and sent 1 BTC as change as compared to using both the UTXOs. Thus it is revealed that the 2 BTC is in fact a change output rather than a payment output. Wallet softwares might create two or more change addresses in order to mask which is exactly the change address, or if multiple UTXOs exist, it will optimally select those UTXOs in order to prevent such leak.
Change address is the last output: If you build your transaction in such a way that your payment addresses comes first and change comes last, then it reveals which of the output is a change. For example, Bitcoin Core had a bug years ago, where it would never put change first despite randomization, which for single-payment transactions resulted in a deterministic position of change address (second). To prevent such deterministic ordering of change address in outputs, BIP 69 recommends lexicographical ordering of inputs and outputs. Outputs are arranged in ascending order of the amounts, followed by the scriptPubKey.


CPU mining in the background I am thinking of doing cpu mining in the background when users are on my website. Also I am thinking of building a program which does everything in the background(cpu mining), that users can download and run. How much percentage of cpu should i mine for the users to not experience any glitches on their computer? I know it should also depend on the cpu power of the machine but what would be the average percentage that I should take over for this purpose?

First of all, I would recommend that your users are informed that you will be doing CPU mining in the background while they browse your site, and that they agree to let you do this.

Secondly, you should not be CPU mining Bitcoin or any altcoin for which GPU mining or ASIC mining exists. CPU mining is much more inefficient than GPU miners or ASIC miners so you both won't earn much even with thousands of users, and potentially cause irreparable damage to your users' computers.

The best way to find the optimal percentage is to try it out yourself. Write your website software and other software and test it locally on your computer. Adjust it so that the parameters are what you are comfortable with. Keep in mind that the computer's cooling solution will need to work harder and the additional fan noise may not be acceptable to everyone. Once you find something that you are comfortable with (i.e. slowdown in other tasks is acceptable, CPU fan noise is acceptable, etc.), undercut that percentage by a bit.


How is the Target Hash determined? So, I understand how the amount of leading 0's are calculated, but how is the hexadecimal that come after the leading 0's calculated? For example, the previous mined blocks hash was
000000000000000000084bc771b929b0780276b1c31cec10a96921b1e53b970a but how was the 84bc771b929b0780276b1c31cec10a96921b1e53b970a after the 0's determined?
I saw this answer: https://bitcoin.stackexchange.com/a/36228/110284 but I'm not gonna lie, I didn't understand it.

I think you're confusing a few things.
A SHA-256 hash is a single value that is 64 hexadecimal characters long. This hash can be seen as simply a very long number.
A target hash in cryptocurrencies is the maximum value that a successful block hash should be. Miners are aiming to generate a block where the hash, when seen as a large number, is a smaller number than the target hash.
The entire thing 000000000000000000084bc771b929b0780276b1c31cec10a96921b1e53b970a is a block hash. It is a SHA256 hash, and just happens to be a number that contains a lot of zeroes.
If you want to see how the block hash is calculated, take a look at this article: https://en.bitcoin.it/wiki/Block_hashing_algorithm


What OpenCart plugins are available or in the works for Bitcoin transactions? I've installed the walletbit module in my installation of OpenCart but any others would be appreciated, especially if someone's working on MTGox/Tradehill integration! Is there much in the works or anything I've missed?

There is an extension for bitpay (bit-pay.com) that can be found here.

Bitpay allows merchants to accept bitcoins but to be paid in dollars which can be very convenient for merchants who are interested in trying out Bitcoin but might not yet be convinced of its greatness.


Does an unopened encrypted Electrum wallet relay its addresses/transactions to nodes? I have Electrum 3.1.3 (windows) installed with an encrypted wallet, which is accessed over a VPN.

The Issue:

I accidentally opened the Electrum program without VPN protection, but the encrypted wallet (default_wallet) wasn't opened (i.e. I didn't enter the wallet password to open it).

So, is there a chance that the wallet addresses got relayed to electrum nodes with my non-VPN ip-address and in turn got compromised?

Reason for the question

When the Electrum program was clicked open, a lot of network packets were send & received, even though the wallet wasn't open.

No because until you provide the password at the start Electrum can't decrypt your wallet file so it doesn't know your addresses and can't query a server about related transactions. This only applies if you are using full wallet file encryption. You know you are doing that if you are asked a password at the start and not just when you try to spend your coins.

Another way is to go to wallet menu > password. The encrypt wallet file option should be checked there. A third way would be to go to file > save copy and examine the saved file in a plain text editor. If you find that it's all random unreadable characters (ciphertext) and not JSON code then you have full wallet encryption.

BTW you can configure a socks proxy under tools > network > proxy tab. If you configure a socks proxy that can only be accessed via your VPN you will never make the mistake of connecting without a VPN. However, note that a VPN does not anonymize you. It just prevents censorship. If you want anonymity use Tor but also note that all bitcoin transactions are public so it can never be truly anonymous.


How to code the Simplest BitCoin CPU Miner? How would I go about making the simplest form of a CPU bitcoin miner? I have not been able to find documentation on the whole process...

If you're fluent in Python, there is a reference RPC miner, written by one of bitcoin's developers: https://github.com/jgarzik/pyminer


What is the typical size for an extended public key? What is the typical bytesize range for an extended public key?

An extended private key?

An extended public or private key is always 78 bytes of data. When Base58 Check encoded, this results in a string that is up to 112 characters in size.

The format of the data is defined in BIP 32.


In a mining pool, can there be any two or more nodes mining a block using the same nonce? Me and my friend decided to try to mine cryptocurrencies using somewhat old (few years old) unused but somewhat decent gaming PC. We decided to create or join a mining pool to double our processing power.
Since, the coin reward in mining pool is gonna be divided by members of a pool.
I wonder, if there is a possibility for two or more nodes in mining pool to mine a block using the same nonce?
I am guessing that this is not an efficient strategy to pool mine. It would create a sub-optimal strategy to pool mine, because if two or more nodes that are supposed to work together, are gonna waste power to calculate a block using a used (calculated) nonce- that is already used (calculated) by your friend in the pool.
This would even decrease the doubling (multiplication) of computing power.
In fact, there would not be any different that non-pooled miners (all competing to calculate the valid hash). Except that pooled-miners need to split the rewarded coins, while the non-pooled miners would keep all their rewarded coins. Am I correct? Or do they (competing miners) even coordinate and mark used (calculated) nonce across the network?
I am sorry, if I haven't completely understood the details yet.
In pool mining softwares, do they prevent this (calculate using same calculated-nonce) from occurring in general, like do they (the mining software) coordinate the nodes to mine using different nonces? Is there a protocol (rules) to prevent this from happening in bitcoin or any other cryptos in general? Or will it be just implementation dependent? If so, how to find mining software that could coordinate pool mining in an efficient way?
I am still quite new in cryptocurrencies in general, I am sorry if there are any mistakes in my understanding, I am greatly thankful if you could correct them.

As I understand this. The nonce is the response to the mining hardware. Nodes process transactions AND this is not mining. The mining produces the nonce the core adds transactions and distributes them (according to block level).
This is an artifact of early bitcoin development from pre-2010 release of "theory technology". You would have a hard time finding any information on this now a days. Good luck @ the onion.


Are the bitcoin miners decreasing in quantity and increasing in size? From what I am learning about bitcoin, the mining process is becoming exponentially difficult and hence exponentially more expensive (or at least more expensive), as people need more physical resources. As a result, there is an aggregation of miners (i.e. small players merge or get acquired by big ones or just go bankrupt).
Will this result in a decreased number of miners and an increased miner size, which can be a potential bottleneck for the currency?

P.S. A bottleneck, as a lower number of miners increases the risk of collusion and jeopardizes the security of the currency?

The difficulty is not rising exponentially, but it does keep going up.

Bitcoin miners have definitely gone from a large group of small miners to a small group of big miners.

In 2010 GPU (graphics card) mining made it hard to mine on CPUs. Sometime 2011 CPU mining became pointless. This meant office PCs could no longer take part in mining. Intel graphics (built into Intel CPUs) and Nvidia were both pretty bad at it. So it really meant mining was now only for gaming PCs with AMD graphics.

In 2013 Bitcoin ASIC (application-specific integrated circuit) miners appeared. Sure, some mined on FPGAs before this, but FPGAs didn't make that great an impact before ASICs arrived and killed off both GPU and FPGA mining. Now bitcoin mining was only for people who bought specialized bitcoin mining hardware.

In 2009 anyone could mine 50-100 bitcoins per day on an old laptop. After the transition to ASICs in 2013 you couldn't mine without specialized hardware.

This has greatly reduced the number of people who are able to mine.

Competition is also getting very fierce and margins are slim.

Some miners design their own ASIC chips and build their own miners with these chips. If you buy your miners from them, how can you compete on acquisition cost of miners?

Some miners have special deals with their power company. Can you get electricity cheap enough to compete?

Some say Bitmain uses Asicboost, which gives them a huge advantage. The only way to compete with Asicboost is to use Asicboost. Do you have a setup capable of using it? Will you risk a lawsuit? Yes, strangely someone has a patent pending on this simple software optimization.

Some mining operations are in very cold places like Iceland. Cooling is probably more expensive for you than for them.

The fiercer the competition, the fewer are able to stay in the game.

I wouldn't call this a bottleneck. But it is a security risk. With the majority of hashrate in China, the Chinese government can 51% attack bitcoin. Bitcoin scalability may also have been achieved more easily without huge mining entities that can veto every proposal to improve bitcoin.


Legal issues / banking issues selling Bitcoins to people OTC? I'm wondering what the practical / legal limits are on selling Bitcoin as an individual using Craigslist and LocalBitcoins. Will I run into legal issues / frozen bank accounts as I scale this? Right now I'm doing about $1K of selling per month, but I could see that expanding to $1K - $3K per week.

I take all the payments in cash, so this will be 1-3K per week in cash going into my credit union ATM.

Note: This is a US-centric answer. Other countries may differ. I'll add other countries as people leave comments.

There is an arbitrary limit of $1,000 per person per day that triggers the necessity to register as a money service business. Stay under that FinCEN is unlikely to care about you, although you still may legally need to register for smaller transactions.
As long as a single transaction does not exceed $10,000, your financial institution should not file a Suspicious Activity Report.
You are best opening an account at an institution separate from your personal, general use accounts.
Try to keep cash liquid. Buy local, sell local. If you've got enough volume, use money orders to get fiat into your exchange of choice. It'll cut into your profits a little, but it reduces the number of parties privy to your transactions. Do not fraudulently fill out money orders.
Keep solid books that include the fiat price at the time you purchased your bitcoin and the price of sale. This will help you calculate capital gains taxes.
Pay taxes. Assuming you're in the US, this means paying taxes quarterly instead of yearly, unless you expect to owe less than $1,000.
If you do register with FinCEN, please document the process and broadcast here, on BitcoinTalk, and on /r/bitcoin.
Be truthful, upfront, and, most of all, careful. When in doubt, talk to a lawyer.


Programmatically, How does Bitcoin core differentiate transactions category? How does Bitcoin core differentiate transactions category?

for instance, when we are calling listtrnasctions in the response body we have category, how bitcoin core assigns category type for a transaction?
Programmatically, How it decides that some transaction should have send or receive string.

The answer is in here:

// Sent
if ((!listSent.empty() || nFee != 0) && (fAllAccounts || strAccount == strSentAccount))
{

}

// Received
if (listReceived.size() > 0 && wtx.GetDepthInMainChain() >= nMinDepth)
{

}

Can someone read and explain the code? I see that receive transactions have zero fees, and Bitcoin core considers transactions with fees as sent.

Bitcoin Core has three types of transaction categories: send, receive, and move.

It differentiates between these as follows:

move - This tx is not an onchain one, and has no transaction id. It is simply moving BTC from one wallet account to another (accounts are not addresses, but groupings of addresses). This is done using the move RPC call
send - A send tx is one where an utxo from your wallet is used as the input to a transaction. This usually have a fee, since the fee is debited from the total sum of the utxos.
receive - A receive tx is one where a new utxo spendable (or watched) by your wallet is created. These don't have a fee as you don't pay anything to receive Bitcoin.

You can see the ListTransaction code here.


How to create a valid unsigned transaction How can I create a valid unsigned transaction which can be broadcasted and mined using these addresses?

Could someone create the raw transaction and show me?

sender's address: 1NsRUK6vmPbtQa8sSjeXVxeYQiGCGNi6W3

receiver's address: 37KSBUjixDYxmgmTdepb79aso69vPZrLu2

Note: These are both my addresses and their balances are 0.

This is not how Bitcoin works.

Bitcoin does not use an accounts system nor does it use addresses on a protocol level. Spending Bitcoin means that you are spending from a transaction output. If there is no available transaction output for you to spend from, then you cannot create a transaction. So with addresses with 0 balance, no such valid transaction can be created.

Next, the "sending address" that you specified requires a digital signature in order to spend outputs associated with it. This is because that address type tells wallets that an output should be created which has the form OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG where the address encodes the <hash> and the type of address specifies the other opcodes. So you cannot spend outputs that are associated with this address without being able to provide a valid digital signature that corresponds to the public key that hashes to <hash>.

What you could do is have a transaction output whose script is something like OP_DUP OP_HASH160 <hash> OP_EQUAL. This does not require a signature, but such a script, even though it can be constructed with the provided address, does not correspond to that address because it does not have the construction that the address type specifies.

Thus it is impossible to create such a valid unsigned transaction because 1) there is no output to spend and 2) the address requires a signature in order to spend from outputs associated with it.

Such a signature-less script as a I described corresponds to no address; there is no address type that specifies it.

The output script would look like this:

76a914ef0ffa5f1cc59bed17cf4e35ae9cbf396cddf17088

A transaction spending from that script would look like:

0200000001deadbeef000000000000000000000000deadbeef00000000000000000000000000000000222103061e97605659c9dc77ed437cbc345ec41633888ae3b2c75fdd532db789cc476fffffffff01000000000000000016a914ef0ffa5f1cc59bed17cf4e35ae9cbf396cddf1708700000000


Is cgminer used for both bitcoin and litecoin GPU mining? I'm trying to figure out which software to download for my Ubuntu 12.04 box to start some litecoin mining.  Via google search, I keep coming up with cgminer for both bitcoin and litecoin mining.

How does that work, is the same software cgminer used for both bitcoin and litecoin mining?

Cgminer can be used to mine both LTC and BTC.  When executed to mine Litecoin one would need to add the command line switch --scrypt  It is also worth noting that the last version to support GPU mining and scrypt is version 3.7.2  Versions after that have all GPU mining capability removed.


Samourai Wallet 0.96.03 APK file The release page for Samourai Wallet 0.96.03 lists an APK hash but does not have a downloadable APK file.

From the available zip or tar.gz files how can I locate (or create) an APK file to compare against the hash listed in GitHub?

Apparently you can only download via the PlayStore for Android 5.0+. However they will have an apk out when they release the 1.0 version and it'll be available on F-Droid.


How does SatoshiDice operate with 0 confirmations? I understand they use your bet as an input, but what does that mean and how do they do it? Can they use the standard bitcoind as a server against which to run the API from?

This is oversimplified, but here's one sequence showing a serie of payment transactions:

Miner --> You -->  Me -->  SatoshiDice --> Me

So you send half a bitcoin to me and I use a client that lets me send it instantly to SatoshiDICE.   SatoshiDICE then includes at least part of that payment in their win or loss return payout.

Once your payment to me confirms, then mine to SatoshiDICE can confirm.  Once my payment to SatoshiDICE is confirmed, then their payout back to me can confirm.

So if you cheated me and your payment to me was a double spend it will then never confirm (reaching 6 confirmations).  And in turn, my transaction to SatoshiDICE will never confirm.  And in turn, the SatoshiDICE payout transaction back to me will never confirm.

So it doesn't matter that I saw a payout transaction from SatoshiDICE right away, I can't spend it anywhere until it confirms.

Because even a transaction with one or two transactions can get orphaned due to a block reorg and a double spend attack, even if you see a confirmation that doesn't mean the transaction will clear.  That is why, unless there is recourse, only six transactions is the recommended number of confirmations to require.

Here's an example of the transactions for a losing 0.02041833 BTC bet:

http://satoshidice.com/lookup.php?tx=0419fdcbc82add4b46b6fe11e362561d0a3d18329770b36a637a2b60a881cf1e
http://blockchain.info/tx-index/16106266/0419fdcbc82add4b46b6fe11e362561d0a3d18329770b36a637a2b60a881cf1e
http://blockchain.info/tx-index/16106269/e69d7d733d4de5eee6fae0d402fe0db0fdd2544e9ece0f169922d143a8eaf850

You can see the flow visually here:

http://blockchain.info/tree/16104343  (click on the orange dot for the 0.01569037 BTC payment, which was one of the two inputs that paid for the bet.)


Is there a limit to how many blocks can be rolled back from a 51% attack? I was wondering if we where to ever face a 51% attack is there some sort of limit as to when the longest chain doesn't matter? For example if I owned 51%+ of the network, mined 1000 blocks privately and the rest of the network was at block 990 and then I broadcast the data would everyone switch to my chain and would the last 990 blocks be orphaned?

For example if I owned 51%+ of the network, mined 1000 blocks privately and the rest of the network was at block 990 and then I broadcast the data would everyone switch to my chain and would the last 990 blocks be orphaned?

This can certainly happen. There is no limit on how many blocks can be reorganized. However, while nodes will still perform the action to rollback those 900 blocks and replace them with the 1000 privately mined ones, there will be lots of warnings if this does happen as Bitcoin Core (the most commonly used node software) has checks for large work blockchain reorganizations. These checks will trigger warnings if there are reorgs of more than a few blocks so that the node operator can take action if necessary.


What is the "Bitcoin stick"? I've encountered the page on "Bitcoin stick" while browsing the Research wiki page. The information provided on the subject is quite small. Can anyone explain what it really is and where one can find more information on the subject?

See http://www.youtube.com/watch?v=IavQ-Wc8S1U

Clemens Cap of Uni Rostock explains the Electronic Bitcoin wallet
device he's working on. It's based on adafruit microtouch device.
This
is a small takeout of Clemens' talk at the Bitcoin Conference in
Prague 2011


How to set up a private bitcoin network with mining on a single machine? I created a testnet for mining using several ports in a single machine. However I see that the source codes [CAddrInfo, CAddr] are based on IP and not IP||port. Is there an easy change to make it do mining across ports [under same IP] or this is simply not possible?

I've had to do this, so I'll try to describe exactly what you need to do to get mining on testnet to work in a local setup. For our purposes, we'll have 2 instances of bitcoind running, the first set up to be a miner, the second as a peer.

First, create two directories, one for the miner, the other for the peer:

$ mkdir 1
$ mkdir 2

Now create this file in the 1 directory:

$ <your favorite editor> 1/bitcoin.conf

Here are the contents of the file:

testnet=1
irc=0
dnsseed=0
upnp=0
listen=1
checkpoints=0
server=1
rpcuser=test
rpcpassword=test
rpcallowip=127.0.0.1
port=20000
rpcport=20001

Now go and make the same file for the 2 directory

$ <your favorite editor> 2/bitcoin.conf

Contents:

testnet=1
irc=0
dnsseed=0
upnp=0
listen=0
checkpoints=0
connect=127.0.0.1:20000
rpcuser=test
rpcpassword=test
port=20010
rpcport=20011

Run the first instance:

$ bitcoind -datadir=1 -daemon

Run the second instance:

$ bitcoind -datadir=2 -daemon

You can check to see if everything is up and running by using bitcoin-cli:

$ bitcoin-cli -datadir=1 getinfo

Blocks should be 0 until you mine something.

If you have mining hardware, you can now mine by connecting to 127.0.0.1:20001 with the user/pass of test/test. The actual command to connect will differ based on the mining software you use, but for bfgminer, it would be something like:

$ bfgminer -o http://127.0.0.1:20001 -O test:test --generate-to <a testnet address> --no-longpoll -S all

Note that CPU mining takes several hours to find a block from my experience.


Choosing a blockchain fork in Bitcoin Core According to this, the BIP 148 UASF (user activated soft fork) goes into effect on August 1. Supposing it results in a substantial fork in the blockchain, is there a way users of Bitcoin Core can choose which chain to use (as opposed to whichever chain one's node receives first)? In other words: How do I tell Bitcoin Core to use an alternative chain?

Is this what preciousblock* is for?

*"Treats a block as if it were received before others with the same work."

From what you linked it seems to me that preciousblock doesn't supersede a longer chain, it just prioritizes one block over another at the same height.

You could call bitcoin-cli invalidateblock <blockhash> on the first block of the chain that you wish not to follow.


Configuring Windows Bitcoin Core Wallet for use on Tor I use Bitcoin Core v0.12.1 (64bit) for Windows as my desktop wallet for transactions on the regular web. I am just getting set up to use Tor. I would like to configure Bitcoin Core for use on Tor as well. When I opened Settings|Options|Network tabs I found a pre-checked marked box labeled "Allow incoming Connections" In addition to that I have checked marked the box labeled "Use Separate SOCKS5 proxy to reach peers via Tor hidden services" ProxyIP: 127.0.0.1  Port:9050.

Is this all that I really need to do? I've been reading up on bitcoin.conf and the command line options. It all seems horribly complex. I'm just an average schmo not some power user. I wouldn't know which options to pick or what values to assign. I would appreciate any thoughts and suggestions on the subject.

Yes, following this guide should be all you need to do.  It sounds like you've already done that.

Alternatively, I've found that it's cheap and easy to set up a TOR wifi access point that you can connect to, and then all network traffic is proxied over TOR.  That way, neither your local computer nor your Bitcoin Core installation need any special configuration.


All Bitcoin Public Keys with non-zero balance I want to get a database or otherwise retrieve a set off all bitcoin public keys (not addresses) that have non zero balances.

What would be the easiest way to do that? Is there an API that could do such thing? Do I have to download and prune the whole blockchain? If so how would I do that?

You can't get a database of all such public keys, but you can get some of them.

An address, as you know, is a hash of a public key.  When somebody sends coins to an address, you can think of the associated public key as having a positive balance, but nobody else necessarily knows what the public key actually is.  (You can't compute the public key directly from the address, because hash functions are effectively one way.)

However, in order to spend the coins from that address, the spending transaction has to reveal the public key (so that the spending transaction's signature can be verified).  So what you need to look for are addresses with a positive balance that have also had some coins spent.  I am not aware of any simple way to do this short of making an index of all transactions.  It is possible you could rig up a way to produce such a list by querying a fully-synced bitcoind using -txindex (so that all transactions are indexed), but it seems likely to be inefficient.

But as a randomly chosen example, consider the address 1Q6NNpHM1pyh6kEqzinBhEgsRc3nmpTGLm.  It is associated with some public key which has a balance of BTC 259.7299, but since (as of this writing) no coins have been spent from that address, nobody except the owner of the address knows what the public key is.  So your database will necessarily be incomplete; probably very incomplete.

In particular, most people use a new address for each of their transactions (including change addresses), in which case the transaction that reveals the public key for an address also spends all its coins (so that the balance is now zero), and that public key will likely never be used again.  This strategy is used partly because certain theoretical cryptographic attacks are easier if the public key is known, and this strategy mitigates the risk from such attacks; it also increases privacy by making it harder to look at patterns of transactions to try to deduce who the address belongs to.

Another case in which you can learn the public key is so-called P2PK transactions, where the output script includes the actual destination public key, instead of merely its associated address.  These were common in the past, but these days all standard clients use the P2PKH transaction type, in which only the address is used.


How to determine the balance associated with a given BTC address based on input/output amounts I'm writing an application that attempts to calculate the running balance of a given BTC address by looking at data including block height, input amount, output amount, etc. However, I'm not certain about the logic involved here. Would it be possible to create this running balance by checking an input/output address and then tracking the input/output amount?
Here's a quick sample of the data that I'm looking:
BLOCK_DATE | BLOCK_HEIGHT | TRANS_HASH | INPUT_ADDRESS | OUTPUT_ADDRESS | INPUT_AMOUNT | OUTPUT_AMOUNT
01/11/2020    190            15c7853       abc             xyz1             -0.01          0.0001
01/11/2020    190            14v9876       abc             xyz2             -0.50          0.70
01/11/2020    191            19vc842       abc             xyz3             -5.03          0.413
01/12/2020    192            20ff4d3       abc             xyz4             -0.06          0.201
01/12/2020    192            154gf34       xyz1            abc              -0.07          0.18
01/12/2020    192            45f4ti5       ggg             abc              -0.10          0.24
01/12/2020    192            33cv5c5       jjj             abc              -0.08          1.13

So using this dummy data, how would I go about calculating the running balance for address abc? I know that the input/output isn't necessarily 1:1 and there are some nuances here that make it more complex than this. So I'm not sure if I could do something straightforward like sum all of the inputs and outputs for a given address.

It looks like you are trying to calculate address balances by what I assume to be transactions. The way the data is presented in your table, I get the impression that you are assuming that there is only one input address and one output address in every transaction. That's not the case, though.
Each input in a transaction spends an Unspent Transaction Output (UTXO) created by a previous transaction. Transactions can have many inputs and there is no requirement for all the inputs to have been received to the same address. In fact, address reuse is not recommended, so most of the time every input is associated with a different address.
Let's look for example at this random transaction (via blockchair.com) with four inputs and two outputs:

It uses funds that were previously received to four different addresses and reassigns the amounts to two new addresses. So, you'll need to amend your approach slightly: instead of looking at transactions as atomic units to feed your script, parse each input and each output separately.


How can all possible numbers in 256-bit space be squeezed into 160-bit space? Bitcoin addresses are essentially 160-bit hashes of a 256-bit public key. Huh? How can all possible numbers in 256-bit space be squeezed into 160-bit space? Does that mean any given bitcoin address could be derived from more than just one public key?

It's really 160 bit hash (RIPEMD160) of an already hashed (SHA256) public secp256k1 elliptic curve key. And yes, on the average, every address has about 2256-160=296 pairs of private/public keys.


Multibit saving after transaction - what do wallet private key backups look like, if they exist? I sent some bitcoins from a multibit wallet to another wallet. I recently realized that the change not sent in this transaction is sent to a new address. This means I didn't back up the key of this new wallet.

I was wondering if this new address created would have auto-saved when I shut down multibit. If so what kind of name would it self save under?

In multibit, under the help menu option you can open the help contents. Under Wallet Backups you can read the following:

  MultiBit does this automatically in the background using special files that are described in detail in the File descriptions article. These files can often be used to recover your wallet automatically should a problem occur.

In the File Descriptions article you can read the following:

  For the purpose of illustration, imagine you have created a new wallet called saving.wallet. Please refer to the relevant help section for your version below (use the 'About MultiBit' menu option if required).

  Wallet files for MultiBit version 0.5.13 and later

  Here is a list of the files stored with your wallet:

  saving.wallet  =  This is the main wallet file containing your    private keys and transactions.
  saving.info  =  This file contains the    description of the wallet and the labels you have given to your    addresses.
  saving-data  =  A directory containing your wallet backup    files.
  saving-data/key-backup  =  A directory containing your    automatically generated private key export files.
  saving-data/rolling-backup  =  A directory containing your rolling    wallet backups.
  saving-data/wallet-backup  =  A directory containing    your encrypted wallet backups.
  saving-data/wallet-unenc-backup  =  A    directory containing your unencrypted wallet backups.

  Private key backups. In your private key backup directory you will have files called 'saving-YYYYMMDDHHMMSS.key'. Here the YYYYMMDDHHMMSS
  is a timestamp. With an encrypted wallet every time you add or change
  the password, add a receiving address or import private keys an
  encrypted, timestamped export of your private keys is created. This is
  encrypted with your wallet password. You can use these to recover the
  essentials of your wallet by importing one of these files into a new
  wallet.

This should at least put you in the right direction.


Automatically restart bitcoind on crash On Ubuntu 14.04 I have not been able to get the Bitcoin daemon to automatically restart. Rarely the daemon dies and it is important that it starts again without manual intervention. To get it to start automatically with Upstart I have followed the guide linked below. It starts with sudo start bitcoind as expected but the service does not restart if it fails.

Ubuntu Linux — How do I start bitcoind as a service to run automatically?

My conf file in /etc/init/ is as follows.

description "bitcoind"

start on filesystem
stop on runlevel [!2345]
oom score -500
expect fork
respawn
respawn limit 20 90 # 10 times in 60 seconds

script
user=bitcoinuser
home=/home/$user
cmd=/usr/bin/bitcoind
pidfile=$home/.bitcoin/bitcoind.pid
# Don't change anything below here unless you know what you're doing
[[ -e $pidfile && ! -d "/proc/$(cat $pidfile)" ]] && rm $pidfile
[[ -e $pidfile && "$(cat /proc/$(cat $pidfile)/cmdline)" != $cmd* ]] && rm $pidfile
exec start-stop-daemon --start -c $user --chdir $home --pidfile $pidfile --startas $cmd -b --nicelevel 15 -m
end script

If I run ps -aux | grep bitcoind to get the process ID and kill it the daemon does not restart as desired. I have followed the guide and cannot see what is wrong with the set up. As a side note sudo stop bitcoind does not actually stop it from running.

Any help on this would be appreciated.

I'm running a RaspberryPi Bitcoin node. Since I discovered that the node had sometimes crashed due to overload, I put an hourly starting command into crontab:

@hourly <completePath>/bitcoind -daemon -disablewallet

If bitcoind is already running, it fails to start due to not getting a lock on the data directory. Otherwise, the server will be restarted with at most one hour of downtime.

I'm sure there are more elegant solutions, but I didn't explore it much further as this worked for me.


spending some of the coins nullifies address' balance. where does the remainder goes? I use litecoin-qt, but my guess it'll be the same for Bitcoin or any other crypto coin.

I created a new wallet, added an address and received the coins I expected. Then I created another wallet on different PC added another (non default) address, and sent some of the coins from first address mentioned to the second. I used 'sendfrom' command.

Now both wallets show exactly what I would expect, however on any online block explorer I see something strange. When I enter the first address, I see the transaction with the initial amount, but then another row that withdraw that amount. Clicking on the transaction I see that the second address is credited with the amount I sent, and the rest goes to an unfamiliar address.

What does it mean or what am I missing?
Where's this 3rd address coming from?
I thought I know how things are working with cryptocoins, but now I'm completely lost.

As you may know, transactions have inputs and outputs. The outputs give the addresses to which coins are being sent, and the inputs link back to outputs of the prior transactions that gave the coins to this transaction's sender, thus forming a chain. Anyone on the network can step along this chain to verify that all the coins in circulation legitimately got to their present owners.

To make it easier to verify the chain, the Bitcoin protocol has a rule that each input must spend all the coins that were in the output that it links to. (I am presuming that Litecoin is the same.) So if the smallest (or only) transaction to your address had
an output of 150 LTC, then you have to spend 150 LTC. But since you only really want to spend 45 LTC, your wallet gives the transaction a second output that sends the remaining 105 LTC back to you, as "change".

Rather than sending the change back to the same address that is spending the coins, some wallets choose to generate a new address and send the change there. I am not exactly sure why; perhaps it's to help obscure what addresses belong to whom, for privacy. But in any case, you should find that your wallet holds the private key to this new address. The 105  coins are still yours, they're just at a different address.


Why cant i retreive my BTH coins from my blockchain wallet I logged into my wallet on blockchain.com today. I followed the links through and saw that I had been credited with a equivalent number of bitcoin cash coins that I had been expecting.

I had a few other things to do whilst there so did those first then when I went back to deal with the BTH coins they were no longer showing. what can I do to reclaim my BTH?

btw the other things I did were to move BTC from addresses into my wallet  I also backed up my wallet and recorded a new 12 word phrase but these shouldn't has had any bearing on my entitlement to BTH

I assume by BTH you mean BCH for Bitcoin Cash.

Blockchain.info does not support Bitcoin Cash so you cannot retrieve your Bitcoin Cash as that is an altcoin. However you can take your 12 word seed phrase and use it in a Bitcoin Cash wallet software that supports BIP 39 like Electron Cash to recover your coins.


getrawmempool verbose returns ambiguous results bitcoind v0.15.1 getrawmempool rpc in verbose mode returns size and vsize for a transaction:

vsize: size for fees post-segwit (ceil(weight/4))

size: disksize

But getrawmempool rcp also returns descendantsize and ancestorsize values.

Are these values segwit-aware? do they return the ancestor/descendant transaction disksize sum or ancestor/descendant vsize sum?

As easy as read an actual rpc call instead of bitcoin.org documentation:

"descendantsize" : n,   (numeric) virtual transaction size of in-mempool descendants (including this one)
"ancestorsize" : n,     (numeric) virtual transaction size of in-mempool ancestors (including this one)strong text


How to run bitcoin atom daemon? I set up the bitcoin atom daemon on an Ubuntu server and I want to run it.

How can I do that?

You may miss rpcport number in configuration file.

Run nano ~/.bitcoinatom/atom.conf

Add new line rpcport=7332 for mainet or rpcport=17332 for testnet

Kill the process and restart server

Ref: https://github.com/bitcoin-atom/bitcoin-atom/wiki/Mining-Instructions


Bitcoin sent but not received. This is the log
0 confirmed/ in memory pool
1NJBNxv5c7oB6risrN7Zrh4J5bomjrsrNM
Debit: -0.56748446 BTC
Transaction fee: -0.00098910 BTC
Net amount: -0.56847356 BTC
Transaction ID: bc28bfac6984ddeaab814cc73a71fd9f8fb49780997beb39d0f9a8bce519f242
Transaction total size: 98570

Any ideas on what is keeping it from arriving.
I have sent to this address before with no problems.

Thank you

Frank

This transaction hasn't confirmed yet because it has a low satoshi/weight unit transactoin fee (0.251 sat/wu, or 1.003 sat/byte).

The transaction you linked is very large, you can check all the inputs using this link. Transaction fees are calculated according to the amount of data transmitted (tx weight/size), not the amount being transacted, or the receiving address.

The mempool appears to be fairly empty right now, but with a fee this low, I'm still not sure your tx will confirm anytime soon.


Would it be possible to provide a downloadable blockchain that is updated and verified by a mass of people? As of November 2012, the blockchain is nearly 3 GB in size with a near-linear growth of about 500 MB/month (cut from exponential growth by the hard-coded block size limit, I guess).

I want to install Bitcoin on my average notebook:
Downloading and verifying the latest bootstrap.dat from Bitcoincharts took some hours (5–9, I guess), but that was only 2.3 GB! Now, I’ve been waiting for Bitcoin to catch up on the last 2–3 months, in which blocks have been considerably bigger and each block takes about 5 seconds of being processed, with my CPU at ~25% and my hard drive at max workload.

This is, to be put lightly, unsustainable.

We need a system, in which an already verified blockchain can be downloaded and directly copied to the bitcoin folder, maybe in an incremental form.
The source has to be trusted, for this, one needs a verifying system in which everyone can control the correctness of the blockchain and then sign it, I’d propose to use gpg keys for this.

The source can then be distributed via server-backed torrent, for example.

Is this technically possible and how?

Edit: Since I approached this with a wrong mindset, I posted kind of a follow-up question about the security risks of lightweight clients. Should an end-user download the whole blockchain? Or is a “lightweight” client sufficient?

There already are downloadable versions of the blockchain. There's no problem in principle in having them GPG-signed by several trusted people. However:

It somewhat weakens security. With the software itself you can trust the signatures and you can inspect the code. With blockchain data inspecting it is infeasible.
Future versions will use a different DB format which allows for much faster verification, so there will not be much advantage for a system where verification is obviated but downloading the data is still needed.
In the long-term, end users will not use a full client, but rather (at best) an SPV client which does not need to download or verify the entire blockchain.


How can I know *exactly* when my name_new domain is ready for the name_firstupdate step? The FAQ very vaguely says "Wait at least 12 blocks", but it doesn't make much sense to me.

Unless I have totally misunderstood how this works, once the name_newd domain is in the chain, I should safely be able to proceed to the next step... so how can I know exactly if it is ready? Or am I missing something?

It seems you can issue your name_firstupdate transaction whenever you're ready (in particular, right after doing the name_new).  It won't be included in a block until the name_new is mature (12 confirms) but should be picked up shortly after that happens.

I don't have any source for this other than recent experience, but my names are showing up when I do name_list so I take it that they are properly registered.

EDIT: I thought about it a little, and I suppose you should wait a little bit (at least until your name_new is included in a block).  The reason being that nobody can know what name you're trying to register until you do name_firstupdate, and so they can't steal it from you.  Sending both the name_new and the name_firstupdate is vulnerable because someone can quickly issue their own name_new for the same name, and depending on luck (or in the worst-case, their control of a significant hashrate) claim it before you can.

Someone more familiar with the intimate details of how requests for the same name are resolved can comment on whether this scenario is possible or not.


Firstly, the version number is actually 4 bytes. It is a 32 bit little endian integer.

The version number is used to signal specific support for some technologies. Specifically, a transaction must be version 2 in order to use OP_CHECKSEQUENCEVERIFY. Otherwise the transaction is exactly the same as a version 1 transaction. Only transaction versions 1 and 2 are considered standard.


Hashrate comparison for multiple hash algorithms My question is about the hashrate obtained with same hardware (non-ASIC) on many algorithms.

For example, I've read that Scrypt-N is about half the hashrate of Scrypt. Is that true for all hardwares? Do we have the same kind of relations between hashrates on other algorithms (something like on SHA256 my hasrate would be 10x my ethash hashrate)

Thank you for your answers

It is not true (at least not in a direct ratio) for all hardware. Some algorithms will benefit more from more memory, or particular assembler instructions (eg, AES-NI). Some will benefit more from more hardware threads. So while most algorithms will follow a rough upcurve as system specs improve, you'll se more or less linear ones, and more or less plateauing or decelerating ones, and ones with different slopes on the more or less linear ones.


Fastest way to transfer funds from Ethereum address to Bitcoin address I have an Ethereum address with some Ether in it, and I would like to transfer some of those funds to a Bitcoin address.

I am wondering what's the quickest and most painless way to perform the token exchange and the transaction - possibly without having to install a wallet client.

Use an exchange that trades both BTC & ETH.
Bittrex, ShapeShift, Coinbase, Poloniex, etc.


Vanitygen: Impossible addresses? I'm currently attempting to modify Vanitygen to suit a particular purpose. However, I'm running into an issue with "impossible" addresses. For example, from the stock Vanitygen available on Github I get this output:

./vanitygen -T mR
Prefix 'mR' not possible
Hint: valid testnet addresses begin with "m" or "n"

While the following works:

./vanitygen -T m
Difficulty: 1
Pattern: m
Address: mh8e8yUtsmhCm6PTkuHV85ozEV5iNibmbp
Privkey: ***************(doesn't matter)

I get similar results for this set of options:

./vanitygen -F script 3Ro
Prefix '3Ro' not possible
Hint: valid bitcoin script addresses begin with a "3"

and

./vanitygen -F script 3R
Difficulty: 836
Pattern: 3R
P2SHAddress: 3R1jUHTrESWgCC812LrgwHErc9Y3UL7XeL
Address: *********(doesn't matter)
Privkey: *********(doesn't matter)

So, I'm trying to determine why Vanitygen is saying that these particular prefixes are not possible. For both of these failures, the failure occurs within get_prefix_ranges(). However, this isn't a programming question, necessarily. What I'm trying to uncover is some underlying principle that I may be missing that would render these particular prefixes impossible.

Perhaps a couple of questions may help me answer this myself:

When Base58Check encoding the version+publickey+checksum, how exactly is the encoding processed? Is the input broken into 6-byte words and then converted into Base58 format (seems implausible because you could theoretically have something like 111111 (binary) in the checksum that would be > 58). Or, is the whole version+pubkey+checksum converted to a BigNumber and then essentially Mod 58'd for each character.

If the latter is the case (which seems probable), in what order does this occur? Using the example of 80FAFBFC (2163932156 decimal):

x = 2163932156
result[0] = x % 58 = 6
x = floor(x / 58) = 37309175
result[1] = x % 58 = 37
x = floor(x / 58) = 643261
result[2] = x % 58 = 41
x = floor(x / 58) = 11090
result[3] = x % 58 = 12
x = floor(x / 58) = 191
result[4] = x % 58 = 17
x = floor(x / 58) = 3
result[5] = 3

result = [6, 37, 41, 12, 17, 3]
Convert to Base58 values:
result = [7,  e,  i,  D,  J, 4]

Would the result be displayed as: 7eiDJ4 or 4JDie7?

This is due to the "version" byte and the way bitcoin addresses are made with base58.

The procedure is pretty straightforward:

the version byte
the RIPEMD160 of the SHA256 (known as HASH160) of the sec format of the public key (don't worry too much about this part, just know it's 20 bytes long)
the checksum (4 bytes long)

Concatenate these and you have a 1 + 20 + 4 = 25 byte string which then gets encoded into a base58 string to form the bitcoin address. Note that parts 2 or 3 can be pretty much anything, but the version byte is specific to the network.

For your case, the version byte of testnet is 0x6f.

The documented procedure for calculating base58 is here.

Here is a simple python program to demonstrate how this is done:

alphabet = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
def b58(x):
    a = ""
    while x > 0:
        x, r = divmod(x,58)
        a += alphabet[r]
    return a[::-1]
print b58(0x6f0000000000000000000000000000000000000000)
print b58(0x6fffffffffffffffffffffffffffffffffffffffff)

The result of this program is this:

mfWxJ45yp2SFn7UciZyNpvDKrzbhuzkU7H
n4rZHAPGXCu8bYchjzJhK3V7VVredELJRc

That is actually the range of possible addresses within testnet. This is because anything before mfWxJ45yp2SFn7UciZyNpvDKrzbhuzkU7H would result in the first byte being 0x6e and anything after n4rZHAPGXCu8bYchjzJhK3V7VVredELJRc would result in the first byte being 0x70. Running vanitygen should confirm:

$ vanitygen -T mfWxJ3
Prefix 'mfWxJ3' not possible
$ vanitygen -T mfWxJ4
[...]

It's important to keep the version number in mind when generating vanity addresses for this reason.


Networking & Lightning Network So I have a question regarding network connectivity within LN nodes.

Scenario #1:

I have public lightning network node. it has real public IP address (let's say 123.123.123.123), which one is announced in config file. also, there is a TOR service, with configured .onion service (let's say mynode.onion). On the nodes config file there is no proxy configuration, so my node communicates with the rest of the world using clearnet. So from the outside world my node is available on 123.123.123.123:9735 and mynode.onion:9735. While outgoing connections are made from 123.123.123.123.

Now I have a friend, who's also node operator. He's a paranoid (his node is only available as a TOR hidden service on friendsnode.onion) and needs some incoming capacity. As i understand (please correct me if i am wrong), the only way to open channel to him is possible that way:

connect from my friends node to my node using my clearnet IP
123.123.123.123
connect from my node to friends node using his node ID
open a channel to him, using his node ID

my question is:

what will happen in case of node restart or any other accidental event which can interrupt the current connection.
Will the nodes re-connect to each other without any manual operations?

Scenario #2:

I have two LN nodes on my LAN. each node has its local IP (let's say NodeA - 192.168.0.1 and NodeB - 192.168.0.2) and both nodes have their dedicated public ip (let's say 5.5.5.5 and 6.6.6.6). The nodes have in their config files announcing the real IPs, not local ones. I would like to create a channel NodeA -> NodeB, but want to do so using local addresses. So what i do:

on NodeA connect to NodeB id@192.168.0.2:9735
open a channel NodeA -> NodeB

my question is:

will it connect at all (not tested, but i assume - yes)
will the nodes reconnect correctly on restart? (is the NodeB connection network address stored in DB/config files on NodeA or is it retrieved from "announced" addresses somehow from NodeB each time? )
will be the LAN address of any node somehow visible to rest of the network? (assuming that beside NodeA<->NodeB channel there are non-related channels to  third-party public node from each node as well)

Appreciate your answers!

edit: formatted & fixed some typo

This is implementation dependent of course. Afaik every implementation will try to reconnect, so your first case works (note that your paranoid friend's Tor hidden service isn't used at all). This is common in practice, for any non-public node.

In the second case, for c-lightning the address hint will be forgotten on reconnect, so they'll try to reconnect on the public IPs. Even if we were to fix that, they'll try so the addresses including the public ones: we'd need a special option to ignore public addresses for a specific node if this were common.


Bitcoin Server accounts I run Bitcoind and when I type account lists I get 4 accounts. Why?
How do I know which account is associated with bitcoin-qt? Also I never had any coins and using "move" command I moved 0.1 bitcoin to another account? How is this possible and how do I remove everything and start over?
Do I need to have bitcoin.conf written before I run Bitocind?

You can and should ignore those accounts. The accounts mean nothing; they are just an internal thing in Bitcoin Core and will be removed soon. Accounts are done by the address labels, so when you change a label for an address, you are changing its account. But that really doesn't matter and you should not be using the accounts system at all.


Will the Bitcoin network discredit a transaction if you do a simple transfer on a multi-sig after you found the collision on that address? Let's say you found a collision for an address on the Bitcoin network. You have its private key.
Will you be able to transfer any money around or will the network prevent it or does it get verified?

Here's another way of putting it: Can the address generated by 2-of-3 pv/pk be accessed by a 4th pv(a collision) or the network always looks for 2 of those 3 signing the transaction. Is that clear now?
Is multisig only a way for shareholders of an address, making sure enough of them are present during a transaction, or does the network actually prevents a transfer without all the necessary signatures?

No, this is not a palpable concern.
Multisig is generally implemented by means of Pay to Script Hash (P2SH) addresses. Hereby, the receiver defines a script that they'll use to spend the funds, and forms an address from a hash of the script. Later, when spending, the original script is revealed and must be fulfilled. In the case of a 2-of-3 multisig, this will require two valid signatures corresponding to two of three explicitly stated public keys.
The only way a collision could be found would be if, hypothetically, a script that only requires one key happened to hash to the same address. It is generally considered infeasible to search for such pre-image collisions other than by brute force since cryptographic hash functions are one-way functions, though.


Mining your transaction to push it to the blockchain? Is there a way to mine your own transaction to push it to the block chain.

I see these individual miners out there on forums speeding up other users transactions within 10-60 minutes.

So i guess i am trying to figure out how i can do this to speed up my 3 stuck transactions!

Any info would be nice! Thanks!

You can pay to mining pools to mine your stuck transactions.

Expensive but i don't know any other mining pools who provides this feature.

https://pushtx.btc.com/

Try to push your stuck transactions before you pay, maybe that could help you if your transactions have more than 120/sat per byte.

  https://insight.bitpay.com/tx/send

  https://blockchain.info/pushtx

  https://blockexplorer.com/tx/send

  https://btc.com/tools/tx/publish

  https://coinb.in/#broadcast

  https://chain.localbitcoins.com/tx/send

  http://webbtc.com/relay_tx

  https://www.smartbit.com.au/txs/pushtx

  https://live.blockcypher.com/btc/pushtx/

  https://www.f2pool.com/pushtx (Needs referral code from pool operator.)

  https://pool.viabtc.com/tools/BTC/broadcast/

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

Some websites asks for hex format transaction ID, You could convert it like that:

https://blockchain.info/tx/TransactionID Here?format=hex


Bitcoin Sellers who Request Photo ID, is this safe? I wanted to comment on this but couldn't due to low rep:

What's the safest way to buy bitcoins in the UK?

Looks like quickbitcoin.co.uk is a good place to buy bitcoins, however; I'm not comfortable sending my driving licence or other ID.

Why do companies/sellers of crypto currency want photo ID of customers?  Is it safe?

Cryptocurrency companies generally require photo identification to protect the company. The legal concern of exchange of cryptocurrency is money laundering, and by requiring identity verification, you know who you're receiving currency from or giving it to. Of course, companies will also need to have procedures in place to detect identity fraud. Some exchanges will require you to provide a picture of yourself holding your photo identification.

As for whether it is safe or not, it really depends on how trustworthy people believe the company is.


How does serializing in coins.h work? I'm talking specifically about this:

/** pruned version of CTransaction: only retains metadata and unspent transaction outputs
 *
 * Serialized format:
 * - VARINT(nVersion)
 * - VARINT(nCode)
 * - unspentness bitvector, for vout[2] and further; least significant byte first
 * - the non-spent CTxOuts (via CTxOutCompressor)
 * - VARINT(nHeight)
 *
 * The nCode value consists of:
 * - bit 1: IsCoinBase()
 * - bit 2: vout[0] is not spent
 * - bit 4: vout[1] is not spent
 * - The higher bits encode N, the number of non-zero bytes in the following bitvector.
 *   - In case both bit 2 and bit 4 are unset, they encode N-1, as there must be at
 *     least one non-spent output).
 *
 * Example: 0104835800816115944e077fe7c803cfa57f29b36bf87c1d358bb85e
 *          <><><--------------------------------------------><---->
 *          |  \                  |                             /
 *    version   code             vout[1]                  height
 *
 *    - version = 1
 *    - code = 4 (vout[1] is not spent, and 0 non-zero bytes of bitvector follow)
 *    - unspentness bitvector: as 0 non-zero bytes follow, it has length 0
 *    - vout[1]: 835800816115944e077fe7c803cfa57f29b36bf87c1d35
 *               * 8358: compact amount representation for 60000000000 (600 BTC)
 *               * 00: special txout type pay-to-pubkey-hash
 *               * 816115944e077fe7c803cfa57f29b36bf87c1d35: address uint160
 *    - height = 203998
 *
 *
 * Example: 0109044086ef97d5790061b01caab50f1b8e9c50a5057eb43c2d9563a4eebbd123008c988f1a4a4de2161e0f50aac7f17e7f9555caa486af3b
 *          <><><--><--------------------------------------------------><----------------------------------------------><---->
 *         /  \   \                     |                                                           |                     /
 *  version  code  unspentness       vout[4]                                                     vout[16]           height
 *
 *  - version = 1
 *  - code = 9 (coinbase, neither vout[0] or vout[1] are unspent,
 *                2 (1, +1 because both bit 2 and bit 4 are unset) non-zero bitvector bytes follow)
 *  - unspentness bitvector: bits 2 (0x04) and 14 (0x4000) are set, so vout[2+2] and vout[14+2] are unspent
 *  - vout[4]: 86ef97d5790061b01caab50f1b8e9c50a5057eb43c2d9563a4ee
 *             * 86ef97d579: compact amount representation for 234925952 (2.35 BTC)
 *             * 00: special txout type pay-to-pubkey-hash
 *             * 61b01caab50f1b8e9c50a5057eb43c2d9563a4ee: address uint160
 *  - vout[16]: bbd123008c988f1a4a4de2161e0f50aac7f17e7f9555caa4
 *              * bbd123: compact amount representation for 110397 (0.001 BTC)
 *              * 00: special txout type pay-to-pubkey-hash
 *              * 8c988f1a4a4de2161e0f50aac7f17e7f9555caa4: address uint160
 *  - height = 120891
 */

I don't really understand how nCode works. Let's take the second example:

First bit is set to indicate it's a coinbase transaction. So far nCode = 01.
vout[0] and vout[1] are spent, which means we add 1 because there is at least 1 unspent output. So the bitmask is 0001 0001, which is equal to 0x11.

So already we have a number bigger than 0x09. How the hell is that nCode = 0x09 computed?

(note: I'll be using a different bit numbering from the comment which goes from 0..B instead of 1..2^B, as I find that easier to read myself)

The binary representation of 0x9 separated in functional groups is

bit# ...6543 21 0
        ---------
        0001 00 1

Bit 0 is set because this is a coinbase
Bit 2 and 1 are 0, because vout[0] and vout[1] are spent
Bit 3+ contain just the binary number 1. As bit 1 and 2 are not set, these bits encode N-1. N=(9>>3)+1=2. N here is the number of bytes in the subsequent bit vector.

These two bytes that follow are 04 and 40, encoding the number 0x440, the number with bits 2 (1<<4=0x04) and 14 (1<<14=0x4000) set. As described in the example this means vout[2+2] and vout[14+2] are unspent.

How do you end up at 0x11?


What are Merklized Alternative Script Trees? I have seen the acronym MAST floating around. I saw that it stands for Merklized Alternative Script Trees, but what does that mean? In what context do they appear and what can they be used for?

The idea of Merklized Alternative Script Trees (or previously Merklized Abstract Syntax Trees) dates back to an idea Russell O'Connor had in 2012. The original idea was that you could have alternative scripts or script fragments stored as leaves in a Merkle tree and then the leaves of the tree that weren't used could be pruned away and not take up valuable space on the blockchain. Compare this to P2SH (Pay to Script Hash) where the entire script is hashed and then revealed on the blockchain at spend time. This brings block space efficiencies (and hence lower fees) as well as privacy benefits.
The earlier formalized proposals for MAST were BIP 114 and BIP 116 and the most recent proposal is of course Taproot (BIP 341). The reason why we moved away from using Merklized Abstract Syntax Tree terminology is that with Taproot (and BIP 114) only one single leaf of the Merkle tree can be executed. You cannot split one particularly long script path into multiple script fragments stored on different leaves of the tree and then satisfy a combination of these leaves. It is effectively a tree of ORs (no ANDs of different leaves and no IF, ELSEs that lead to satisfying different leaves on the tree). You can have ANDs and IF ELSEs but they are contained within leaves not between leaves. Satisfying a single leaf is sufficient to spend the UTXO. As Johnson Lau says in BIP 114:

Only one branch is allowed for execution, and users are required to transform a complicated condition into several mutually exclusive branches.

Pieter Wuille and Russell O'Connor discussed why this design decision was made for Taproot at London BitDevs in July 2020. One of the reasons was that you only need a logarithmic number of Merkle branch nodes to get to any given leaf. There is a combinatorial explosion if there is the potential to have different combinations of all the leaves. Another reason is that the design space had to be limited at some stage to give the proposal the best chance of obtaining community consensus and ultimately be activated.


Increase transaction fee with Bitcoin Core client fails because of no change output. Why? Context

I created a transaction (using the full balance of an output) with the Bitcoin Core Wallet (running as full node). The transaction got into the mempool of major nodes, as expected. I set the fee to what the client recommended for a slow transaction (little more than 9 sat/B) , but these days this turns out to be very low. Given the current state of the mempool at hoenicke this may get confirmation in weeks, if at all.

Increasing the fee fails

I initially, deliberately, set the transaction to "Request Replace-By-Fee", and I want do increase the fee now. I expected to take some part of the "target amount" and use it as fee, leaving the total amount of the transaction the same (still spending the complete output in total)

However, this does not seem to be possible by design. I get a "Fee bump error" saying "Increasing the transaction fee failed (Transaction does not have a change output)".

What to do about it?

Why am I not able to change the target/fee balance of a transaction, and how am I expected to increase the fee at this point?

Transaction Details (as per Request)

Summary
Size    1xx (bytes)
Weight  7xx
Lock Time   Block: 49xxxx

Inputs and Outputs
Total Input 0.01xxxxxx BTC
Total Output    0.01xxxxxx BTC
Fees    0.00001xxx BTC
Fee per byte    9.xxx sat/B
Fee per weight unit 2.xxx sat/WU
Estimated BTC Transacted    0.019xxxxx BTC

Both input and output addresses start with "1"

BIP125 RBF (Replace-by-fee) transactions in bitcoin-core 0.15.0.1 appear to require a change address with a balance in order to facilitate a future RBF-based fee increase.

By way of an example, consider the following transaction:

Input  - 1.00000 BTC
Output - 0.99998 BTC
Fee    - 0.00001 BTC
Change - 0.00001 BTC

Assume the fee is too low.  Now, we want to increase the fee for the transaction, so the RBF replaces the prior transaction with one like:

Input  - 1.00000 BTC
Output - 0.99998 BTC
Fee    - 0.00002 BTC
Change - 0.00000 BTC

Now the fee is enough that the transaction is confirmed.

Without "change" present in the first transaction, there is no source for the increased fee.  RBF could be implemented such that the output is reduced to allow for a greater fee; I'm not sure why that is not supported.  Line 2928 of the wallet.cpp source code in the bitcoin-core github repository states:

break; // Done, able to increase fee from change

The way around this problem for a transaction that has RBF enabled, but has no change address is to follow the directions contained in one of the answers in the canonical "transaction not getting confirmed" question.  I experienced the exact issue last week and was able to successfully recover using the -zapwallettxes option in the bitcoin-core wallet CLI.


What is 42Coin? Why it is highly priced? In cryptsy, I see that one 42coin is trading at >900 BTC. Just wondering what is 42coin and why it is highly priced?

A new crypto-coin, scrypt based, which produces blocks every 42 seconds (each of which yield just 42 millionths of the currency, except for every 420th which yields x10) and for which there will be no more than 42 coins in existence. Yes, that's right, only 42 "42coins" will ever exist! That takes Bitcoin's hard limit of 21 million to the extreme, of course.

For what I've read, it's a half-joke based off the novel "The Hitchhiker's guide to the Galaxy", wherein it's stated that number 42 is the answer to the "ultimate question about God, life, the Universe and everything else" - such a question that we humans are just too dumb to fully understand, much less grasp the implications of the answer :)

Official page

Official forum, with links to pools

What amazes me is how a coin with no virtually no use appart from speculation has commanded such a high prize - it's HUNDREDS of times more valuable than a bitcoin itself! And yet, according to coinwarz, it's not all that profitable (probably because of the block's ultra-low yield).


Is there any chance to check the name by bitcoin hash? Someone recently wants to sell me an iPhone, but the seller does not want to show me anything about it. It's a second-hand phone, and I'm worried about it a little bit. Is there any chance to see the information about the seller from bitcoin hash?

No, that's not possible. Bitcoin is pseudonymous. In all likelihood, you will be sent an address which never had any activity on it before. You can't find any relation between that address and the real world (including activity on the blockchain) until a transaction sending money to that address is published. Even if you knew the person who gave you the address, you wouldn't know for sure whether it belongs to them (but you'd of course assume it because why would they give you an address of a different person or one which belongs to no one). They can prove that it belongs to them but they can't prove that it doesn't and you as someone it doesn't belong to can't proof they own it nor that they don't.


What type of fork is Litecoin? Is Litecoin classified as either a hard fork or soft fork? If neither, what is considered as?

It's considered a source code fork, or an altcoin, neither a hard fork nor soft fork of bitcoin. To be classified as a soft/hard fork, it should share some of the same chain from the genesis block. LN has a completely different chain right from the start so it's not a fork of the bitcoin chain.

Note that even coins sharing the same chain as bitcoin from the genesis block, e.g. BCH, are not considered hard forks by most people because they are not "bitcoin". They are generally termed "forkcoins"


How do cryptocurrency exchanges like Mintpal manage so many? As there are 100s of crypto coins each with their own QT-client, how do exchanges manage the transactions? Do they use the core client of every altcoin in the servers or will they be programming code to do that? If coding is done, which platform or language is secure?

As there are 100s of crypto coins each with their own QT-client, how do exchanges manage >the transactions?

From what I have seen and what I understand, each exchange running on a website like cryptsy or mintpal is its own process. Each "exchange server" is a program running on the website's server. Because each coin's protocol necessitates its own wallet, they just have to have a lot of servers. The way lots of servers are banded together to handle a lot of requests is a complex science, and a lot of it is proprietary because businesses invest a lot in it.

  QT-Client

Using a qt client in a server is rather inefficient, because there is not much need for a graphical interface. Using such a client is just unnecessary extra overhead. These websites can save a lot of money by optimizing server programs, which in turn allows for less server use, and less necessary investment in hardware.

  Do they use the core client of every altcoin in the servers or will they be programming code to do that?

The most efficient solution for running a crypto transaction would be the barebones command line, as it has minimal overhead. It just takes requests and sends them through the network. This is easiest to do with just the core client, although all bitcoin clients have the core client in them. Next, sending through transactions would require a server side program, that would do the exchange math, and then send the proper funds to the proper wallets. This part would be custom coded. Peatio is not highly prevalent yet, and there isn't other "exchange software," so exchanges do write exchange software themselves.

  If coding is done, which platform or language is secure?

Server side coding does not affect security because it stays on the side of the exchange. Server side security precautions like encrypting important data aren't really affected by platform. As long as the platform can encrypt connections and keep data safe, it's a secure platform. I realize that's kind of a blow off answer, but almost every server platform is made to be secure enough to run these types of things, and so are the coding languages.


how do i convert bc1 address to hex? for coinbase transaction Im trying to create a coinbase transaction so that I can do some mining.
I have a bech32 bitcoin address, how do I convert that to hex so that I can include it in the coinbase transaction data?
example> bc1quukrk3u6cgpjhyqvehcj0ruyk8990dpev0zn6h
Also, where are the parts of the address? network type, checksum.
And how would I do it with the other address types?
Thanks in advance!

BIP173 specifies the conversion from Bech32 segwit addresses to scriptPubKey. You probably want to use some reference software to do the decoding (there are several links in the BIP). If you need the details, it is approximately:

Split the address in a "human readable part" and a "data part"; the last '1' character in the address separates the two.
Convert the data part from characters to symbols (integers in range 0-31) using the character map in the BIP.
Verify the checksum (last 6 characters of the data part). I'll refer to the BIP for the details.
Interpret the symbols of the data part as follows:

One symbol: Witness version (number 0-16)
Variable number of symbol: witness program
The last 6 symbols: the checksum

Perform various sanity checks on the data sizes and ranges, also illustrated in the BIP.

The retrieved information (witness version and program) can the be converted to a scriptPubKey, as specified in BIP141. Namely, OP_n (where n is the witness version), followed by a push of the witness program. Note that OP_0 is 0x00, while OP_1-OP_16 are 0x51..0x60.
There is a proposed amendment called BIP350 which improves the checksum for witness versions higher than 0 (which are currently not in use, but may become in use following the activation of Taproot (BIP340-342).
This is how conversion from addresses to scriptPubKeys works for all transaction outputs, FWIW. It is entirely unrelated to coinbases.
Disclaimer: I'm a co-author of all the BIPs mentioned in this answer.


Import newly generated address to bitcoin core Can I import newly generated address to Bitcoin core with "importaddress" rescan false, for the watch only purpose?

why do I need to rescan if the address doesn't have any history?

Question: will it trigger the "walletnotify" if it receives new transaction on that address without rescanning.

why do I need to rescan if the address doesn't have any history?

It does not know it has no history until it completes the rescan.

You can either pass a false as extra argument (look up the importaddress documentation), or use the more powerful importmulti command with a recent birth time.


Can you use any Bitcoin address as a Counterparty token receiving address? I have a bunch of bitcoin addresses and I would like to just use them for receiving counterparty tokens. I've read that counterparty addresses are the same thing as a Bitcoin address. Is this correct? And if so, doesnt this mean every Bitcoin address can effectively receive counterparty tokens?

I also can't seem to find an option to import an existing Bitcoin address into the counterwallet website. I was only able to find an import sweep option. screenshot would be nice.

Yes, you can use your Bitcoin addresses to receive Counterparty tokens. Make sure you have the private keys to your addresses backed up.

Counterparty is a layer built on top of the Bitcoin protocol which basically allows you to embed data into the Bitcoin blockchain. This data can be used to represent tokens which will be recognised by the counterparty protocol as being owned by a particular Bitcoin address. You will need a small BTC balance at the holding address in order to send those tokens to a new address.


How many bytes long should nSequence be? When I look at the following raw transaction from: https://blockstream.info/tx/a175425ee2f3c01acc97ef32ab1082db14eaa94e5af4c54f02f3b01dec72558e?expand

020000000001018e5572ec1db0f3024fc5f45a4ea9ea14db8210ab32ef97cc1ac0f3e25e4275a100000000**00cf050000**01d2ddbc0000000000160014b82d832b2e5c0d80c771b06ce0da50fbccf12f3e0347304402204a54d94068512c22847cc07fa85f2b93feaf758411920a9b20ce9b85831e8aa5022005924cb82c331c5173e21477a4d8298eb25c0d967ace065b883455f2537c3d0a01004d632103f96d73ffe138690f032e97408af933a71782ad27a28df66a750b48c56b2d7fa96702cf05b275210304f332f50363cd01b679d9fb50fb8691fb0fb638737867bd02f06850c6191a2268ac00000000

When I parse it manually, specifically at this section: a100000000**00cf050000**01...

a1 is the last byte of the input tx (in little endian),

00000000 is the output index (4-bytes),

and at the end the 01 is the tx_out_count.

But that would make the sequence number 00cf050000, which is longer than 4 bytes? What am I missing here?

The sequence number is always 4 bytes, it is a fixed size, little endian, 32 bit integer which makes it always 4 bytes.

What you are missing is the scriptSig. The scriptSig always begins with the size of the script (as a compact size unsigned integer). If the scriptSig is empty, then the size must still be there to say that it is a 0 length byte. So the first byte of your "sequence" is actually the length byte for the scriptSig that says it is of length 0.


Can you mine more bitcoins on amazon aws than it would cost to operate the servers? Read title.

Creating a soft of self sustainability if you will. It might not be possible?

AWS is rental of server instances.  Servers without GPUs. Bitcoin is not cost effective when mining using CPUs, so nobody has done that analysis for nearly two years because its an obvious money loser and becomes a worse option with each passing day of rising difficulty.

Now EC2 (compute cluster) does use GPUs but NVidia GPUs which don't perform at a fraction of the level of AMD GPUs for the specific purpose of Bitcoin mining. Although it was not analyzed recently, a calculation from a while ago provides numbers in the right ballpark, if not better than they would be today.  In that study costs you more than twenty dollars of EC2 charges to earn one dollar of bitcoins.

Once ASICs ship that difference will increase possibly by an order of magnitude.


Save state to the disk at abrupt bitcoind shutdowns I have a bitcoind running, and after new blocks being synced, sometimes I kill it(without stop command).

Next time, when I start it, it goes through already synced blocks.

Is there any way to force bitcoind keep the state on a hard drive after accepting each new block?

I think bicoind save the state of the last block because it can access to DB and read the last block stored into DB.

also, I have noted when running bitcoind, it runs some previous bock (I don't know the motive)
This is the log of the bitcoind

2019-08-22T10:51:33Z init message: Rewinding blocks...
2019-08-22T10:51:36Z init message: Verifying blocks...
2019-08-22T10:51:36Z Verifying last 6 blocks at level 3

ps: If you kill the process bitcoind without stop command you can corrupt some file blk and inside it, the client bitcoin can store trash data


How to check two hashes are equal using block data and the nonce? This is my first question on this community (the 100 points were just given to me by the site). The information given is from a block i found looking from the docs api. What am supposed to do with the nonce and the hashes in this block to check SHA256(A)==SHA256(B+nonce) or is this terribly wrong and the data here cannot give me that answer.

{
    "hash":"0000000000000bae09a7a393a8acded75aa67e46cb81f7acaa5ad94f9eacd103",
    "ver":1,
    "prev_block":"00000000000007d0f98d9edca880a6c124e25095712df8952e0439ac7409738a",
    "mrkl_root":"935aa0ed2e29a4b81e0c995c39e06995ecce7ddbebb26ed32d550a72e8200bf5",
    "time":1322131230,
    "bits":437129626,
    "nonce":2964215930,
    "n_tx":22,
    "size":9195,
    "block_index":818044,
    "main_chain":true,
    "height":154595,
    "received_time":1322131301,
    "relayed_by":"108.60.208.156",
    "tx":[--Array of Transactions--]
{

I wrote a python program to calculate the block hash from the version, prev_block, mrkl_root, timestamp, bits, and nonce. You can see it here.


does anyone know how to send the "exp" parameter in an Electrum request I tried modifying the request so it would include a 3600 second expire time. (minutes - 1 hour) as shown in the example  it returned an error the parameter was invalid.  It shows - but as "null"

curl --data-binary '{"id":"curltext","method":"addrequest","params":{"amount":"3.14","exp":"3600","memo":"test"}}' http://127.0.0.1:7777

{"error": {"message": "Invalid parameters.", "code": -32602}, "jsonrpc": "2.0", "id": "curltext"}[

This is Electrum client daemon - not server - Linux (CentOS 7) - not Windows - it runs and returns a request fine without the "exp" parameter

Yes.  Use "expiration": "3600" and it'll work.


How to get a description (comment) of the transaction? From this json response from blockchain.com

How can I get a comment on the translation from here?

The comment field seen on the blockchain.info blockexplorer is a feature of the blockchain.com wallet. The data for that comment field is created by users of their wallet, stored only by blockchain.com/info and published by blockchain.info.

This comment is not part of the Bitcoin transactions stored on the Bitcoin blockchain, it's only stored in the databases of a service by a company called Blockchain. The comment thus cannot be retrieved by other wallets. It may be possible to retrieve it from the blockchain.info API.


Why do bitcoins have a total limit? There are a total of ~16 million bitcoins in existence, and 21 million
  total will be available. Therefore, there are ~5 million bitcoins
  still to be mined from now until around 2140. How much bitcoin is left
  to mine? - ...

Source:
https://www.quora.com

Why does nobody can mine any bitcoin after 2140? Given this information is true?

The number of newly-created bitcoins with every mined block gets halved every 4 years on average. (More precisely, every 210,000 blocks). When bitcoin started, this was 50 new coins per block and currently it's down to 12.5 coins. This halvening creates a geometric progression which converges to the theoretical maximum number of bitcoins that can ever be mined, which happens to be 21 million.

Mathematically:

50 + 25 + 12.5 + 6.25 + ... = 100

100 × 210,000 = 21,000,000


Is it true that only one message can be sent at a time in Bitcoin Core? I looked into Bitcoin Core client code, and it seems that there is a lock that allows only one thread to send data (Block, TX, etc.) at a given time point. If this is true, it means that transactions and blocks have to wait in a queue until the previous once are done sending. Am I right?

That's not quite right.

There are two main threads involved in the network code, the network thread and the message handler thread.

The network thread receives data from peers, parses it into messages, and puts those messages on per-peer queue for processing. It only serves one peer at a time, but is not restricted to processing full messages. For example when only 10 kB of a block have been received, it will process those 10 kB, and continue with another peer. When all TCP packets for a particular message have been completed, the full block message is given to the message handler thread.

The message handler thread is what implements the P2P protocol - it knows how to respond to various incoming messages. It works on a single message at a time, but it never needs to wait for incoming messages - the network thread already dealt with that. If a message is to be sent back in response to an incoming one, that again isn't done directly - it's put on another per-peer queue, where the network thread will pick it up and send it out incrementally until it is gone.

So while it is true that the message handler only operates on full messages at a time, it never needs to wait for a message to be received or sent out on the network.


How will the Bitcoin network look after BFL ASIC hardware shipments? There have been over 7000 pre-orders of BFL SC series mining machines, with the cheapest one supposedly running at 3.5 GH/s and the most expensive being 1000GH/s thats a lot of hashes about to be added to the network, these machines are set to ship late october-early novermber. Also in the month following that the number of btc released in a block will be cut to 25. these two events will likely cause a lot of turbulence in the bit coin economy. How will these events affect the Bitcoin network and its economy?

The number of bitcoins issued each day is targeted to at 7,200 BTC per day.  Beginning with block 210,000 that number will drop to 3,600 BTC per day.

The distribution as to which miners will be getting the newly issued coins will change once ASICs are out, but the actual quantities issued will not.  (Well, there could be a few thousand extra coins for a few days but then it will readjust back to the target).

Therefore, there will be very little impact on the "Bitcoin economy" due to the introduction of massively greater hashing capacity that will come from ASIC designs entering Bitcoin mining production.

As far as the block reward subsidy drop from 50 BTC per block to 25, that is already known -- the date might vary a week or so earlier than the current target (November 30th, 2012), but generally it is known when and to what degree (50 to 25) it will happen so it is likely already priced in for the most part.

Thus again, the "Bitcoin economy" probably won't be impacted by speculators or miners rushing to buy.


Is there any chance of the Ripple gateway market NOT consolidating into a small transnational oligopoly? Bigger and better reputations might beget more business and so on. What can possibly prevent emergence of a small oligopoly of transnational Ripple gateways ?

That wouldn't really be a bad thing if they were reliable and kept costs down. But I think it's inevitable that, if Ripple catches on, small gateways will always be around at least to serve more remote and underbanked areas and populations that transnationals can't be bothered to target.

However, I don't think the barrier to entry will be that high. You might think that a small company couldn't compete with a larger company because trust is required. But actually, a gateway can operate without people trusting it. The gateway can basically resell another gateway's IOUs for cash. And for getting cash out, the gateway can accept other gateway's IOUs. I think there will always be "gateways" of this type selling and buying IOUs in person.

Over time, if the gateway continues to operate reliably, people will hold its IOUs. This is especially likely if the gateway offers some advantages such as a lower transfer fee or the ability to costlessly exchange their IOUs for IOUs from a number of other gateways.

Of course, transnationals may be able to eliminate this opportunity by providing their own costless inter-gateway exchanges and keeping their own transfer fees low. But if they serve everyone at low cost, nobody should much care that there isn't much competition.

A model that I frequently use to think about the relationship between gateways is Internet service providers. They compete with each other, but if they don't also inter-operate with each other, none of their customers will be happy and they will move to other providers that inter-operate with their competitors better. Small Internet service providers don't exactly compete on a level playing field, let's be honest, but they still have little problem finding niche markets.


The randomness of vanitygen is secure enough? If two people running vanitygen 1abcdefg What is the chance that both of the person will get the same public key & private key?

I hope that the answer is less than 0.0000001. But for this vanigygen need to use random algorithm (not simple while(true){ i++; test()}).

My question is: Usually when I create wallet, using http://bitaddress.org I need to Move your mouse around to add some extra randomness, but vanitgygen do not do this method.

By inspecting the code of vanitygen in GitHub I see that they use random functions. Can I trust it? Is it really random? How it can be secure? Is it use the machine time or what?

If two people running vanitygen 1abcdefg What is the chance that both of the person will get the same public key & private key?

If a billion supercomputers each tried a billion keys per second for a billion years, the odds of a key collision would still be less than one in a billion.

  I hope that the answer is less than 0.0000001.

Yes, much less.

  But for this vanigygen need to use random algorithm (not simple while(true){ i++; test()}).

It just needs a random starting place. You can increment from there if you want to. The number of possible starting places has 77 digits when expressed in decimal notation.


RPC server with bitcoin-qt and bitcoind has a different set of commands? When running bitcoin-qt -server, I am able to run the getbalance command, and the help command shows many items:

~ > bitcoin-qt -regtest -server  # Running in another shell

~ > bitcoin-cli -regtest getbalance
2797.99990000
~ > bitcoin-cli -regtest help | wc -l
69

Trying the same thing with bitcoind gives me fewer commands and no access to getbalance:

~ > bitcoind -regtest -server  # Running in another shell

~ > bitcoin-cli -regtest getbalance
error: {"code":-32601,"message":"Method not found"}
~ > bitcoin-cli -regtest help | wc -l
31

Is this a limitation of bitcoind or have I incorrectly configured it?

I'm using 0.9.1:

~ > bitcoin-cli --help | head -1
Bitcoin RPC client version v0.9.1.0-g026a939-beta

~ > bitcoind --help | head -1
Bitcoin Core Daemon version v0.9.1.0-g026a939-beta

~ > bitcoin-qt --help | head -1
Bitcoin Core version v0.9.1.0-g026a939-beta

Just discovered the problem. It has to do with the "wallet" being disabled in the code via the default configuration with my package management.

I investigated the source initially and saw that there is a bunch of commands that are only enabled if the wallet #define is enabled: https://github.com/bitcoin/bitcoin/blob/e18bc583d41d97cdab93b7ffd111402628cfba19/src/rpcserver.cpp#L268

From there I was able to work out that the build options has disabled the wallet. I'm on Arch Linux, which the user-contributed package (on the AUR) has been configured to disable the wallet by default.

In other words, PKGBUILD configuration has added --disable-wallet to the  ./configure arguments as you can see here: https://aur.archlinux.org/packages/bi/bitcoin-core/PKGBUILD

As if the time of posting, the ./configure command is:

./configure \
    --prefix=/usr \
    --sbindir=/usr/bin \
    --libexecdir=/usr/lib/bitcoin \
    --sysconfdir=/etc \
    --sharedstatedir=/usr/share/bitcoin \
    --localstatedir=/var/lib/bitcoin \
    --enable-hardening \
    --with-gui=no \
    --disable-wallet

Modifying PKGBUILD by hand to remove the --disable-wallet argument fixes the problem.


Bittrex API 3 minute delay I'm noticing that the Bittrex API (both v1.1 and v2.0) have a 3 to 4 minute delay when getting data, i.e. GetLatestTick:
https://bittrex.com/api/v2.0/pub/market/GetLatestTick?marketName=BTC-NEO&tickInterval=hour

So if you make a request say at 8:00PM, it will not bring the 7:00 to 8:00PM candle data until 8:03PM, some times 8:04PM ...

I thought about constructing my own candles querying the API every few seconds with /getticker - but for a few cryptos it will get lengthy and might get banned for the amount of requests per second ...

Anyone knows any other method to get candle data sooner?

Thanks!

I have noticed the same. I am afraid that we have to live with it since even on bittrex website charts are delayed by 3 minutes approximately. You can see that if you get the 1-minute chart plotted. Market history is on time though. If you need this sort of speed, you could build a script to catch ticks from market history list.