Possible To --enable-wallet After Syncronization With Blockahin? I am running bitcoind from the command line (--without-gui) and my system apparently does not have the correct Berkley DB version (4.8+). Therefore, I chose to run the program without the wallet enabled (--disable-wallet) so that Berkley DB would not be required.
What I am now wondering however, is if I sync the entire blockchain (300GB+) and at some point want to --enable-wallet, will I be able to do so without any incompatibility issues?
Furthermore, how can I update to the correct version of Berkley DB (4.8+) so that I can --enable-wallet. I already ran the script $home/bitcoin/contrib/install_db4.sh which did not alleviate the error when running ./configure to test the system for compatibility. I still get the error that the current version is incompatible.

What I am now wondering however, is if I sync the entire blockchain (300GB+) and at some point want to --enable-wallet, will I be able to do so without any incompatibility issues?

Yes, there's no issue with this. You will need to rebuild with --enable-wallet (or use the release binaries which bundle BDB), but this will have no impact at all on the synchronization state. You can switch between having the wallet compiled in, and back with no concerns.

Furthermore, how can I update to the correct version of Berkley DB (4.8+) so that I can --enable-wallet. I already ran the script $home/bitcoin/contrib/install_db4.sh which did not alleviate the error when running ./configure to test the system for compatibility. I still get the error that the current version is incompatible.

Depending on your distribution, you almost certainly have a version which is too new (5+), and many distros don't bundle old versions of it anymore. Bitcoin Core uses a very old version for compatibility, as newer versions would produce a wallet that can no longer be opened in older versions. Eventually this will be removed as a dependency except for some importing tool, but for the moment we just have to deal with it, or use the static release binaries which are reproducably built.


how to stop bitcoin transfers from unknown parties? How can you prevent bitcoins from unknown parties being transferred to any of your bitcoin addresses? if so, how? If not, why not?

Receiving Bitcoins is entirely passive. The receiver plays no part in the process whatsoever. There is no way to refuse a Bitcoin transaction, other than to transfer the Bitcoins back to the sender.


I am unable to sync with the network because I have too little disk space I downloaded Bîtcoin Core on a laptop without knowing it takes up a lot of space and my laptop has only 128 GB disk space. It keeps saying "low disk space" so it won't sync. I sent lots of bitcoins there a while ago and was wondering if there's a way to retrieve them.

I would suggest running bitcoin core in pruned mode if you don't have enough space to for the entire blockchain.

You can start bitcoin with the -prune=X command line argument or put prune=X in your conf file, to limit the amount of space used by the blockchain to only X megabytes. It will delete the old blocks and keep only the most recent blocks on your computer.

Related answer: How to free up the space taken by bitcoind?

Alternatively, if you just want to recover your coins, you can backup your wallet file and move it to another computer that has more space for example.


Can a unconfirmed transaction be lost or modified? I am beginner and I am still learning fundamentals of block and bitcoin network.
Suppose, I do a transaction on bitcoin network, it is marked as unconfirmed transaction and is stored in mempool of full nodes.
This unconfirmed distributed over network, at some point a minor will create a block which will contain this transaction.
My question is where these unconfirmed transactions are stored before being included in block or hence block chain?
Can they be modified before a minor put them in blockchain?

where these unconfirmed transactions are stored before being included in block

Mempool
Each node (wallet, miner, etc) stores them in a local collection called the "mempool". The name implies these are typically kept in memory (RAM) but the developers of each wallet software can decide whether to also store the data onto non-volatile storage such as disk.

Can they be modified before a [miner] put them in blockchain

No, because they are each signed
Modifying the transaction would make the transaction signature fail verification.  Only the person who knows the secret number known as a private key can produce a valid signature for a transaction. The inputs to a transaction are locked by a script that can only be satisfied by a number resulting from the use of the private key.
Every other node (wallet, miner etc) would reject a modified transaction and start to suspect the source as being potentially malicious.


I sent bitcoins to my wallet before it had synced. is there ANY way i can get my coins back? I downloaded Bitcoin. qt and started the sync (which was going to take about 6 days UGH) so about 4 days into it i tried to open the app and Now the app shows "error loading blkindex.dat" So i cannot access my wallet on my computer and never really got a chance to backup or encrypt anything...

I've tried using blockchain.info's desktop sync function but literally nothing happens when i press "download address list" on step 3...????

I have also tried MtGox but i can't find anywhere to upload my wallet.dat file...

Is there ANY WAY i can get my coins?

I'm running Mac OS X. Be as specific as you can please :)

As long as your wallet.dat file is uncorrupted/unstolen, your coins are fine. Try backing up the wallet.dat file, uninstalling Bitcoin, then reinstalling.


Is the minimum amount of money required to purchase >50% hash power equal to max worth of all existing bitcoins? 20 BFL Bitforce Mini Rigs (each, $30k) will give about 30THash/Sec hash power for $600k. That's way above 60% of hash power of then total 51THash/Sec.

10.694M total Bitcoin * $18.5 current mtgox best ask rate = $197.839M

So, BFL should ship at least 6595 such miners, or price it based on, (total worth of all Bitcoin / no of miners planned to ship).

Does this mean, these miners priced so low, or currently bitcoins comparatively valued so high? Or, these two parameters just unrelated?

Please note that these miners are yet to be shipped.

OK, the question here is worthless anyway for 2 reasons.

Getting 51% hashing power over the network doesn't give you all of the Bitcoins.  All that does is allow you to spend Bitcoins, and then later roll back the blockchain and spend them again.. If you've let the blockchain commit 6 blocks to get a "real" transaction committed, then it's going to take you a while to undo that whole chain as the rest of the network continues to run away from you with the soon to be previous real blockchain.  That's going to be expensive because if one person or group thinks they can do it, then you can bet two people or groups will think they can.. All so you can buy your pizza again with your same bitcoins, and steal some petty amount of money from whomever you spent it with the first time.. Your reward isn't all the money (unless you think you can catch up 4 years of signed blocks.. dunno maybe you could), and even if it was, it wouldn't be worth it.
If you do pull off this Bitcoin coup.. What are you really going to do? It isn't run away with 200 million USD. It's destroy the value of Bitcoin.. at least until balance is restored (in which case, you've stolen nothing). You think Mt Gox is going to let you cash out when you send them the coins from their wallet that you've taken by rewriting the blockchain? Do you think they even could? You think you'll find the market depth to cash it all out? I can tell you now.. You won't.. Even if you use all the exchanges, it won't be there.. You'd be stealing more coins than actually exist. I know I've personally destroyed 280 of them. I've heard of many others destroying more.. You'd get them back in the full rewrite of the blockchain required to steal everything, but the USD behind those doesn't exist on the exchanges.. It never did.. In theory, you could steal the sum of all the asks on all the exchanges if you could undo enough transactions to do so.. If you didn't time it right though, a lot of them are going to go away as the price plummets like it was two July's ago..

Satoshi's genious wasn't making it impossible to cheat the system (although it is very difficult), it was making it so that it was not to your advantage to do so. If you can hit 51% or greater, your best option is to just take 51% of the new coins.. Maybe occasionally you rewind and undo some large transactions you made with your own coins, but if you did that too much, then you've ruined yourself soon enough..


Bitcoin trading: security I have seen different trading websites on Bitcoin and a question came to my mind:

Security
Why do they require so much identity verification? If I remember correctly MtGox (despite what later happened) when it started, it didn't require any id\bank verification. So my question here is: is identity verification required by law even when dealing with bitcoin trading or is it an anti-fraud system enacted by the trading operator?

All services that deal also with fiat money, apart from cryptocurrencies, must comply with specific AML (Anti Money Laundering) and KYC (Know your customer) rules, which can be more strict depending on their jurisdiction.

AML/KYC Explained: https://bitcointalk.org/index.php?topic=454795.0


If bitcoin have a 21 milion limit...what happens with the lost bitcoins? After reach the 21 million limit, and every year there is some coins that are lost... won't this make the value of the bitcoin go up?

It is never possible to determine which bitcoins have been lost, and which are merely being held unused.  In either case, it means they are effectively removed from the economy.

This means that they aren't being offered for sale on an exchange, nor being offered in exchange for goods and services.  This creates scarcity, and as economists tell us, scarcity (in general) makes the value go up.  It means that those who are offering to sell bitcoins on an exchange have less competition, and can charge a higher price.


How do I move the blockchain file location on Windows? I tried to edit the storage information for the blockchain. Neither the Windows 7 nor Bitcoin qt could do it (it says that the app can't open the configuration file).

So I tried to edit the -datadir in in Bitcoin qt. The app doesn't give me a response for the command (I thought it had worked but the blockchain was yet being download in my desktop).

I don't know how to create the symbolic link that someone has wrote in another question. Can someone give me some information that I may had misread?

Go to Settings > Options and click the Reset Options Button. Note that this will clear all of the options shown there, so note down what they all are so you can set your options again later.

In the Dialog that appears, click Yes and Bitcoin Core will shut down. Now go to the Bitcoin data directory and copy the entire thing to wherever you want it to be. The data directory on Windows is located at %APPDATA%\Bitcoin. Move the contents of the data directory to the location you want Bitcoin Core's data to be.

Start Bitcoin Core again. You should be prompted to choose the data directory. Choose a Custom data directory and set it to wherever you moved the data directory to. Then set your options again.


Transaction failure due to "made-up" transaction For instance, if I am trying to send 1 BTC to an address, however, I do not have enough BTC. What will happen to this transaction?

Will the sender and the recipient both receive notification regarding the status of transaction?

Unless you are using modified software, your software will not allow you to create such a transaction.

Even if you succeeded at creating it, the transaction is invalid. Invalid transactions don't get relayed on the network, so your recipient would never learn about it.


Sender, nodes or miners? Who validates transactions? I have been reading a lot about the validation of transactions. I understand the actual method in which a transaction is composed (inputs and outputs). However, I don't know what happens with that transaction once its "ready":

Do miners check it before including it in a block?
Do other nodes check it and where there is a certain consensuous miners include it into a block? Who composes the blocks then? Are all miners trying to solve the same block at the same time or different blocks?

Thanks in advance

Other nodes check if the transaction is valid, and if it is, they relay the transaction to other nodes. Mining pools have also (at least one) nodes, they verify it too, and if it's valid and the fee is enough, they put it in the block they're working on.
Do miners check it before including it in a block?

Yep. If they include an invalid transaction, the other nodes will not accept that block, and that miner won't earn the block reward for that block. (currently 125k dollars!)

Do other nodes check it and where there is a certain consensuous miners include it into a block

Yes.

Who composes the blocks then?

Miners.

Are all miners trying to solve the same block at the same time or different blocks?

They are trying to find a block with the same height, but with different transactions, different nonces (a random number - related to block hash and difficulty) and different block reward addresses.


Bitcoin-core how to get all transactions hashes? Please, can anyone help me how to get all transactions hashes? How to browse all the transactions hashes used in blockchain?

P.S. How simply get a list of all transactions IDs (as a simple text list) if I only have running syncronized bitcoin node on my PC and I do not have any other data such as addresses or something else?

Browse BlockChair to find the list of transactions: https://blockchair.com/bitcoin/transactions

Then uncheck every box other than TXID (hash):

https://blockchair.com/bitcoin/transactions#f=hash

Then use export, and pay them if needed.


Low hashrate with cgminer 3.7.2 kalroth edition @ ubuntu 13.10 x64 @ R9 290 MSI GAMING EDITION @ 16 gb ram @ core i7 860 I'm trying with (below my sh file):

export DISPLAY=:0
export GPU_MAX_ALLOC_PERCENT=100
export GPU_USE_SYNC_OBJECTS=1
cd /home/x/cgminer-3.7.2-kalroth/
find *.bin -delete
sleep 3

cgminer --scrypt -o stratum+tcp://stratum.fast-pool.com:3333 -u user.x -p pass --thread-concurrency 24550 --lookup-gap 2 --auto-gpu --gpu-engine 950 --gpu-memclock 1250 -w 512 -I 20 --gpu-powertune 20 --auto-fan --gpu-fan 40-100 --temp-overheat 90 --temp-target 85 --temp-cutoff 95 -g 1

This gives me average ~660 kh :(

I was trying also with config from GUI miner for windows called "R9 290 high":

cgminer --scrypt -o stratum+tcp://stratum.fast-pool.com:3333 -u user.x -p pass --thread-concurrency 32765 --lookup-gap 2 --auto-gpu --gpu-engine 950 --gpu-memclock 1250 -w 256 -I 20 --gpu-powertune 20 --auto-fan --gpu-fan 40-100 --temp-overheat 80 --temp-target 75 --temp-cutoff 85 -g 1

but it gives e something like this:

 [2014-02-13 11:00:29] Started cgminer 3.7.2
 [2014-02-13 11:00:29] Started cgminer 3.7.2
 [2014-02-13 11:00:29] Probing for an alive pool
 [2014-02-13 11:00:29] Pool 0 difficulty changed to 128
 [2014-02-13 11:00:34] Maximum buffer memory device 0 supports says 774897664
 [2014-02-13 11:00:34] Your scrypt settings come to 2147287040
 [2014-02-13 11:00:34] Error -61: clCreateBuffer (padbuffer8), decrease TC or increase LG
 [2014-02-13 11:00:34] Failed to init GPU thread 0, disabling device 0
 [2014-02-13 11:00:34] Restarting the GPU from the menu will not fix this.
 [2014-02-13 11:00:34] Try restarting cgminer.

Above configs works fine (better hashrate) on windows 7 64, but i prefer to use ubuntu beacause windows is unstable.

Anyone can help me?

I have installed latest catalyst, sdk ofcourse.

Since you have R9 290 you likely need patched Catalyst drivers as well as patch cgminer itself as described here. If you already done so, then search reddit and experiment with different configurations. You should be getting around 840-870kH/s with your card.


How do you extract the sending and receiving addresses, and the amount, from a Bitcoin transaction? I'm trying to write software in Elixir to do it. I have the source code for BitcoinJ, but it's quite laborious figuring out what it does. If I look on bitcoin.info, I can see this block

https://blockchain.info/block/00000000000000000028d1186d6dc9191a6ec93624141031e31814e22e75e0c5

has transactions including 2c1a83d5a511399f151571ff26925764ef73081251c239dd2eb6904304d7bcba

from which blockchain.info has deduced

1PSfpNCcY9uNh1QEitLLLGaDX5LicnBJhx sent 12 BTC to

3PK9abqzd2oK3yWgESSZ6Ps1wPBBu222VW and 0.0789 BTC to

12AE3fQj1CsSGL9c3aZpkSDz991KUxntvB

I want to find out how it deduced it. Thanks for any information.

Bitcoin transactions are serialized into a hex string that contains all the necessary information to execute the transaction such as input and output values and origin and destination addresses. Blockchain.info decodes transaction hex strings to show this information.'

We can take the transaction you listed as an example and decode it:

Starting with the transaction hash:
2c1a83d5a511399f151571ff26925764ef73081251c239dd2eb6904304d7bcba

We get the hex string using blockchain.info's api:

https://blockchain.info/rawtx/2c1a83d5a511399f151571ff26925764ef73081251c239dd2eb6904304d7bcba?format=hex

Which gives us the hex:

0100000001923f8a599a04a21ef10da6330a21d29fe162d653267da012d6eededb55702e4e010000008a47304402203207e257255a21ac32fe2203f3356f6a5303b8cfca6a6b66c16a23d68f818ff902206a83cce8450aac66f300f0579d4274c6d9852ef3ea74826c9817b87dd9a0abec0141049778e7a85cad5d71cec7fde276842f744f0615897a3f28015489bf2b4bbfda11227e84ff553d7d0762baf5ff50371dfec0c1bf6f5a8ff9937e6bc9c431297981ffffffff02008c86470000000017a914ed3001d36afe91700b20d07bef089323daacc6788750647800000000001976a9140cb6c275be7f179883bb821ef1dfd6b520fc656988ac00000000

Almost all bitcoin libraries (in whatever language) have functions to decode hex strings. Here's an online service that lets you decode the hex:

http://chainquery.com/bitcoin-api/decoderawtransaction

Pasting the hex from above will give you information about the transaction.


If I am spending multiple inputs from the same address, must I provide a signature for each input? Suppose I have two inputs belonging to the same address.

Do I need to provide a signature script for each input that proves that I own it? Wouldn't that waste space? Also, in the standard client, are the signatures exactly the same, or are they two different but valid signatures?
Or can I prove that I own that address just once?

Do I need to provide a signature script for each input that proves that I own it?

Only signing and checking signatures once for each public key, assuming signed with SIGHASH_ALL, seems like it would be safe, but I don't think there's any such optimization in the bitcoin code. If something was signed with SIGHASH_SINGLE, though, then it wouldn't be okay to assume that the owner of the key approves of all other outputs too.

  Wouldn't that waste space?

Yes, and signatures are the largest single component of a bitcoin transaction, so it's a non-negligible space too. At the same time, though, spending from two UTXOs that were sent to the same address probably isn't the most common type of transaction.

  Also, in the standard client, are the signatures exactly the same, or are they two different but valid signatures?

Looking at the SignatureHash code, the input scripSigs are all emptied and then only the one corresponding to the input that is being signed is filled with the previous scriptPubKey (for somewhat strange reasons).

// Blank out other inputs' signatures
for (unsigned int i = 0; i < txTmp.vin.size(); i++)
    txTmp.vin[i].scriptSig = CScript();
txTmp.vin[nIn].scriptSig = scriptCode;

This makes it so that the hash that needs to be signed (the result of SignatureHash) is different for each input. Thus, since different data is being signed, the signatures will most definitely be different. Even if the data being signed were the same, ECC signatures are non-deterministic (involving a random number) and so will not be the same from signing to signing.

EDIT: The long and short of it is that the double hash that needs to be signed is different for each input in the new transaction, so even if the same key pair is being used, a new signature must be calculated.


Why does hash of new created block must meet certain requirements in blockchain? I am a very very beginner with blockchain. I've read a lot of articles and can't understand one thing. When data miner is creating new block, the hash of such block must meet certain requirements. As I understand this is the key difficulty for creating new block. However, as a programmer I know that it is very easy to create new hash. Can anyone explain what is the reason of such requirements?

The hash must be less than or equal to a certain target hash. This is to reduce the probability that any random hash you choose will be a valid hash with valid work. The whole point of this is to prove that you (as a miner) did, on average, a certain number of hashes (work) in order to find the block.


Why are there multiple input addresses in one transaction and are they linkable to one single address? For example, see this transaction:
https://blockchain.info/de/tx/517c634fcf802bb8114516bc32718acf8a4e360decb7d93859e913f958d7bb6d

In my understanding, the bunch of input addresses (usually) come from a single HD wallet. I.e. a transaction input address is hierarchically derived from the previous one and so on. Is this true for every transaction? What else could be a reason for multiple input addresses?
Is there any way/method/ready-to-use-script that I can input with some address from an HD wallet and that generates a series of child addresses?
Say, I know some (hierarchically older) address of the user who sent this transaction. This method would allow me to compare the thus generated child addresses against the input addresses visible in the transaction. Hence, if there is a match, I would be able to link this transaction to this particular user. Is this train of thoughts correct?

The bunch of input addresses (usually) come from a single HD wallet.

That's one possibility.  It could also be that they come from a non-HD wallet, so that they correspond to a bunch of independently generated private keys that happen to belong to the same person.  Or they could all belong to different people, who have agreed to combine their coins and send them somewhere.  There's no way for us to know for sure.

  a transaction input address is hierarchically derived from the previous one

That's not completely correct.  A public key in an HD wallet is derived from the previous one together with the master extended public key.  Unless you know the master key (which would normally be kept secret), you can't determine what the next key in the sequence would be.  Hence you cannot find out what other keys / addresses belong to that user.

The complete technical details of how key derivation is done are in BIP 32.


How do I generate a paper wallet for Bitcoin Cash I can't find any tools to generate Bitcoin cash paper wallet - any ideas?


Why don't miners charge more for high value transactions? I know high and low value transactions take up the same amount of space in the blockchain.
But wouldn't btc be more economical and fair if miners deliberatly chose transactions based on the value/fee ratio?
That way small transactions became cheaper and more viable

Miners don't charge anyone.

Users put aside some amount of satoshis to incentivize a miner to include a transaction in a block, as the miner takes those satoshis if they are successful in mining that block.

A miner has the incentive to maximize their own profitability by including the highest paying transactions into their block, and to squeeze as many in as possible to maximize that revenue.

The idea that miners might reject some large value transactions because they don't pay a higher fee is incompatible with their incentives, which are to compete with other miners for those transactions which pay the most per weight unit. If a miner decided not to include transactions with sufficient fee, some other miner would include them, and be more profitable than the miner who didn't. It only makes sense then that the miners will continue to operate as they currently do because attempting to adopt a strategy like you suggest would be harmful to them.

Ultimately, miners do not control anything. They merely attempt to profit from what the market is offering.


Mining Process - Transactions Selection I started reading about Bitcoin a few weeks ago. Reading most the information and watching videos on the web, I though I understood about the mining process. However, I was shocked when I realized than all the 2^32 combinations of possible values of Nonce can be found is less than 1sec with the current mining hardware. I was even more shocked when I saw the explanation that the mining process also includes the selection of each transaction will be processed. Thus, mining process is much more "try to find the transactions" that will provide the solutions than really try to find the correct Nonce. When the solution is found, then does the miner publish the list of all transactions he selected, the Merkel Root and the Nonce. If the miner's solution is correct, he receives the block reward (currently is 12.5BTC) plus all the transactions fees included in the publish list (not all initial transactions).

At the same time, the concept of "Priority transactions" (https://en.bitcoin.it/wiki/Transaction_fees) no longer applies , since the miners choose the transactions to be processed.

Is my understanding correct?

Most miners today simply use sort transactions by fee/byte and include them in blocks. This is optimal strategy for revenue maximization(ignoring the knapsack errors).

When the nonce space is exhausted, miners can either change the timestamp of the header or they can use the additional space in the first transaction(called coinbase) where they can put random data. Changing this random data changes the merkle root, on which you try out 2^32 nonces.

So, to answer your question miners don't necessarily try to find new transactions that will find the solution, they can mine the same set of transactions with a little change in first transaction that does not affect the outputs any transactions in the block.


Chain accepts parameter db, which can have multiple backends.
By default it will be stored in memory. So this tip is coming from memory.

If you want to store it to File(For example full node stores it in PREFIX/chain) you need to pass db with backend(ldb for example) and specify either prefix or location.

prefix stands for general directory where chain and wallet will be stored.
location specifies DB directly.

So if we wanted to store this db in /tmp/testnet-1/chain.ldb We could specify:

const chain = new Chain({
  network: 'main',
  db: 'leveldb',
  location: '/tmp/testnet-1/chain',
});

or

const chain = new Chain({
  network: 'main',
  db: 'leveldb',
  prefix: '/tmp/testnet-1'
});


Decentralized democratic voting Has the fundamental problem in cryptovoting, one person, one vote, in a completely decentralized or blockchain centric manner been solved?

In other words, how can votes be allocated in a decentralized manner?

The intent of this question presupposes that vote allocation is not delivered by a state, that a blockchain itself can at the very least implement a completely basic, pure democracy: truly one person, one vote.

How can this intent be implemented?

This problem is not solved by the blockchain or the Bitcoin protocol. By "cryptovoting" I'm assuming that you mean that an individual signs his or her vote with his or her private key. The problem is that anybody can generate a new private key on a whim. The private key would have to be verifiably tied to one individual's identity, and that individual's identity would have to be exclusive to all other entities in the voting network. (DNAcoin maybe? kinda cool, kinda scary)

Note: I just googled DNAcoin and obviously found a thread on Bitcoin talk: https://bitcointalk.org/index.php?topic=187991.0

While a Bitcoin-based voting system could implement a "1 vote per 1 private key" rule, the pseudo-anonymous nature of the Bitcoin network makes it nearly impossible to know if an individual has generated two private keys (unless the transactions make it apparent that it is the same individual). Generating a private key is as easy as flipping a coin 256 times and recording the results as 1 or 0, then converting that into hex (or tonal if you're Luke-jr).


Autonomous Loop channel Can I have an autonomous loop channel with myself where I would suck all excess inbound/outbound capacity to/from channels I have with other parties? In such a case, I would not have to even burden Bitcoin blockchain with the looping activity.

Yes you can rebalance your channels by creating circular onions. That will also cost you routing fees which are currently low.
However in order to get onchain funds you would have to close a channel (or open a channel if you want more liquidity). This means you cannot really swap on chain with off chain funds to provide yourself with inbound liquidity - wich is what loop / submarine swaps are for.
If you use c Lightning you can use the rebalce plugin https://github.com/lightningd/plugins/tree/master/rebalance or the drain plugin: https://github.com/lightningd/plugins/tree/master/drain depending on what exactly you want to do you might have to fork these plugins


How is the monetary part of bitcoin stored? How is the monetary aspect of a bitcoin stored?
I understand that the blockchain is a set of records documenting transactions. I've also seen that blockchains in general can store arbitrary information (such as contracts, small notes, etc).

What I don't understand is how monetary values are recorded, exchanged, and divided.

Is a literal number value encrypted into the transaction? Or is it something more abstract?

Within the Bitcoin protocol, each Bitcoin is represented as 100000000 satoshis. Therefore, you can divide bitcoin up with a precision of 0.00000001.

In a transaction, the number of satoshis being delivered to each output is recorded, along with a record of which previous output is being spent.

The fee is then derived from sum(Inputs) - sum(Outputs). The actual representation of the amount itself is encoded using the Variable Length Integer representation


Can you let us know, which tool or software you used to generate this output? I have one observation:

    47: OP_DATA_0x47:        push hex 47 (decimal 71) bytes on stack
    30: OP_SEQUENCE_0x30:    type tag indicating SEQUENCE, begin sigscript
    44: OP_LENGTH_0x44:      length of R + S
    02: OP_INT_0x02:         type tag INTEGER indicating length
    20: OP_LENGTH_0x20:      this is SIG R (32 Bytes)
        76731C7063163D36:D0650B7573EC46AF
        795C46F7860940D4:EE8A48F7B1C66C0D
    02: OP_INT_0x02:         type tag INTEGER indicating length
    20: OP_LENGTH_0x20:      this is SIG S (32 Bytes)
        CA417E99B3549CE8:0ED1DB7964DB3597
        CABF709CC614A22F:1FE7B81769775D36
    01: OP_SIGHASHALL:       this terminates the ECDSA signature (ASN1-DER structure)

The S-Value starts with CA417E99... this value in a signed int is above the allowed value. See Pieter's post at the bottom of this link.
Values higher than one should be preceeded by "00". But before doing so, it should be checked wether it is larger than N/2. Further explanation here.


How is the hash target set and verified by all nodes? As in the title - I understand that nodes look at the last two weeks of calculated hashes and adjust the difficulty to bring the average time to 10 minutes. But how exactly is this done?

In particular, all the nodes would have to agree on the same target, else a newly mined block would be valid for some nodes and not others. This seems like a problem of consensus (in the traditional sense, not the Bitcoin way) which is very difficult, isn't it?

The difficulty adjustment algorithm is as follows (from the source code):

unsigned int CalculateNextWorkRequired(const CBlockIndex* pindexLast, int64_t nFirstBlockTime, const Consensus::Params& params)
{
    if (params.fPowNoRetargeting)
        return pindexLast->nBits;

    // Limit adjustment step
    int64_t nActualTimespan = pindexLast->GetBlockTime() - nFirstBlockTime;
    if (nActualTimespan < params.nPowTargetTimespan/4)
        nActualTimespan = params.nPowTargetTimespan/4;
    if (nActualTimespan > params.nPowTargetTimespan*4)
        nActualTimespan = params.nPowTargetTimespan*4;

    // Retarget
    const arith_uint256 bnPowLimit = UintToArith256(params.powLimit);
    arith_uint256 bnNew;
    bnNew.SetCompact(pindexLast->nBits);
    bnNew *= nActualTimespan;
    bnNew /= params.nPowTargetTimespan;

    if (bnNew > bnPowLimit)
        bnNew = bnPowLimit;

    return bnNew.GetCompact();
}

The adjustment is only run every 2016 block. What it does is it takes the timestamp of the block at the beginning of the last period (2016 blocks prior) and the timestamp of the block that came before the one with the adjusted difficulty. Those timestamps are then used to calculate the amount of time that passed between the first block in the interval and the last block in the interval. Then that timespan is clamped to be at least 1 quarter of the target timespan and at most 4 times the target timespan. To calculate the new difficulty for this interval, that target is multiplied by the actual amount of time that passed, and divided by the targeted amount of time.

Since all nodes are calculating the target at the same block and with the same previous data, the target calculation is deterministic and everyone will land on the same target.


Mine valid but nonstandard transactions Is there a way to configure cgminer to accept valid but nonstandard transactions for mining?

If not, where, theoretically, would be a good place to look if I was interested in mining nonstandard transactions into the blockchain, i.e. what must I modify in what node/client code?

Alternatively, would it be enough to modify a client to relay such transactions to cgminer without modifying the mining package itself? Does cgminer also verify that a transaction is standard?

I suggest you go and read about just what cgminer is presented with, in most cases it is just the header which has absolutely no bearing on the content of the block. It does not, and can not in most situations know what the work it has been provided with actually is.

The node providing work must be modified slightly by changing the isStandard checks, which you can find in main.cpp of the Bitcoin core client. There's not really that much interesting you can do at present without making your block invalid, but it's easier just to submit them directly to eligius.st which is a pool that already accepts certain nonstandard transactions. The chance of a user solo mining a block is vanishingly tiny at this point.


Please investigate for the reason of no confirmation. Over 2 day zero confirmation. Fee Paid. Please help! Can any miner help confirm my BTC transaction!  Zero confirmation for over 1.5 days now.  Feed was included. Please investigate to find out the reason of this delay, any mistake from the sender or receiver wallet that need to taken care off?  Please help.  Below is the link to the blockchain.

https://blockchain.info/tx/3f4ca76ec5d39f700a6284e1282bfbb77c8be474f810191840d9441fd8e97d81

Your fee is 58.928 sat/Byte. Looking at the current backlog and https://bitcoinfees.21.co/ this might take a while. What wallet did you use to send it? You can try your luck using https://www.viabtc.com/tools/txaccelerator/


Transaction unconfirmed for hours I need any help you can provide me regarding the transaction ea36f903db582e5b87c3618208cae2b28957521b8567f5d7934fc8b47a663bd8

It has been unconfirmed for more than 6 hours and I don't know what to do.

Thanks in advance to anyone who can help me.

Your transaction can be seen here: https://blockchain.info/tx/ea36f903db582e5b87c3618208cae2b28957521b8567f5d7934fc8b47a663bd8

One of the inputs is address 1BPAcceeSNiNEHeeR1wEQDspvcq17jM142. It has an additional unconfirmed transaction at 671454f599c947cc01bf69defe68a6e59e869352006fb8b86df17dd51bc1d1fd. One of that transaction's inputs is 1KhqWzuRSB4cLsAnTtKjf8TGtY7HsNAdM4, which has an additional unconfirmed transaction at 8b780e2d3197ebdaf74688333fefc0fa83a11ff24f687423899354455881c14c. And here is the problem:

Your later transactions cannot complete until their inputs are confirmed. Your only option is to wait at this point.


Selling Test bitcoin I have a random and maybe crazy question. Can I sell test coins? Someone recently told me that Advanced Market Terminal is buying them. It is strange to me Since they should hold no value.

Testnet coins are an interesting thing:

They are useful because they have no value
If they had value, they would be useless

Remember that the testnet is there to test out your code, and ensure that everything runs smoothly before you deploy that code to an environment which is holding actual value. That way, if something goes wrong, you haven't lost anything of value.
So you certainly could sell someone testnet coins, but I'm not sure why anyone would pay you for them.


Will forks and alternative block chains cause hyper-inflation of decentralized digital money? Great effort has been put into Bitcoin's concept of money supply and that there will never be more than 21 million units.

However, it's relatively easy to fork it and create alternate block chains. SolidCoin, IXCoin, IOCoin etc are much less worth, but they can easily be traded against Bitcoin. Does this increase the over-all supply of Bitcoin-like money to well beyond 21 million units? Some believe yes, and that this is one reason already for the recent price drop.

Also, the concept of open and decentralized P2P money is still young. Chances are that a lot of other such currencies will pop up in time. Is there a risk that Bitcoin will be thwarted by an inflation of other currencies, rendering it and all other open, "free", decentralized money worthless and useless?

EDIT: One thing to consider in this context is that the number of traditional currencies will always be limited as there are only so many nation states on this planet (and they are consolidating, e.g. Euro), but the number of decentralized digital currencies is potentially unlimited.

It depends entirely how much those alternate block-chains get utilized. In the recent examples of ixcoin and i0coin, a small portion of btc miners and users switched over, sold their stash and went right back to bitcoin. It's essentially a case of network effect - whichever block-chain has the most users will be the most attractive to new users, and those new users themselves contribute to that effect. Bitcoin is by no means beyond the "tipping point" where forks can no longer threaten it, but short of a fork with some superior feature or another it remains the preferred fork and probably will for some time. Even namecoin hasn't touched bitcoin's user-base much despite having a definitive use built into the protocol.


Electrum on Android - where is wallet.dat hidden? Does anyone knows where Electrum android app saves its wallet.dat on phone/sd memory?
If such files exists is it possible to transfer it between phones?
I have forgotten my seed words (and do not want to move btcs from wallet to another) and wonder if this is an option to transfer this file like on desktop (with wallet.dat file)

Electrum doesnt use wallet.dat file, those are used by Bitcoin Core. Electrum creates wallet files in %UserProfile%\AppData\Roaming\Electrum\\wallets for Windows, /home/user/.electrum/wallets/ for Linux and /data/data/org.electrum.electrum/files/data/wallets for Android. If forgot seed words, move BTC to another wallet and keep backup info safe if you can.


Is it technically possible to send a transaction with two identical destination output addresses? Is it technically possible to send a payment consisting of several outputs, of which two (or more) are the same?

ie input collected 10 btc -> output to 1abc 1btc, output to 1abc 1btc, output to self 8btc (change)?

Will the client allow it? Can it be handcrafted?

I'm building a merchant-type app, and am trying to account for strange, non-standard transactions.

Thanks!

Yes, absolutely.

You can chop a 1 BTC input into 5 equal 0.2 BTC outputs, all to the same address.  These are not strange at all.


Is there any reasonable way to short-sell Bitcoin It is not an official currency (yet?) but definitely has a market, and as such, I might be intrested in short-selling some. Are there any reliable, way to bet against it?

Even though I would strongly advise against it doing a search turns up:

https://icbit.se/
http://mpex.co/

There are probably others but do take into consideration that the majority of these "exchanges" have statements like the one listed bellow (taken from https://btct.co/faq):

  Is it legal for this exchange to operate?   (...)

  No assets on the site are to be considered real.
  The use of this site is for educational and entertainment purposes only.
  If an asset issuer on this site defaults, you have ZERO RECOURSE. (not like you have any recourse in most international BTC situations
  anyway.)


safely delete the blockchain from .bitcoin directory I have bitcoind installed and I'd like to free up space by deleting the blockchain from my .bitcoin directory. What set of files and directories should I delete such that the next time I start bitcoind it will recover gracefully by downloading the blockchain again?

Delete the "blocks" and "chainstate" directories.


Acting as a passive node rather than an active one using bitcoind I currently have a bitcoind version:80500 running on a VPS. I am interested in using it to only verify transactions for me much the same way blockchain.info  does.

Is it possible to run bitcoind to do this? I guess the best analogy to this would be acting as a leecher. Or does it always act as an active node passing transactions etc?

What you are asking for is not possible with an unmodified version of bitcoind. So I will interpret your question as why not and how to achieve something similar.

Having bitcoin nodes that do not relay transactions is a danger to bitcoin: If nodes start behaving that way, not only do we move a tiny step further towards risking that transactions are stuck because someone sending a transaction does not get them forwarded at all, but more importantly, mining exploits like the one described in the preprint Majority is not enough: Bitcoin Mining is Vulnerable move from the rather theoretical to the practical. In fact, someone trying to implement this exploit might ask pretty much the same question as you do!

So what stops you from just doing it anyways, with a modified version of bitcoind? Nothing, really, except that it seems a bit self-defeating. Consider that as soon as others start perceiving it as a sufficient nuissance (and they should, for reasons of fairness and security!), we'll come up with some modification that will require you to forward at least some transactions or not get transactions forwarded yourself. Or get stuck with only similarly selfish nodes to connect to. That'll be the exact opposite of what you want to achieve for verifying transactions. Just consider that eventually you may only see those transactions more likely to not get propagated all the way to the mining pools!

So what options do you have to limit bandwidth (I doubt you can save much CPU time, anyways)? Here are your options:

You already know the most radical answer: Not running your own copy of bitcoind, and instead use the public APIs of blockchain.info and blockexplorer.com (or some commercial solution). I presume you are not happy with relying on free external services, but considering that there is redundancy (to either deal with individual downtime or to get more than one confirmation). So this super-low bandwidth approach (at least for few transactions to actively monitor) may not be quite as bad as it must sound at first.
Limit the number of nodes your bitcoind connects to. This, unfortunately, is a double-edged sword. It simultaneously limits the data you will send out (fewer peers!) and the data you receive. Hence you have a greater chance of being late to see a transaction, if for whatever reason it did not reach the very few (one?) other node you connected to, or because few peers mean you are at an elevated risk of simultaneously lose connection to all of them, being cut off from the bitcoin network briefly.
Modify your client in a sensible way. Maybe you can live with relaying new transactions, but throttling bulk downloads of the entire blockchain? This could potentially have a huge impact on your outgoing (and total) bandwidth, whilst offering the potential for very sensible overall behavior. Consider that it could even make sense for the mainline bitcoind if alternative means of bulk download of the blockchain could be implemented---and as long as we find mirrors for them, this should be doable. In fact, by putting a "blockchain mirror" part of your site behind a free cloudflare account to serve static content at zero cost, you could do it!

May I suggest that option 3 could be the way to go? If the necessary modifications to bitcoind are a problem for you, I could help (or even do it all), although I am sorry to say I probably couldn't do it for free.


How to let surplus go to fundraiser in ANYONECANPAY crowdfunding script? ANYONECANPAY can be used for crowdfunding, where pledged donations cannot be spent unless funding goal/soft cap is reached. But since output is committed, when soft cap is exceed, all the surplus will go to transaction fee. Any way to make the exceeded part to go to the fundraiser as ICOs typically do?

  ALL|ANYONECANPAY

  This construction can be used to make a "crowdfunding”-style
  transaction. Someone attempting to raise funds can construct a
  transaction with a single output. The single output pays the "goal"
  amount to the fundraiser. Such a transaction is obviously not valid,
  as it has no inputs. However, others can now amend it by adding an
  input of their own, as a donation. They sign their own input with
  ALL|ANYONECANPAY. Unless enough inputs are gathered to reach the value
  of the output, the transaction is invalid. Each donation is a
  "pledge," which cannot be collected by the fundraiser until the entire
  goal amount is raised.

No, I don’t think it can be achieved using SIGHASH_ALL | SIGHASH_ANYONECANPAY. Because there is always an output with a preset value, as you’ve mentioned, any surplus will be treated as the mining fee in this case.

However, I think it’s still achievable under a more complex design. Let’s take a close look at the problem. Since it’s crowdfunding, we can assume that,

The participants are willing to donate the money, and,
They want their money back if the crowdfunding fails, i.e., the cap is not reached.

The problem is, if crowdfunding with a cap of 10 BTC is reached, while in the end, it receives a total donation of 11 BTC, how can the fundraiser get the extra 1 BTC as well?

Applying SIGHASH_ALL | SIGHASH_ANYONECANPAY won’t help here, the extra 1 BTC will be treated as the transaction fee. Borrowing some ideas from the lightning network, I think a feasible solution can be achieved using Bitcoin Script. Here’s the draft,

Scenario

Crowdfunding with a cap of 10 BTC is initiated. If the cap is not reached in 60 days, the money is returned to the participants. Otherwise, all the money goes to the fundraiser.

Stage One - the participant sends money

The participant generates a secret, called it payment_secret, and hash it to produce payment_hash(for instance, using RIPEMD160).
The participant creates a transaction with an output, its locking script is specified as follows, in which, there are two possible paths to spend it,

If the payment_secret is presented, the money goes to the fundraiser.
Else, if 60 days passed, the money goes to the participant.

The script,

OP_IF
    # To the fundraiser if payment secret is supplied
    OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
    <fundraiser_pubkey> OP_CHECKSIG
OP_ELSE
    # To the participant after 60 days
    <60 days later> OP_CHECKLOCKTIMEVERIFY
    <participant_pubkey> OP_CHECKSIG
OP_ENDIF

where, the fundraiser can spend it using <fundraiser_sig> <payment_secret> 1, and the participant can spend it using <participant_sig> 0.

Stage Two - the fundraiser collects/returns the money

If the cap is reached, the fundraiser will ask all the participants to reveal the payment_secret to him/her. The fundraiser will be able to get all the money, even it’s beyond the cap. To spend the outputs, the fundraiser use <fundraiser_sig> <payment_secret> 1 to unlock them.
If the cap is not reached, i.e., the 60-day time limit has reached, all the participants can now take their money back, using <participant_sig> 0 to unlock them.

So the surplus problem is solved, but this approach has many downsides,

There are too many transactions, especially comparing to the SIGHASH_ALL | SIGHASH_ANYONECANPAY approach, although it may be optimized.
The participants need to know how much money has been raised. This requires the fundraiser collecting all the transactions and show them to all the participants, which might require a centralized service, e.g., a website.


How can P2Pool charge a fee? P2Pool is an open source peer to peer mining pool. It currently charges a fee of 0.5%.

Is it possible to just fork P2Pool protocol and eliminate the fee? Has this been done? If so, how can P2Pool still retain users when a cheaper alternative remains? If this hasn't been done yet, why not?

Since November 17, 2011 no fee is charged.  Instead an optional donation of 0.5% is sent to the author of P2Pool to support future development.

If you don't want to donate to the author you can run P2Pool like this:

python2 run_p2pool.py --give-author 0.0 [USERNAME] [PASSWORD]

The 0.0 is a percentage of your earnings and can be set to whatever percentage you like.


Why are there ETH addresses in bitcoin wallet.dat? So I have a lot of addresses or pkscript listed in my wallet.dat files that begin with 0014....all...numbers.

There is bitcoin address on the same line starting with a 3.

When I strip the 0014 and search the blockchain, they all bring up an ETH address with 0 ETH.

Who can explain this?

Ethereum addresses are the trailing 20 bytes of keccak256(public_key). In other words, ethereum addresses are any collection of 20 bytes.

0014{20 byte payload} in Bitcoin is the redeem script for a p2sh-p2wpkh address. If you strip the 0014, you're left with 20 bytes. Due to the size of the ethereum address space, the vast majority of 20 byte combinations will lead to unused addresses.


I am just wondering what are the methods which can hide all the transactions and also able to validate transactions in an block chain? I am new to block chain and was looking at how block chain work mainly proof of stake based . They check validity by going through all the transactions which is something concerning as everyone can see the transactions. So what are ways to hide all transactions and also make everyone able to check validity of new block.
This question is not only for block chain relm but also for cryptography.

So what are ways to hide all transactions

In the blockchain used by Bitcoin it is not ever possible to hide transaction details because the integrity of the whole system depends on those being public.

However the sensitive parts of those details are mostly Bitcoin-addresses and amounts. There is a privacy issue if observers can infer information by comparing use of the same address across multiple transactions.

This is why Bitcoin (for example) is often described as not anonymous but as psedonymous. You can't see people's names in transaction data but you can see the Bitcoin-addresses.

Generally people hide their identity by

never re-using Bitcoin-addresses and by
using coin tumblers.

This makes it very very difficult for third-party observers to associate a transaction with a specific person.


BTC Days Destroyed, Lifo or Fifo? Imagine I've got 100 BTC in my wallet, which I accumulated at different points of time. When spending a fraction of my BTC, e.g. 10 BTC, which one of my 100 BTC do I actually spent? The last one I accumulated (Lifo)? The first one I accumulated (Fifo)?

Neither.  The client chooses the best fit of coins for your spending.  This is known as the knapsack problem.

The coins chosen will be the ones that yield the lowest amount of change, with exceptions for very recent (unconfirmed or newly confirmed) coins.  Even when there are multiple solutions that yield the same amount of change, it will not necessarily choose an older coin versus a newer coin.

Here's an answer to another question that gives more details on this:

https://bitcoin.stackexchange.com/a/1078/153


Can one safely buy vanity addresses from a third party without risking one's coins from being stolen? One can easily generate vanity addresses for Bitcoin, but they can take quite awhile to generate. Outsourcing that process to someone with a strong mining rig is an option, but then one runs into the risk of the person generating the address using it without our knowledge to steal our coins. Is it possible to generate vanity addresses in such a manner so as to make it impossible for anyone to steal your private keys?

From what it appears, yes, it is possible, and quite simple really to outsource vanity address creation to a third party without risking anything.

Bitcoin addresses are created from ECDSA keypairs. Their property is that if you take two private keys and add them together (with appropriate modulo operations), the sum will map to a public key that is the same one as one would obtain by adding the two public keys corresponding to the private keys.

This means that in order to outsource vanity key generation, one can create an ECDSA keypair, store the private key safely, and give out the public key to other people. They would then proceed to generate ECDSA keypairs, summing the generated public keys to the one provided by you, and checking whether they map to the appropriate vanity address. If it does, they need only to give you the appropriate private key, which you then need to add to your secret private key in order to obtain the private key that maps itself to the vanity address.

JoelKatz explained it in his post, and I went ahead and implemented a "vanity pool" that enables such outsourcing. Moreover, I also created a simple testing suite for playing with combining the ECDSA keypairs. Currently there are no "split key vanity miners" available, nor any offline solutions for this problem, but they can follow shortly.


Where is Bitcoin information (wallet.dat) stored on OS X? Is there a wallet.dat for OSX? Where is it located?

Taken from https://github.com/bitcoin/bitcoin/issues/544

The Bitcoin wallet on Mac OS X is located in ~/Library/Application Support/Bitcoin/wallet.dat.

Mac OS X v10.7 (Lion) came out, and it has the ~/Library folder hidden, see the answer from chilled35 to access it with Finder.

  In order to see hidden folders, such as ~/Library from Finder, simply hit shift + ⌘ (command) + G which will GO to a folder, then paste in this location:

~/Library/Application Support/Bitcoin

  From there, you will see all the files associated with your wallet.


Why does Bitcoin store all transaction inputs and outputs, instead of just an "account/balance" ledger? From what I can tell, the Ethereum blockchain just stores accounts and balances - why did the original Bitcoin developers choose the method of storing all transactions for validation instead of just account balances? It seems like that would reduce blockchain size on disk quite a bit...

In order to be sure that an address balance is correct, you need to check that all the transactions on that address are valid.  So in order to generate a list of addresses and balances that you trust, you must first download and verify the entire block chain.

Actually, the way Bitcoin works, what you actually need is a list of unspent transaction outputs (UTXOs).  When you create a new transaction to spend coins, you don't just debit an address; you have to reference one or more specific outputs from previous transactions that you are spending.  Those previous outputs then become unusable, so that you can't spend them again.

Bitcoin Core does actually generate an indexed database of all UTXOs, and refers to it when checking transactions for validity (since this is much faster than searching back through the block chain directly).  This is the closest analogy to the "ledger" you proposed.

Once you've done this, you could delete the block chain itself and just keep the UTXO database; that is basically what the -prune option does (see How can I run bitcoind in pruning mode?).  However, remember that Bitcoin is a peer-to-peer system.  So you keep the block chain so that new users can download it from you.


Verifying Bitcoin ownership Suppose Alice has 30 bitcoins from David. Now Alice wants to transfer amount 20 bitcoins to Bob.

Now, Alice creates a transaction with Bob's bitcoin address.
To prove authenticity and integrity, Alice digitally signs the current transaction.
To prove that Alice owns the money, the current transaction includes hash from David's transaction which can be verified by the recipient and other nodes on the network.

As per my understanding, transactions are collected in blocks which are linked to form a block chain. Every node on the network stores the block chain. To verify whether Alice owns the money, one has to verify the bitcoin address of Alice in David's transaction. Now David's transaction can be very old, in older blocks. How this check is done? Is the hash of David's transaction for Alice's ownership checked in every block in the block chain?

Is the ownership verified by going from block to block?

Also what prevents Alice from using David's transaction again and again?

A bitcoin transaction can have 1 or more inputs and 1 or more outputs. Inputs are previous transaction outputs that sent bitcoins, and outputs are instructions on where to send the bitcoins from the inputs. The total value of the outputs cannot exceed the total value of the inputs, and any leftovers (output is less than input) will be taken as a transaction fee by the miner who created the block that verifies the transaction. Also, an output can only ever be used as an input once.

So, in your example, David's 30BTC transaction is the only input, and you need an output of 20BTC to Bob's address. That leaves 10BTC in change. Typically, you would create another output back to yourself. This is called 'change'. So there will be two outputs, 20BTC to Bob and 10BTC to Alice (or maybe slightly less, providing a fee for miners and encouraging them to verify the transaction quickly).

The actual verification is complex, but a simple explanation would be that a verify-er can traverse the entire blockchain from start to finish, picking up every output and discarding outputs as soon as they are used as an input. When he's done, he's got a list of unused outputs that could be used in future transactions. To verify transactions included in the next block, he just has to make sure the transaction has inputs that are on the list, and that there are no other transactions in the new block trying to use the same input.

So, if David's transaction was used as input in the past, it wont be on the list. If Alive tries to be sly and create multiple transactions at the same time that use David's transaction, the miners will only include one of them.

Meanwhile, once you have your list, you don't really need to traverse the blockchain from the beginning again, you just have to keep your list up to date by reading each new block and removing used outputs and adding new unused outputs. That way, you always have a list of valid inputs.


Hardware-dependent block difficulty? Is it possible to make block production difficulty not the same for every node, but automatically adjusting to the node's hardware speed?
For example, node A and node B are both trying to solve for their next blocks, node A's hardware speed is twice that of B's. Their client software detect their hardware speeds and adjust the difficulty in such a way that B's next block's difficulty is only half that of A's.
Is this possible?

No, difficulty is a network-wide consensus rule. POW mining helps solve the issue of sybil attacks, whereas your idea opens up mining to sybil attacks:

Your idea would create a level playing field for all devices (regardless of computing power), so if I want to expand my mining operation, I would just want to run thousands of mining nodes. Hardware doesn't matter, so I could just use cheap computers, or better yet, a botnet. The more nodes I can make, the better!

Additionally, how can you be sure nodes aren't lying about the hashrate available to them? How can you be sure a user hasn't rewritten the source code of their client to artificially lower the difficulty? Etc.


Why not to mine more efficient? I'm a kinda newbie here. But this is what I completely can not understand.

If every single miner have to 'arrange' transactions and then compute a SHA-256 function of a given memory chunk, and if computed SHA-256 must match a given criteria (so-called difficulty), why not to split such work, and force each miner node to 'compute' (or 'pick') his own range of nonces? I mean, okay, in good old days every miner was on his own, there was a real 'competition' or concurrent race between them, but now times have changed. Now miners gathers into 'pools'. Just look at the chart:

I mean, 28.2% of miners may help each other by tearing this work apart. Are there any less brute but more 'lock pick' ways? If such large segments of the network are now centralized, why not to look for map-reduce approach? Either I've missed some important details, or there is the way. Thanks a lot for the explainations.

force each miner node to 'compute' (or 'pick') his own range of nonces?

You don't need to force them. They will obviously do so on their own - doing anything else would be ridiculous, as the fastest miner would always win if they all try to run the same race.

In practice this is automatic, as every miner pays out to himself. As their payout addresses are different, their coinbase transactions will be different, which means their transaction hashes will be different, which means their Merkle tree will be different, which means their Merkle root hashes will be different, and as a result block header will be different too. In fact, it's impossible for them to be working on the same block template without forgetting to pay themselves!


How is the mempool incorporated in the calculation of the block hash? So I've been reading about how the nonce is calculated. There is one part that I don't get. So there is a mempool, and each node (or mining node) takes a part (or the whole part) of that mempool, computes a merkle root and combines it with a nonce to get a hash that has a certain difficulty level.

Is the mempool (or part of it) is first converted to a hash by the mining software, then enters the nonce calculation?

Are there requirements on how the transactions are ordered when mining a block?

Can nodes choose the order of transactions in a block? Is a node free to choose any order of the transactions that it wants or must it be chosen chronologically?

(feel free to edit the question, I tried to explain it the best I could)

Every node in the network has a mempool. The mempool contains unconfirmed transactions. Each mempool may be slightly different as they constitute a subset of all unconfirmed transactions in the network: Some might not have been relayed to a node, so he doesn't know about them, the node owner has set a higher minTxRelayFee and filtered out some transactions with low fee, or the node owner has set a smaller data limit for his mempool.

Anyway, all of the above is also true for any miner's node. When miners are trying to find a block, they select a set of transactions to confirm from their mempool. From these transactions, they build a Merkle tree.
The Merkle tree allows the whole transaction data to be represented by only the Merkle root. This Merkle root is part of the block header.
Miners get to choose which transactions to include freely, and they can also put them in any order they want, as long as the transactions are valid. Since there are now often more transactions available for confirmation than block space, miners usually select transactions that maximize the fees that the miner can earn.

So, miners have selected some transactions and created a Merkle tree to contain them. They combine this with the other parts of the block header: Time-stamp, Reference to previous block, difficulty statement, and the nonce. The nonce is an arbitrary number, so miners can build a block candidate with all the other data and then try this candidate a lot of times by cycling through all possible values for the nonce.
Every try they put the block header into the hashing algorithm and receive a digest or hash of the data. If this hash satisfies the difficulty statement, the miner has found a new block and will relay it to the network.


How to connect nodes globally? I am running two altcoin clients on different network, connected by VPN. The addnode  command works fine, and nodes connects. But what to do if I want others to connect to my network? The ip addresses i have are local subnet addresses.

You should have at least one node that can be accessed from a public IP address. This might mean setting up your router/firewall to forward your altcoin's port to the internal IP address of the machine.

You might hardcode this (public) IP into your altcoin code if it's static (it sounds like this is a very small, probably made by you, altcoin), and/or hardcode DNS server(s) that point to known node(s) (maybe use No-IP if you're looking for a free/cheap approach with a dynamic IP). These are the same techniques that Bitcoin Core uses to discover your first peers.

Once a new client has connected to its first peer, the peer will tell you about more peers, etc.


Will transaction fees eventually make microtransactions not worthwhile? It seems that one of the strengths of Bitcoin is the ability to send tiny amounts across the globe. If we keep thinking in USD or EUR, we'll wipe out micro transactions altogether (less than 100 satoshi).

So will transaction fees eventually put a lower bound on how small of a transaction can be sent?

A change to the 500KB per-block limit can be done with updating the client without causing a fork, but that only goes up to a 1M block size.  To exceed that 1M limit would require a hard fork and thus it is possible when that limit approached, a larger limit might never happen.

Bitcoin could hit those limits before really even "taking off" even.

Bitcoin was never architected to be a microtransaction system.  It works fine as one for now but eventually that use might no longer be feasible.

There are currently methods to use bitcoins for microtransactions without touching the blockchain.  For example, Mt. Gox BTC redeemable codes have no fee (currently) and could be used, presumably, for microtransactions.  Various approaches will solve the microtransactions problem better than Bitcoin does.

In the meantime, businesses that do use microtransactions can get off the ground by taking advantage of the fact that Bitcoin's is still well below the per-block capacity limit and thus microtransactions are nearly free.

Build a customer base in a market today, solve the technical problems tomorrow.

With Satoshi Dice's growth, for instance, there might soon be enough demand to launch a alternate blockchain for its microtransactions with properties that are useful for that special case.


Why isn't Replace by fee default for all transactions? I know it's a wallet implementation and a flag, but when it was introduced why wasn't this change a rule for all transactions so that anyone could RBF if they wanted to instead having had to set the mandatory flag?

It's been over six years and I've done entirely too little research to state the below with confidence, but what I can roughly piece together quickly between cursory research and from what I remember:
There was a big debate about the merits of RBF since at least 2013, when Peter Todd and John Dillon provided a Full RBF patch. Gavin Andresen described it as anti-social and among others pushed for a First-seen-safe RBF variant which would require a replacement transaction to include all outputs of the replaced transaction. It was pointed out that FSS RBF would only protect transactions that only spent confirmed inputs (since transactions that spent unconfirmed inputs could be invalidated by replacing the parent) and that each replacement would add another change output to the transaction adding UTXO bloat.
Regardless, the full RBF proposal saw strong push-back, especially by a number of services built around zero confirmation payments (IIRC e.g. Satoshi Dice, BitPay). The 2015 compromise was then to require transactions to opt-in to Full RBF and to require that replacements pay not only more fees than the replaced transactions but more than their entire descendant tree to curb DOS attacks. Standard transactions were left unchanged in their behavior.
Obviously, RBF is just a mempool policy and cannot be enforced, so nothing would prevent nodes (or even miners) from individually switching to running a Full RBF mempool policy.


GPU mining strategies (algorithm) I am currently in the process of creating a fairly simple bitcoin miner for CPU and GPU (for demonstration purposes not for money earning).

However I am having a little troubling understanding how the GPU miners generally work. Now I do want a fairly simple version of this, but I hope to be able to get one that performs decently (hopefully within 10-30% of normal miners, and definitely faster than CPU version).

In general I would think the strategy you have for executing on the GPU is something like the below. I hope someone could help me out on whether I am doing something completely wrong and give me some pointers towards how you usually do it.

Transfer the binary version of the data to hash to the kernel (I noticed a lot of input arguments to the OpenCL kernels on some of the versions I have seen, I assume this is some sort of optimizations of data transfer)
Now, calculate the double sha256 hash of the data (Is it generally advisable to have a loop checking multiple nonces or just one per kernel?)
Return a result. What is the best way of doing this? Do I check inside the kernel if it is lower than the desired target, do I just return any value and return to the host device to check for validity or how is this generally done? If checking multiple nonces I assume you should keep track of what was the best result during the run.

I do have a general and very basic GPU implementation but it is currently slower than the CPU implementation I have. I do more or less as above where each kernel check several nonces and return the "best" one (i.e. most trailing zeros of the hash (using getwork protocol) ).

Now that bitcoin difficulty is too high to see much output even on a properly configured gpu with the right drivers, running cgminer at > 100 Mhash/s of sha256d, your learning excercise might be better making an sha256d "altcoin" of < 100,000 difficulty.

In terms of strategy, I think that you want to download a "stratum proxy" which preprocesses blocks from "somewhere" to compute a "midstate" which anything runnning cgminer on your LAN can try hashing with lots of nonce values.  I think that "somewhere" could conceivably be some sort of local testcoin full node which you've poked the source code of.  Whilst "somewhere" could also be a usual BTC mining pool, you won't see enough shares to get bitcoin for your gpu programming.

Next I think that you want to set up your gpu pc with correctly installed drivers and cgminer, so that you can see the text in a terminal showing a reasonable hashrate when you run cgminer with your stratum proxy specified.  You might need to open a port number and do some messing like that the first time it is used, and it took me a few days to get that far on linux.

Once you have seen your gpu working with "ordinary" cgminer, you might want to go into the source code of cgminer, but unfortunately that hides most of the inherant parrallelism of the gpu behind the proprietary binary hardware drivers to which it makes some calls.  It may be that those won't let you use more than 1 gpu core for reasons unknown to me.  You can also call cgminer as a multithreaded cpu miner but that is sooo 2010 that it won't do much with bitcoin nowadays.  Hence my hint that an altcoin or home testnetcoin on sha256d might be interesting.


Why does bitcoin use signatures to verify transactions? Why does bitcoin use signatures to verify transactions in order for them to be broadcasted and mined and is there any other method that could be used instead of signatures?

Any viable system of value needs this simple property: only the rightful owner of the asset is able to spend it. For example: if you owned some bitcoins, but someone else was easily able to spend them, then that wouldn't be a very trustworthy system now would it?

So, we need a system where someone can prove that they are the rightful owner! A naive way to implement this would be to create a secret password that locks your funds, so that you have to attach your secret password to the transaction, in order to spend them.

But there is a problem with this: once you attach your password, anyone else monitoring the system could see your transaction, and just copy the secret onto a new transaction, which sends your money to the attacker!

What is a solution? Using a cryptographic signature allows the owner of a private key to prove that they have knowledge of the secret, without revealing the secret itself! Everyone else can check the signature, and know that it must have been made by the private key for that address, and they can do this without knowing what the private key actually is.

Plus, the signature changes depending on the data being signed, so an attacker cannot just copy the signature to a new transaction to steal the funds (like in the example above). If you use the same private key to sign two distinct transactions, the signature data will be different for each one.

  is there any other method that could be used instead of signatures?

Perhaps there is, but using cryptographic signatures works just fine, and the underlying cryptography has been studied and tested extensively over the last few decades, so we can be fairly confident it works well.

Many other common authentication schemes require some sort of centralized store of data (eg, user accounts for a website, that are accessible by password), so a decentralized cryptocurrency network has some special considerations in this regard. Cryptographic signatures are used in a LOT of different applications though, they are not specific to bitcoin or cryptocurrencies, they are just a useful cryptographic tool in general.


Installed bitcoin-qt and Tor, allowed firewall, Tor connects, but Bitcoin doesn't I did these things but Bitcoin still says 0 connections. What's the problem?

Windows 7 32bit. Installed bitcoin-qt
Installed Tor Browser bundle
I allowed all local outbound connections in my firwall (remote connections allowed only for Tor, for bitcion they're forbidden).
Run bitcoin.exe and enabled SOCKS proxy 127.0.0.1 on port 9050.
Exit bitcoin.exe, run Tor Vidalia, wait till it say "Connected to Tor"
Run bitcoin-qt.exe
Wait, wait, wait... 0 connections. In Resource Monitor I see only Tor connects to the internet. Bitcoin doesn't connect anywhere.

Please help.

Bitcoin Core works fine with Tor. There is a current setup guide in this question. The only thing that you may need to adjust is if your current Windows setup uses port 9150
(instead of port 9050) for the Tor Socks5 proxy.


Electrum 2.0: non-BIP39/32 standardisation complicates matters immensely. Why? Electrum 2.0 has been causing me some frustration, insofar as it seems to be a non-standard implementation of BIP32/BIP39 (HD wallets, mnemonic seed, respectively). The wallet in question is a 2of2 multisig wallet (all P2SH), with the 2nd extended public key being created in pybitcointools using

bip32_privtopub( bip32_master_key( sha256("a password") ) ),

then imported into Electrum.

Given the 13 word seed, which itself is non standard since the last word is a checksum, it's proven impossible to export the xpriv key from Electrum.

How is a mnemonic seed converted to a BIP32 standard extended private key (given the client itself won't allow it)? : EDIT1: with great difficulty, see my answer below

(REFOCUSED) QUESTION: *why does Electrum:

stray from BIP0039?
make exporting the master BIP32 private key impossible?
return partially signed P2SH hex Txs which are malformed?

Thomas Voegtlin , the developer of Electrum explains the reasoning in the first 10 minutes of this interview. I think he also posted same thing to Bitcoin dev mailing list some time ago.

https://letstalkbitcoin.com/blog/post/epicenter-bitcoin-69-thomas-voegtlin-electrum-spv-wallets-and-bitcoin-aliases

His main point against BIP39 is that it doesn't include a version number, and the requirement of the word list dictionary in order to implement it.


Trying to claim my bitcoin cash but transaction history doesn't match Upon discovering the meteoric rise in value for Bitcoin Cash, I decided to actually claim the little Bitcoin Cash that I had from after the August 1st 2017 fork.  I had sold most of my crypto holdings awhile ago but retained about 17 mBTC.  My last valid transaction was a Send of 0.4 BTC to my Coinbase on July 15th which was prefork and left me with the remaining 17 mBTC balance.

I am using Bitcoin Core on a Windows 7 machine with a password protected wallet that is kept in a KeePass database that is protected with a private key I keep on a USB thumb drive. I decided to install Electron Cash and the install asked if I wanted to import private keys from a Bitcoin wallet.  I decided to do this and got the private keys from the Debug Console in Bitcoin Core for all of my receiving addresses.

I can see the correct amount of transactions in the History tab in Electron Cash after importing my private keys, however the amounts are wrong and the dates seem slightly off.  What is most concerning is that the final transaction shows my balance being sent out but the transaction id on Blockchair doesn't seem to match up with what I am seeing in my wallet.  Electron Cash wallet shows my balance as 0 which is incorrect.

BTW, I verified the ElectronCash 3.0 executable against the sig and checksum and my download is legit.

I am incredibly confused and wondering if I did something wrong on the import or if my money was pilfered.  Could this be a bug in ElectronCash 3.0?  Should I try a different wallet?

I figured out what was going on... sort of. At the very least I found where my Bitcoin Cash was and was able to sweep it into another wallet.

It is probably that I fundamentally misunderstood how Bitcoin Core works. I started investigating all of my Send transactions and Receive transactions on Blockchair and found that when I was sending a payment to another address, it would grab the funds from a receive address that had sufficient funds to cover the payment. I naively assumed that the remaining balance in my receive address would stay there, however I discovered that what Bitcoin Core was doing was liquidating the remaining balance from the receive address and sending it to a new address that was also in my wallet.

When I would do tge export of Receive Addresses from Bitcoin Core it would only list addresses that I received funds to, not addresses that still contained unspent Bitcoin. This was why Electron Cash and other BCH wallets showed a zero balance when I brought in the private keys for those addresses. Sure enough when i dumped the private keys for these hidden addresses listed in Blockchair, I was finally able to get the unspent balance and sweep the funds.


How can I convert a bitcoin private key (hex) into a Bitcoin public key? How can I take a bitcoin private key encoded in hex:

d1d9a2e9fd3da7e7710310ea17a9edff9e08845c7a6f2ea3d650ba4ae7ee0d3b

and convert it to the corresponding public key:

0478a2a9be183f26e2745c9254957e3b714e8bf161f8bf992f9c628fbddc634e149f52aab6a45cd93187593e2413baf14378e7b2c14c0429f98cbe90c723e1e179

I am NOT looking for a program/tool that does this, but how to do this mathematically. If you can't find that out, you can also give a solution in python 3, which I can understand and convert to something mathematical

I'm voting to close since this is very similar to the other question, but what you want to be doing is scalar multiplication of the private key to the generator point using Elliptical Curve Cryptography. The curve parameters, including the generator point is defined in SECP256K1. The resulting x and y coordinates are encoded via SEC uncompressed format to get the public key.


When making an altcoin copy of Bitcoin, where should one start? In attempting to create a clone, a few things have to be considered... things like block time, reward, etc are often changed. What other things should be considered when messing with the source code?

You should study the current alt-coins world:

en.bitcoin.it: List of alternative cryptocurrencies
bitcointalk.org: List of all cryptocoins

The most interesting alt-coins today on my sight are:

Quarkcoin (QRK) blake, bmw, groestl, jh, keccak, skein
Primecoin (XPM) First non-hashcash proof-of-work in cryptocurrency, pure prime number based proof-of-work
Litecoin (LTC) scrypt

The fastest way to understand what must be changed is take a source bitcoin-0.6.3-linux.tar.gz and source of litecoin 60300.

Thereafter, extract both archives into two directories and simply diff -rHvn bitcoin litecoin.

Change the names of configuration files, number of ports, etc... And change the hash function, if you wish.

You surely will meet two common troubles:

Kill network by difficulty. Someone may come to your network with >50% of power, increase the difficulty and then disappear. After that, your network participants would found next block with BIG delay, which will break the stability of transactions, etc...
ASIC miner. Today, any gamer with a TOP video card can't mine, in the top pool, not even ONE Bitcoin for years, because of ASIC miners. What to say about a finding of block, solo-mining.

First can be solved, I think, by reinventing dependence on the difficulty by adding a dependency on Time. For example:

  Next block must be with 10 zeroes in the start, but after one minute the
  number of zeroes would be decreased by one, at the second minute decrease
  this doorstep again, etc...

Second, the ASIC miner, may be conquered by the really hard hash algorithm. Look at the QRK: probably nobody will draw such circuit while the game isn't worth the candles. But here you'll meet next attack: someone may analyze the cascade of hashes and find a much easiest way to getting blocks.

You can observe the world of alt-coins and you will realize that nobody needs your new coin. There are about 30 very active alt-coins and about 100 in incipience. I predict: "In the next year this numbers would be multiplied by 10!": 300 active alt-coins with various difference from bitcoin and 1000 full clones, differing only by labels.

You could blow up the market with super innovation.

One of the most interesting and costly thing is traceability of money, on my sight. E.g. Look at zerocoin.

The second is a dying of mining. The market of bitcoin might plop in.

Edit: Also, there is rippled/xrp, sometimes ago it has become opensource.

https://github.com/ripple/rippled/
https://ripple.com/wiki/Introduction_to_Ripple_for_Bitcoiners

Also, look at granpa of ripple:

https://classic.ripplepay.com/login/

One day, surely, there will appear a child of bitcoin and ripple. Kind of crypto-money-mutant.

I leave here a little space for the future to add more interesting questions and answers.


How to reverse Bitcoin Elliptic curve? Hello Friends is this possible to reverse the elliptical curve if you have value of X and Y of public key?
I know the public is generated through following formula
K=kG or kG=K
Can we reverse it ?

The whole point of Elliptic Curve Cryptography is that it is not possible to do such an operation. If it were, ECC would be broken, along with everything that uses it.
With current technology and algorithms, it is not possible to do what you are asking.


What are the implications of a huge amount of unused hash power? A not unthinkable scenario is that the Bitcoin price decreases to, say, 10-20% of today's value. This would make mining less profitable, and the difficulty should adapt accordingly.

This should lead to a large amount of unused hash power, that could be made available to some majority attacker.

What are the implications of just knowing that someone (although unlikely) could be covertly using this hash power to mine a parallel and longer blockchain before difficulty adjusts, causing all sorts of trouble?

Can this scenario be remedied somehow by altering the protocol?

I grasp your question, mining becomes unprofitable so mining hardware is turned off and the difficulty reduces. Then, an attacker coerces miners to turn on their hardware in a bid to attack the network.

This would be difficult to achieve. First, you would have to identify where the mining hardware that is turned off is, identify who it is that operated it and, make contact with them. Then, you would need to convince them to go along with your attack.

As mining is largely anonymous, at best you could potentially source some of the IP's that miners are connecting through. Nothing says that the IP a miner is connecting through is their IP and even less identifies the mining operator working behind a particular IP, and still convince enough to go along with your attack to make up 51% of the hash power. This attack is infeasible.


How to answer to whether Bitcoin is a Ponzi scheme? I was asked whether Bitcoin is a Ponzi scheme as I was explaining Bitcoin. In support of the question I was presented with the following scenario. I didn't know what to answer.

  Let's assume Bitcoin started today and had no transactions and no customers. Tomorrow, the first 10 people ever buy into Bitcoin. The price at that time for one bitcoin is $100. So, 10 people bought in at $100 thus there is $1000 in the Bitcoin economy.
  The next day, the price of a Bitcoin doubles and goes to $200 per coin. Now again hypothetically, let's say ALL 10 of these people want to sell their Bitcoin and cash out. The math now says $2000 will have to be paid out.

How will this be handled as there was only $1000 in the system? I don't believe Bitcoin is a Ponzi scheme, but this particular equation does not add up. What am I missing here?

The Scenario is confused, because it assumes that there is only one side to a trade.
The scenario assumes that the money goes "into the Bitcoin economy" when people buy bitcoins. This is confusing, because it sounds as if there were only one side to the trade. You will find that the scenario doesn’t imply Bitcoin to be a Ponzi scheme, once you take a closer look at how trades happen.
People own bitcoins:
When Alice pays Bob $100 to buy one bitcoin, Bob is the new owner of the $100 and Alice is the new owner of one bitcoin. The money didn’t "go into the Bitcoin economy" – it went to Bob.
What changed was the Total Dollar Value or Purchasing Power of Bitcoin: People see that someone was willing to pay $100 for one bitcoin.
So, in your scenario that should rather be: There are currently 10 bitcoins in the system, and the spot price is $100. This gives Bitcoin a Total Dollar Value, or Total Purchasing Power of $1000.
There is no problem the next day either: When the spot-price increases to $200 per bitcoin, that means that one person, say Alice, was willing to sell for $200, while another, say Carol, was willing to pay $200 for a bitcoin. Apparently, Carol thought that bitcoin was undervalued at $100 and was willing to go higher with her bid. And who would blame Alice for selling her coin for a 100% markup in one day?
Now as described in your scenario, the other nine owners of bitcoins offer their bitcoins as well for $200 each. The question then is, whether there are enough buyers to support the price at $200. This boils down to a balancing of supply and demand: Perhaps, Carol wanted only one bitcoin. Then there will be nine offers to sell a bitcoin each at $200, but no buyers. In order to cash out, the sellers have to find someone that wants to buy though. There is no "bitcoin economy" that stores the value and pays them out when they want to exit their positions.
What's a Ponzi scheme?
In a Ponzi scheme, investors are enticed by promise of fixed returns. The operator manages all funds and uses investments by later investors to pay off earlier investors. As no value is generated, the operator must constantly attract more investors to keep the scheme running.
In contrast, Bitcoin doesn’t pay any returns or dividends, nor is there a central operator that could make any such promises. Each individual manages their own funds. Bitcoin's exchange rate is established by supply and demand. Much like a commodity, its current spot-price is that of the last trade between individuals.

Related reading:

Is Bitcoin a scam? further elaborates on the differences between various fraud schemes, high-risk investments, commodities, and currencies.
How do buy and sell orders work? explores how Bitcoin's exchange rate is established.
What happens to cash used to buy bitcoins? looks at the role of Bitcoin exchanges in people's buying and selling of Bitcoin.


Where to find the data to compare the decentralisation of mining for different cryptos? I'd like to compare the centralisation of BTC's mining / nodes / pools for BTC and other alts. Where can data be found on this?

Thank you!

David

Here is data on bitcoin mining distribution and ethereum mining distribution


Why is SHA3 less conducive to ASIC? Bitcoins are encrypted with SHA-256, and Ethereum is encrypted with SHA3.  Why can miners for SHA-256 encryption guess hashes in the TH/s when miners for the SHA3 encryption can only hash in the MH/s?  Is the algorithm more complex?

I'm not an expert but I'm a good at digging through academic literature, and this is what I found about SHA3 with relevance to FPGAs and ASICS (and in comparison with SHA2).

Note that this paper dates back from 2011, the winner of SHA3 was not yet decided as NIST only released the SHA3 standard in 2015. Take a look at the Keccak result in this paper. The ASIC space, atleast ASICs with the specific purpose of hashing, have evolved a lot the past 6 years and the numbers are probably not up to date.

  These  graphs (and  the  corresponding  tables) have revealed that Keccak is the only candidate that consistently outperforms SHA-2 for all considered FPGA families and two hash function variants (with 256-bit and 512-bit output).

Another paper, which is also pretty old and dates back to 2010 has indications that Keccak (SHA3) is faster than SHA-256.

  Figure 5 illustrates how architecture differences affect the performance results. Some curves, like those of Keccak and Luffa, are very steep. This means that a small increase in area yields a significant performance improvement.

Also, I'm not aware of any ASICs for Ethereum, they are currently being mined using GPU's. As you probably already know: GPU's are magnitudes slower than ASICs thus being in MH/s range is no surprise.


Problems about update of protocol of bitcoin I am new to crypto. I want to ask if in the future, bitcoin has a significant protocol update, will there be a recycle (or some kinds of buy-back or repurchase?) of old tokens or an automatic update of the old tokens (perhaps done alongside with wallet software update, just guessing)? What if I hold bitcoin long enough, will the market price of the bitcoin using old token standard drop to zero since the technology become outdated?
I know some crypto projects are built on bitcoin. So how exactly do these crypto project keep up with the updated protocol while maintaining the market price, and how do the bitcoin community and developers deal with these problems?

The general approach to Bitcoin protocol updates is to maintain forward and backward compatibility with the prior consensus rule set on the network.
In fact, Bitcoin's protocol stability is considered one of its most important properties, as it ensures that people can confidently store value and rest assured that their funds will remain accessible in the future. Changes to the system that would pull the rug under prior investors would meet extreme resistance.
Obviously, every user has to decide for themselves whether the perceived social contract is stable enough to inspire confidence.


How to ./configure a built for Raspberry Pi? I want to use this guide to set up a headless bitcoin core full node and came across the line:

./configure CPPFLAGS="-I/usr/local/BerkeleyDB.4.8/include -O2" LDFLAGS="-L/usr/local/BerkeleyDB.4.8/lib" --disable-wallet

Unfortunately, the blog does not explain why he uses this.

First of all, I want to use my node with wallet. Second, I want to configure it to be usefull with a Raspberry Pi which has only 1GB of RAM and is also running other stuff, for example my Logitech Media Server for audio streaming. So I would like to make the node as lean as possible.

I know that I can use a config file for running  bitcoind with entries for upload limit and other setups. Do I need to run the skript also with options or are both setups interchangeably?

Also, I get the error Found Berkeley DB other than 4.8 upon configure. Can Ihave a wallet with the BDB other than 4.8? The error message suggests, that 4.8 is needed for "portable wallets".

Here I found out about dependencies for the wallet and also about the option to built without GUI. Unfortunately, I cannot successfully ./configure with those neither, because BDB 4.8 is also not found this way.

However, to do it without GUI the option --without-guican be used, which is very usefull.

EDIT: I encountered another problem while make:

/usr/bin/ld: cannot find -ldb_cxx-4.8
collect2: error: ld returned 1 exit status
Makefile:4779: die Regel für Ziel „bitcoind“ scheiterte
make[2]: *** [bitcoind] Fehler 1
make[2]: Verzeichnis „/home/pi/Downloads/bin/bitcoin/src“ wird verlassen
Makefile:12975: die Regel für Ziel „all-recursive“ scheiterte
make[1]: *** [all-recursive] Fehler 1
make[1]: Verzeichnis „/home/pi/Downloads/bin/bitcoin/src“ wird verlassen
Makefile:776: die Regel für Ziel „all-recursive“ scheiterte
make: *** [all-recursive] Fehler 1
19:07:10 [pi@raspberrypi bitcoin]$ /usr/bin/ld: cannot find -ldb_cxx-4.8
-bash: /usr/bin/ld:: Datei oder Verzeichnis nicht gefunden

Here I found an answer to a related error and I used ld -ldb_cxx-4.8 --verbose and got this:

attempt to open //usr/local/lib/arm-linux-gnueabihf/libdb_cxx-4.8.so failed
attempt to open //usr/local/lib/arm-linux-gnueabihf/libdb_cxx-4.8.a failed
attempt to open //lib/arm-linux-gnueabihf/libdb_cxx-4.8.so failed
attempt to open //lib/arm-linux-gnueabihf/libdb_cxx-4.8.a failed
attempt to open //usr/lib/arm-linux-gnueabihf/libdb_cxx-4.8.so failed
attempt to open //usr/lib/arm-linux-gnueabihf/libdb_cxx-4.8.a failed
attempt to open //usr/local/lib/libdb_cxx-4.8.so failed
attempt to open //usr/local/lib/libdb_cxx-4.8.a failed
attempt to open //lib/libdb_cxx-4.8.so failed
attempt to open //lib/libdb_cxx-4.8.a failed
attempt to open //usr/lib/libdb_cxx-4.8.so failed
attempt to open //usr/lib/libdb_cxx-4.8.a failed
attempt to open //usr/arm-linux-gnueabihf/lib/libdb_cxx-4.8.so failed
attempt to open //usr/arm-linux-gnueabihf/lib/libdb_cxx-4.8.a failed
ld: cannot find -ldb_cxx-4.8

Now trying with sudo apt-get install gcc-4.8 g++-4.8. That did not help.

Maybe I have to try this guide: https://medium.com/@meeDamian/bitcoin-full-node-on-rbp3-revised-88bb7c8ef1d1

You can follow the instructions for Debian at the build docs:

https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md

For Berkely DB, specifically:

Berkeley DB

It is recommended to use Berkeley DB 4.8. If you have to build it yourself,

you can use the installation script included in contrib/

like so:

./contrib/install_db4.sh `pwd`

from the root of the repository.

Note: You only need Berkeley DB if the wallet is enabled (see Disable-wallet mode).