How to calculate the Average velocity and the Average acceleration of Bitcoin transactions I am working on a Bitcoin project and I would like to extract the following features

1- Average velocity: represents the speed with which bitcoins flow to a user

2- Average acceleration: represents the acceleration of bitcoin flow to a user

I have the following attributes:

user ID ( represents the user)
the total number of transaction (e.g 100 transactions)
the total value of Bitcoin transferred (e.g 10000 BTC)
the date of each transaction (represents the date of each
transaction)

Can you please help me how to calculate the velocity and acceleration?

Thank you for any help you can provide

Regards,

Khaled

You can calculate an average velocity/flow of bitcoin to an address/user by summing all bitcoin received that address/user in a given time period and dividing it by the time period. I think your issue is that you don't have the time each transaction was made. The easiest way to get a rough time (+/- 2 hours) a transaction was made is to look at the timestamp field in the header of the block that transaction was included. So, for example, with if you have the transaction 58513acbb340fd24d2b27d8680961196f0363b79f90ee34a974d6593bf64559b, you can get the time of this transaction in bitcoin core by running this command:

>bitcoin-cli getrawtransaction 58513acbb340fd24d2b27d8680961196f0363b79f90ee34a974d6593bf64559b true | jq ".blocktime"
1576581288

This timestamp is the UNIX epoch timestamp that the miner chose for the block. Bear in mind that miners can choose a timestamp that is off by about up to 2 hours and the block would still be valid, so don't take this the last two/three digits of this timestamp very seriously - this value is mainly used to calculate difficulty adjustments in bitcoin which occurs only about every two weeks. Another way to assign a time to a transaction would be to know when that transaction entered the mempool but that information can be extremely hard or impossible to get a posteriori and can have less practical meaning than the block timestamp.

With an approximate instant when each transaction was made, you can group all transactions done in a day or week, for example, and divide the total bitcoin amount by the time period. To calculate the acceleration takes two consecutive velocities and divide them by the time period again.

Be careful not to confuse the velocity of money, which is an economic concept, with the velocity that you are trying to calculate which is specific to your data set.


Is there a way to monitor what bitcoin-qt is doing on a mac os x? Using 0.6.6.2 on a mac mini; has been running for 56 hours now, still not fully synchronised; is there a way to monitor whether the program is actually doing something or just stuck? would the 0.8.x be faster?

It takes forever and a day to have Bitcoin-Qt sync up with the Blockchain for the first time. Also try executing "netstat -n -P TCP | grep '.8333'" in a terminal window to see if you have eight concurrent socket connections into the Bitcoin network.


How to setup testnet-in-a-box on Mac OSX? I'm trying to setup testnet-in-a-box and I'm a little unclear on how you get the command line version working for mac as described here:

http://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/

I installed macports and ran sudo port install bitcoin so I have a bitcoind executable now.

Instead of

bitcoin -datadir=1 -daemon
bitcoin -datadir=2 -daemon

Do I just use?

bitcoind -datadir=1
bitcoind -datadir=2

Also, since there are two nodes do they have to run on different ports?  Thanks

Yes, run bitcoind instead of bitcoin.

If bitcoind isn't working, but bitcoin-qt is working, then do this instead:

bitcoin-qt -server -datadir=1
bitcoin-qt -server -datadir=2

This will only work if you run the commands from inside the testnet-box folder.  Alternatively specify full path names to the 1 and 2 folders: datadir=/home/chris/testnet-box/1 etc.

You need to download the testnet-box.zip file and extract it.  That will make you the two folders 1 and 2.  Both folders have testnet blockchain files, a wallet, and a bitcoin.conf.

Folder 1's bitcoin.conf says:

rpcpassword=123   # Set this yourself.
noirc=1
testnet=1

so it will run a testnet instance, not connect to IRC, and set the password to '123' for RPC connections.

Folder 2's bitcoin.conf says:

rpcpassword=123   # Set this yourself.
noirc=1
testnet=1
rpcport=19332
nolisten=1
connect=127.0.0.1:18333

which is the same as the other except that it listens for RPC connections on a different port, doesn't listen for incoming P2P connections at all, and only connects to the other instance.

There shouldn't be a port conflict.  The first will be listening on port 8332 for RPC connections and port 18333 for P2P connections.  The second will be listening on port 19332 for RPC connections, and not listening for P2P connections at all.

Note: if you're running the 0.6.0 release candidate, the nolisten=1 in node 2's bitcoin.conf won't work.  You'll need to change it to listen=0 due to a bug I found and reported while researching this answer.


Sending Bitcoin from my wallet to a different bitcoin address When I want to send bitcoin from my wallet to another bitcoin address in blockchain.info, I must to have a private key. How I can obtain a private key?

When completing a transaction via bitcoin, you never need the target's private key.  Never give your private key to anyone.  NEVER.  The private key is the only secret you have that protects your bitcoin.  If you give your private key to someone else, they can "spend" your bitcoin.

When sending money to someone, you simply need an "address"; the recipient should provide you with that address.  If you are attempting to send money from one BlockChain.info wallet to another waller on BlockChain.info, you can get the target address by clicking on the "Request" link inside your wallet.

See this BlockChain.info support page for details.


bitcoins can use different algorithm, how and implications I read that if sha-256 was compromised at some point in the future, or for any other reason, bitcoin could switch to a different algorithm

can someone detail how exactly that would work, and what the implications to existing blocks would be?

from my understanding, everything is hashed with sha-256, then another algorithm would be incompatible with all previous blocks....

can someone elaborate on this?

if bitcoin, or any cryptocurrency, switched algorithms, what would happen to people's current addresses and the ledger of transactions? In theory it should be very simple for major pools to switch to the new client, as has been done numerous times in cryptocurrency land, but I've never seen it done with a different algorithm.

The only way to do this would be to announce a new version of the protocol well in advance. It would need to co-exist in the same blockchain with the existing keys and transactions and be adopted over time.

First, the client software with support for the new scheme needs to see widespread adoption before anyone can use the new algorithm
Once that has happened, early adopters (probably mining pools) can start creating keys in the new format and the blockchain will accept them.
If that worked well, the standard client will default to making new keys
Some more time down the road, everyone can agree that transactions can only be done to new keys, forcing the "old money" out of the system eventually

  Bitcoin could in theory switch to use the SCrypt Litecoin algorithm. (hence there is no reason for Litecoin to exist)

I don't think that would be a good move. If people decided that the Litecoin algorithm is better, they can just use Litecoin. Bitcoin should stick with its algorithm, but make adjustments to parameters such as key length when those become necessary.

Choice of algorithm should be choice of blockchain (Bitcoin vs Litecoin) and can be left to the "market" to decide.


What is a double spend? What is a double spend?

As someone who uses Bitcoin, what do I need to know about how the Bitcoin system prevents double spends? Are there still circumstances where they can occur?

A double spend is an attack where the given set of coins is spent in more than one transaction. There are a couple main ways to perform a double spend:

Send two conflicting transactions in rapid succession into the Bitcoin network. This is called a race attack.
Pre-mine one transaction into a block and spend the same coins before releasing the block to invalidate that transaction. This is called a Finney attack.
Own 51+% of the total computing power of the Bitcoin network to reverse any transaction you feel like, as well as have total control of which transactions appear in blocks. This is called a 51% attack.

To prevent damages from the first attack - wait for one confirmation to appear on a given transaction. To prevent damage from the second attack - wait for 6 confirmations to appear on a transaction, or less if the transaction is small (but still require at least 1). Damage from the third attack can cripple the entire Bitcoin network, so don't worry about it - your business most likely won't be the main target (it's unlikely to happen without really big money getting involved).

For more information about all those attacks, you can check out my master thesis on Bitcoin security.


Bitcoin Transaction using API with Custom Fees I want to transfer Bitcoin from one individual address to another using API. But I want to set Transaction fees as per my requirement. So How can I do it ?

Right now I am using blockchain-transaction - npm api for transfer bitcoin from one address to another. So please shade some lights on this.

var bitcoinTransaction = require('bitcoin-transaction');
//Send all my money from wallet1 to wallet2 on the bitcoin testnet
var from = "mm3gdVh8n6YtcNyaTKYkveB6yTME7aDWNJ";
var to = "mgPUfqJk4X6gE4P5Do5RfpkTFsYmsSjCya";
var privKeyWIF = "cNZi8iySqBToXMpcsQaHKD5uv7HExBQJBSi4dTg3ZPaEzeNAzvbj";    //Private key in WIF form (Can generate this from bitcoinlib-js)
bitcoinTransaction.getBalance(from, { network: "testnet" }).then((balanceInBTC) => {
    return bitcoinTransaction.sendTransaction({
from: from,
to: to,
privKeyWIF: privKeyWIF,
btc: balanceInBTC,
network: "testnet"
});
});

I have not tried this myself but having a look through the documentation on blockchain-transaction - npm api it looks like you can query fees, under the advanced section:

  fees - Gets a list of current fees based on the BitCoin network going
  rate.

https://www.npmjs.com/package/bitcoin-transaction

Looks like you can select a 'fastest' option or others:

  Set the fee for the transaction. Can be either one of "fastest",
  "halfHour" or "hour" in which case the actual fee numbers are fetched
  from the fees provider. Or it can be just a plain number in which case
  that will be used as the Fee per Byte value in Satoshis. It is
  recommended to use one of the string aliases unless you know what you
  are doing.

You might have to specify a feesProvider, not sure if they have a default selected when nothing set.


Why to mine with a high difficult on PPLNS I'm trying poolmining ob btc-guild with the cgminer and try to calculate by testing if it is worth it or not.

One thing I wondered is: Why should I want to set a high difficult / not the lowest one, when mining?

If I am paid for the last N shared within a shift, I would want to contribute as many shares as possible. The lower the difficulty is the higher is the amount of shares, isn't it?

With about 170MH/s I have about 90 shares per hour.

The server will reject all shares that are below the difficulty it specified in your getwork request.

Reasons for the server to lower the difficulty of accepted shares:

Less variance for users

Reasons for the server to raise the difficulty of accepted shares:

Lowers bandwidth usage

Something from 4 to 10000 is about right.


cancel transaction in MultiBit Classic I'm trying to send some BTC - I have two send transactions stuck in MultiBit Classic (0.5.19). They have been stuck for a few weeks.

Both transactions have fee of 0.0001 BTC fee which is most likely why they are stuck.

I tried 'resetting the blockchain' several times in the last couple of days, and I tried increasing the fee to 0.0005 BTC between resets, all to no avail. The transactions still show up as having a 0.0001 BTC fee.

What can I do get these transactions processed (or cancelled)?

The documentation for MultiBit HD, the new version of Multibit, states that the best way to upgrade from MultiBit Classic is to create a new wallet and transfer the balance but how can I do this if the bitcoin is stuck in the transaction?

If I was to export the private keys to another wallet service, say  blockchain.info, what would happen to the BTC in the stuck transactions?

Control over money in Bitcoin is defacto[1] binary: either a transaction has been confirmed in a block and the money has been signed over, or the sender remains in control of the money. Hence, when you export the keys from MultiBit and import them to another wallet, you will be able to overwrite your previous transaction by issuing another transaction transferring the money somewhere else (unless the new platform is aware of your previous transaction and forbids doublespends).

[1]The only exception to this is the option of the recipient to create a child-pays-for-parent transaction which provides a sufficient aditional transaction fees to compensate the low fee of its parent. Still the money is only signed over once the transaction is in confirmed in a block though.


What is the structure of blk001.dat and blkindex.dat? Can anyone tell me where I can read about the structure of the files

 blk0001.dat
 blk0002.dat
 blkindex.dat

I know that in these files bitcoin is saving all the information about transactions.
I would like to parse the files and save the information from these files in my local database.

[Note-these files are no longer used for Bitcoin-Qt/bitcoind version 0.8 and above.]

While reading the blockchain data directly is possible, you can only do so against stale data files -- as you can't reliably read the files while the client is running.

PyWallet and BitcoinTools are two such methods to do this.

Instead, the Bitcoin.org client (v0.7 and above) provides Raw Transactions support, in which you can decode a transaction to learn of its inputs, outputs and other attributes.  This, along with the rest of the API provides the ability to pull all the data from the blockchain that is needed, against a live instance:

http://en.bitcoin.it/wiki/Raw_Transactions
http://en.bitcoin.it/wiki/Raw_Transactions#decoderawtransaction_.3Chex_string.3E


How does blockchain.info's mixing service work? Blockchain provides a mixing service.

How does it work?

Their shared sending feature simply combines payments from multiple users making it very difficult to know which funding inputs (Bitcoin addresses) were used to pay which outputs (Addresses being paid).

Think of it like collecting money at the office to pay for a coffee run.   Five people are buying coffee, each costing $3.

Bob puts in a $5, for a latte
Alice puts in $3, for an espresso
Carolyn puts in $10 for a cappucino

A driver goes to the coffee shop, the bill totals $9, so the $10 bill is handed over and given out is a cappucino, an espresso and a latte.  A $1 of change is given back to the driver.

Back at the office the driver gives bob the $1 from the coffee shop plus a $1 that was received from Alice.  The driver gives Caroylyn the $5 that came from Bob and two $1s that came from Alice.  Each person gets their coffee.

That's actually a very weak example but it shows a real world example of how shared spending "mixes".  It might look like Bob didn't buy coffee from the store, but instead it looks like he bought it from Carolyn. And it looks like Alice bought from both Bob and Carolyn.  But none of that is how it actually occurred because the funds were combined prior to making the purchase.

Some of the coins mixed in are those arriving for on-time use address in which the Blockchain wallet user has clicked the "New Shared Address" option under Receive money.  The amounts received will incur a fee.


What made the old versions of the bitcoin wallet insecure? According to the downloads for the Bitcoin client, versions older than ~0.3.0 were "insecure".  Since they are not available for download (and the lack of security is the given reason) no one can learn from them or verify the reason.

The question I have is, 1, does anyone have a copy of the original wallets and or their source code for download and, 2, does anyone know what made them insecure?

The source code for old versions is available in the Bitcoin-Qt Git repository. Click on the "branch: master" button and then select "Tags", and you can go all the way back to v0.1.5.


Trying to open an old wallet.dat (from ~2013) I found my old wallet.dat file taken from the bitcoin core wallet I used when mining around 2013, nothing serious tho, just fiddling around. Never been too much into the subject, and now I'm totally out of the loop.

Will explain what I did so far:

I downloaded the latest bitcoin core, opened it and after a few seconds closed it properly, replaced the default wallet.dat file (with a size of 1416kb) with a copy of my old one (only 88kb) and opened the program again to let it download blockchain, then noticed that as soon as the program opened, the wallet.dat (my old one) file size changed to 688kb, waited for the  whole blockchain to download and noticed the balance it's still 0, the send/receive/transactions screens are also blank, as a vanilla wallet.

Maybe my old wallet file is somewhat an old format and get's erased and treated like a new one?

I put back the default wallet created by the program and from inside the program opened my old wallet file, a small window with a progress bar appeared saying "opening wallet filename", but it keeps loading forever. Also the file size changed again from 88kb to 688kb.

Any clue of what is happening?

I wan't to transfer whatever is there to some online wallet like coinbase.

You could try checking balance from blockchain, just click on receive and copy the address and search in blockchain.com, youll see you'll how much you got there.


Find the midstate of an already mined block I am playing around with a bitcoin miner and wanted to run some tests. Hence I wanted to find the nonce of an already mined block. Lets take  http://blockchain.info/block-index/353394/0000000000000083ee9371ddff055eed7f02348e4eda36c741a2fc62c85bc5cf as an example. I can find the nonce. I can calculate the block header. But how do I find out what the target was as well as what the midstate and data was when the getwork was called for that particular block at the time of mining?

A useful link on the subject.

Target is computed from a value called "Bits". A Bits value of 0x1b0404cb is equivalent to Target of 0x0404cb * 2^(8*(0x1b - 3)) = 0x00000000000404CB000000000000000000000000000000000000000000000000 . A Pool usually specifies the Target to be just shy of Difficulty 1 Target (a typical Target for a Share), which is equal to 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF .
Calculating a midstate is a big pain. Basically, you need to get an internal state of the SHA-256 function that will be used in calculating the block hash. Also, you have to be mindful that Bitcoin's endianness is all over the board and you have to be swapping bytes around for no apparent reason every now and then.
Data is just a padded block header.

Hopefully with this general explanation and links to examples of the calculations you will be able to compute all the required data as needed.


Does Blockstream have a revenue model that can only exist in a small block environment? Anyone reading discussions in the Bitcoin scene these days probably has seen the following argument (or similar):

  "Blockstream is preventing a blocksize increase because their products can only turn profit in a small block environment."

What evidence is there to support or refute this statement?

PSA (as per our rules):

Be open-minded. This question will likely generate diverse answers that may not align with your personal opinion.
When answering this question, back up all statements you make with appropriate references and evidence.
Answers will be edited/moderated for tone. Stay respectful and courteous.
Avoid statements solely based on your opinion.
Logical fallacies will be called out.

As far as I know, they don't have an explicit business model published anywhere. We do know that they are working on:

Side chains - a two-way peg that has fixed transfers of value from bitcoin to a sidechain and back.
Lightning network - a network of transactions that can be updated relatively quickly (seconds, theoretically) and provably given if the transaction is published on the blockchain.

Both these things are innovations, but how they will make a profit off them is not clear. That said, both these innovations potentially could be more useful if transactions on bitcoin proper were more costly. For both, that would be because transactions on a side chain or lightning network can be potentially cheaper and thus more utilized. That is in theory. Neither of these things are public or even built. Most of the accusation is in theory. Only the Blockstream people know the business model and given that they're a startup with no profits, I wouldn't be surprised if they pivot a few times before they actually find a business model that works for them. This may or may not involve profiting from the innovations above.

Essentially, there is no clear revenue model so the statement about blockstream is mostly speculative.


error : incorrect rpcuser or rpcpassword (authorization failed) I started bitcoind -datadir=/mnt/btc but everytime I try to use bitcoin-cli it says :

  error : incorrect rpcuser or rpcpassword (authorization failed)

I can't find bitcoin.conf (neither in the default datadir ~/.bitcoin neither in /mnt/btc).

Any idea how I can generate one and if it will help the original problem ?

I was having the same problem and just managed to fix it now.
Since the file bitcoin.conf does not exist inside ~/.bitcoin, Just create one.

Here's what did:

 vi ~/.bitcoin/bitcoin.conf

Enter letter 'a' (to edit the file). Then type:

 rpcpassword=any_long_random_password

Press the ESC key, and press ZZ to exit vi

Apparently the password that bitcoind started with is (for one reason or the other) different from the one you are trying. (i also have a feeling that bitcoind misbehaves like that because no password was defined; since there was no bitcoin.conf)

Now, even though you have changed the password, it will NOT be effective until bitcoind has been re-started. But since it won't even accept the stop command (./bitcoin-cli stop) due to the authentication issue;
You will need to kill the process, and restart bitcoind. It will work fine afterwards:

pkill -9 -f bitcoind

then

./bitcoind -daemon

Hope this is helpful


Do Berkley DB versions need to be the same? If I build using --with-incompatible-bdb, will the resulting wallet be incompatible with the bitcoin core client from bitcoin.org? What if I'm using a newer version?

To be safe, you should use BDB 4.8 as that is the version that is used in releases. However using --with-incompatible-bdb should still produce wallet.dat files that can be used with the officially built clients.

You may find that people say that the BDB database files are incompatible from version to version. Furthermore Oracle, in their own documentation, say that there are no guarantees that database or environment files are compatible from version to version, even from minor version to minor version. But from researching and testing this out myself, this is not true in practice.

BDB rarely changes the database file format. Rather what does tend to change are the database transaction logs. These log files are used to ensure Durability (the D in ACID). Oracle has changed the log file format in minor versions so they are not backwards compatible (they are forwards compatible, so you can always move to a newer version of BDB). When you use --with-incompatible-bdb, you will probably be using a newer version of BDB that has incompatible transaction logs. So this would be a problem.

But Bitcoin Core actually mostly takes care of that problem for you. The transaction logs are removed if the wallet is able to be closed cleanly. So if nothing crashes and the wallet file is closed normally, you will be able to use a version of Bitcoin Core compiled with a different BDB, and then have the official release be able to use the same datadir and open the same wallet files.

In the event that Core crashes or the wallet files are otherwise uncleanly closed (e.g. power loss), then you should use a build of Bitcoin Core using the same BDB version that you had been using prior to the unclean shutdown. This will ensure that the transaction log can be read correctly and any information replayed and written to the wallet.dat file.

So what versions are compatible? From my own testing, I have found the following versions to work with no modification to Core necessary (Note these versions are what Oracle has available for download, versions with the same major and minor number of different patch number should still work):

4.8.30 (Note this is the version that Core ships with)
5.0.32
5.1.29
5.2.42
5.3.29

6.0 and above are not backwards compatible as they database file format has changed for these versions. You would be able to use 6.0+ but any wallet.dat files created by them cannot be used in the official binaries. However existing wallets created with the official binaries or one of the above versions of BDB could be used with a build that uses 6.0+ and be subsequently used again in the builds with older BDB versions. I.e. you could go from 4.8 to 6.0 and back to 4.8 with the same wallet.dat file.

4.7.25 also works but requires you to modify configure.ac to be able to build with a version less than 4.8.

4.6.21 requires modifying some code as API calls changed, but the database format still works. 4.5.x and below have significantly more API differences so I wasn't able to test them.


How to get staking balance using RPC commands I enabled staking on my wallet. I want to know the staking rewards I got. Is there any rpc command exist to get staking reward balance?

Thanks

A staking system does not exists in Bitcoin's Proof-of-Work consensus model, that being said you will not find any "staking" related functionality in the RPC API. There have been several proposals for a Proof-of-Stake model where this would exist, but of course these have not yet been adopted or have reached any general agreement among the Bitcoin community.


Why tx informations of a specific transfer in BITCOIN protocol will send to many IP addresses? Recently I send a specific value from a wallet to another wallet and Simultaneously I caputred the related traffics in source and destination.

after that, I found that value and it's related address in different packets which their difference was just in source and destination IP addresses.

Why these information(transferred value and it's output address) where distribute to different addresses and which address is main?

This is gossip protocol. When you are connected to the bitcoin network, you are usually connected to some random nodes. When you want to send transaction, ultimately your goal is for the transaction to appear in a block. The blocks are created by miners who operate few network nodes. Usually you don't even know which nodes belong to such miners. Therefore you just send the transaction to some or all your of the nodes you are connected to. And they do the same thing. Eventually, the transaction propagates to the whole network – meaning to every connected node. And some of those nodes are miners and one of those miners will include it in their new block.


What are some affordable options for running a full node? I would like to start running a full node so I can start building bitcoin/lightning applications, but my laptop doesn't have the storage to do so. Does anyone have any suggestions on how I can affordably run a full node? I was thinking of running it on a remote server, but I'm also not sure of what I should look for in a service.

You can reduce storage requirements by running Bitcoin-core in pruning mode

How can I run bitcoind in pruning mode?


Where is the public key corresponding to my address stored? Some simplified explanations of Bitcoin say, that the Bitcoin address is the public key, and anybody can easily verify that a signed transaction is valid since it was signed with corresponding private key.

But in reality, the address is the hash of another hash of the public key.

So, it's not possible to derive the public key from the address alone.

How do miners obtain my public key, then?
Is the public key included in the transaction I am sending ?

Yes, a transaction includes the public key. So, only when you spend the coins from an address a public key actually becomes public (unless you have shared it with anyone otherwise).

So, as long as you don't reuse addresses, the public key is only known after a transaction, which usually is just a few confirmations away from the address' balance to be 0.


How can I get CGMiner to connect to mining_proxy.exe I'm trying to get my CGMiner to connect to my mining_proxy.exe which I have my network ASICminers running through.

I have tried these (below) in every combination I could think of, local ip, 127.0.0.1, local host, connecting directly to eclipse. you name it and it won't show the hashrate or what is happening in the mining operation.

- cgminer.exe -o  stratum+tcp://127.0.0.1:8332 -u worker -p 123456
- cgminer -o "http://127.0.0.1:8332|http://us.eclipsemc.com:3333" -u worker -p 123456
- cgminer -o http://127.0.0.1:8332 -u worker -p worker

I need CGminer showing my hashrate and have some control over the mining operation.

thanks for the help

you can use like this..

cgminer.exe --userpass usertes.worker1:123 --url stratum+tcp://stratum.bitcoin.cz:3333 --socks-proxy 127.0.0.1:1001

127.0.0.1:1001 is the proxy with port..
modify with ur own proxy


Is the scriptPubKey of a previously unseen transaction in an incoming block checked? If so, where? Today I was reading bitcoind src, and trying to find out where scriptPubKey is executed when a node received new block with transaction, for example transaction from new block may not be exist in mempool.

Find function that execute script:

https://github.com/bitcoin/bitcoin/search?utf8=%E2%9C%93&q=EvalScript

src/script/interpreter.cpp   in this file source code of EvalScript function

Used only in this 2 files:

src/policy/policy.cpp
src/script/sign.cpp

Review sign.cpp

Evalscript -> CombineSignatures -> /src/bitcoin-tx.cpp: MutateTxSign -> MutateTx -> CommandLineRawTx -> main

This functions used when we create new transactions
Review   policy.cpp

Evalscript -> AreInputsStandard -> /src/main.cpp: AcceptToMemoryPool

AcceptToMemoryPool

src/main.cpp   later
src/wallet/wallet.cpp   -> CommitTransaction    -  this is create own transaction functional
src/rpcrawtransaction.cpp -> sendrawtrnsaction - rpc function send rawtx
src/txmempool.cpp  -> no calls only comments

Last one is  src/main.cpp

AcceptToMemoryPool -> ProcessMessage  on message  "tx" , new single tx to pool received
  AcceptToMemoryPool -> DisconnectTip

DisconnectTip -> InvalidateBlock    invaludate block and send all transaction back to pool with all verifications and script eval

DisconnectTip -> ActivateBestChainStep :

  // Disconnect active blocks which are no longer in the best chain.
bool fBlocksDisconnected = false;
while (chainActive.Tip() && chainActive.Tip() != pindexFork) {
    if (!DisconnectTip(state))
        return false;
    fBlocksDisconnected = true;
}

If we have orphan take out transactions from orphan to pool with all verifications

NO more other links found

From this I can conclude that in case node with bitcoind received new block
with transactions that not in mempool we add this tx to blockchain without scriptPubKey executing.

Consequently if same "honest" miner include tx with invalid script, at example incorrect signature that spent same one coins, all bitcoind nodes add it to blockchain without eval script and not detect this

It is not possible to be true!  Where is my error?

The behaviour of the mempool or orphan tx pool should not influence the validity of blocks at all.

When a block comes in:

main.cpp:ProcessMessage deals with processing messages, and dispatches to:
main.cpp:ProcessNewBlock deals with specifically processing block messages, which stores it on disk using AcceptBlock and then calls:
main.cpp:ActivateBestChain tries to verify the potentially new best chain and switch to it. For every atomic "reorganization" step, it calls:
main.cpp:ActivatebestChainStep which will try to verify new blocks to be added to the tip of the chain using:
main.cpp:ConnectTip which does the actual processing using:
main.cpp:ConnectBlock, which will iterate through the block's transactions and verify their inputs using:
main.cpp:CheckInputs which builds up a list of CScriptCheck objects for each script execution to be performed, which are verified from another thread. ConnectBlock waits for these threads to finish and deal with the result. In those threads, we call:
main.cpp:CScriptCheck::operator() which performs a single encapsulated script execution, using:
script/interpreter.cpp:VerifyScript to do a verification of script, which consists of executing a scriptPubKey + its spending scriptSig using:
script/interpreter.cpp:EvalScript.

So, EvalScript() should be executed for all scriptPubKeys which are spent by a block, before that blocks ends up being accepted as a tip.


regtest method not found I have alredy looked at a lot of other similar questions here but they didn't involve my case or the solutions provided did not work for me. I'm trying to work in regtest mode and I'm using bitcoin core v0.15.0 on a Debian machine. My bitcoin.conf file looks like this:

$HOME/.bitcoin/bitcoin.conf ->
rpcuser=bitcoinrpc
rpcpassword=7bljxv........zabyi

I run the command

bitcoind -regtest -daemon

And then

bitcoin-cli -regtest getblockchaininfo

And it works fine, but if I try to run the following command:

bitcoin-cli -regtest generate 101

I get the following error:

error code: -32601
error message:
Method not found

Do you have wallet enabled? generate is a wallet RPC now since it needs to get an address from the wallet. If wallets are disabled, then generate will not work. If you want to mine without wallets being enabled, use generatetoaddress.


Is there a service like localbitcoins.com for Litecoin? At the moment, I use localbitcoins.com to find people to buy bitcoins from who have bank accounts so I don't have to fund an online wallet before I can buy.  In order to sell bitcoins, yes the online wallet needs to be funded with bitcoins and that is fine.

Does such a service exist for litecoins too?  So I can find people in my chosen country to buy from, so I can transfer money to their bank account without having to find an online wallet first with money.  I would understand that if I wanted to sell litecoins, the online wallet would need litecoin funds available first.

https://www.litecoinlocal.net/ is the site you are looking for


Is Bitcoin's Economic Majority those who already own coins or those who will buy or keep coins? The Economic Majority theory says that the power to control the Bitcoin protocol is held by those who [own] bitcoins.

But the article then goes on to read:

  The ability for a protocol change to be successfully implemented
  ultimately rests with those who accept bitcoins in exchange for value.

So that refers to investors and those who accept bitcoins for income or revenue but then aren't immediately spending or cashing out the coins they received.

But that power doesn't lie with those who already hold the coins but instead it lies with those who are willing to accept the newly issued coins under the revised protocol or coins with taint from coins issued under a revised protocol.

So, is the Economic Majority those that already hold bitcoins or is it instead just those who will hold the bitcoins generated following a change to the protocol?  If so, how would that be best worded?

Each entity's weight in the economic majority is closely related to its ability to devalue the coins in the protocol version they are against.

People (and their proxies) who are willing to offer goods or services (including traditional currencies) for Bitcoin can refuse to accept coins of the "wrong" protocol, while people who hold bitcoins can sell coins of the wrong protocol.

A detailed analysis might reveal the impact each of these groups has, though I suspect the former group has an advantage.

(Personal note: It's been said that I coined the term "economic majority" in this context. When I originally used it I meant the former group.)


binascii.Error: Odd-length string for Python Implementation of Bitcoin https://gist.github.com/vivosmith/f0e692d9aedbc39ec8d3eb4651bc107c

I was trying to implement this video in Python 3

But the issue is that, it was implemented in Python 2

So I tried to implement this with binascii instead of encode/decode. However I keep getting a binascii.Error: Odd-length string at line 22.

How to I correct this? Or if this is completely broken, then is there any other libraries that work better for python 3?

This is working for me:

import os
import ecdsa
import binascii
import hashlib

private_key = os.urandom(32)
PK_EN = binascii.hexlify(private_key)
print("Your Key" + "  " + str(PK_EN))
PK_CON = binascii.unhexlify(PK_EN)
sk = ecdsa.SigningKey.from_string(PK_CON, curve=ecdsa.SECP256k1)
vk = sk.verifying_key
msg = binascii.hexlify(b'Hello')
sign_msg = sk.sign(msg)
assert vk.verify(sign_msg, msg)

public_key = b'04' + binascii.hexlify(vk.to_string())
print(public_key)

ripemd160 = hashlib.new('ripemd160')

ripemd160.update(hashlib.sha256(binascii.unhexlify(public_key)).digest())

I've changed the way you concatenated the public key with the prefix, and the call to the ripmd160.update, since it was expecting a string, not a Hash object.


What's going on with address 1NZ9kxxUykiNSe61ZRNPLqWeVHVRnirGry? Does anyone know what is going on here:

https://blockchain.info/address/1NZ9kxxUykiNSe61ZRNPLqWeVHVRnirGry

As far as I can tell, it looks like the "1NZ9..." address seems to be one one of those which "cannot be decoded"? How did blockchain.info then decide to show this information page on the address? Because, If I do a getrawtransaction on the tx shown there, I get no addresses from bitcoind.

And if the address is one of the "cannot be decoded" ones, how come the Total Received and Final Balance fields are 0?

What is happening here is that blockchain.info parser seems not to work well when decoding Pay-to-multisig scripts (P2MS).

All the outputs but last two contain Pay-to-multisig scripts as ScriptPubKey (1-3 Multisig for all but the very last one, that is 1-2 Multisig). The last two are normal Pay-to-PubkeyHash (P2PKH).

If you check the information in blockr.io for example, you will see it correctly displayed.

You can also check the decoded raw transaction to find it out. Here you have an example of one of the outputs:

"asm":"1 8322e509a68669409750b06abef89e48423d21c0089efcc211261c16e8f0a413a693bdee97ca3bd3424eb6247bc235a8d49d77cde681093a4824e462a9ea9610ed b72f5174d4946b456da718db0eb1e852a67544c67e6041f1eb6156bae1b1d788614d89542274f46f0100389a6b40f5158dab5da9870b3447b65e8d003665d0e969 db99614d616506661872851a2786ec296ca73dbab8dbf100c21ef2e80be79eb5d916ab3b3b29ec6e5dcda45a405c155655fe380d979877e53b2f1417a744ebf142 3 OP_CHECKMULTISIG"

Notice how the structure of the script is: OP_1 <Public_Key0><Public_Key1>...<Public_KeyN-1> OP_3 OP_CHECK_MULTISIG


Why can't altcoins erode Bitcoin's foundation? There already are hundreds of altcoins and even more are being created. However, Bitcoin still dwarfs all altcoins in value.

From a technical point of view, Bitcoin was invented 7 years ago and its technology is far from perfect (e.g. forking, speed). Why can't altcoins with improved features beat Bitcoin?

Bitcoin has the advantage of the network effect.
More info here:

What if someone creates a new block chain, or a new digital currency that renders Bitcoin obsolete?
Network effect


Opening a wallet with bitcoind I am running bitcoind after previously running bitcoin-qt. I made a wallet with bitcoin-qt (and encrypted it) and I would like to open it now with bitcoind. The folder that contains the wallet.dat file is in the data directory, but when I run either of the following:

bitcoin-cli listwallets
bitcoin-cli getwalletinfo

it does not show my wallet. I have tried:

bitcoind -wallet="directory with wallet.data file"

and still no luck, it just tried to rund bitcoind and says it is already running (not sure why, I am running bitcoind -daemon).

Any idea how I can import this wallet?

you must describe you bitcoin.conf , default was home folder user  .bitcoin

here i have some example BSV script for change defaut values such location wallet data block and etc.

example script manage blockchain

you can check in bsv folder there was running custom script and example config .


Strange re-connection problem with python-bitcoinrpc I am using https://github.com/jgarzik/python-bitcoinrpc to access the bitcoin core rpc. I have found a very strange re-connection problem.

from bitcoinrpc.authproxy import AuthServiceProxy, JSONRPCException

# rpc_user and rpc_password are set in the bitcoin.conf file
1. rpc_connection = AuthServiceProxy("http://%s:%s@127.0.0.1:8332"%(rpc_user, rpc_password))
2. best_block_hash = rpc_connection.getbestblockhash()
3. print(rpc_connection.getblock(best_block_hash))

The above code runs well in the python interactive window. However, after a while (for instance 10s), when I run the line2 again, it crashs with following info:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/fangjun/.local/lib/python3.5/site-packages/bitcoinrpc/authproxy.py", line 136, in __call__
    'Content-type': 'application/json'})
  File "/usr/lib/python3.5/http/client.py", line 1106, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib/python3.5/http/client.py", line 1151, in _send_request
    self.endheaders(body)
  File "/usr/lib/python3.5/http/client.py", line 1102, in endheaders
    self._send_output(message_body)
  File "/usr/lib/python3.5/http/client.py", line 936, in _send_output
    self.send(message_body)
  File "/usr/lib/python3.5/http/client.py", line 908, in send
    self.sock.sendall(data)
BrokenPipeError: [Errno 32] Broken pipe

if I reconnect the server again by running line1, then line2 runs well.

It seems I need to run line1 from time to time, but it doesn't make sense. Can some tell me the reason? Thanks.

Both the RPC client and the RPC server have timeouts, if no request or response has been received for X seconds, they will close the connection. By default the timeout is 30 seconds. I believe you are running into the timeout since you wait a while before trying to send another command. By that point, one end has timed out and thus the connection is closed resulting in Broken pipe errors.


How do miners know how to remove recently confirmed transactions? A miner is in the process of creating and mining a block of 1400 transactions. Suddenly they receive a broadcast that a new block was confirmed with 200 of the transactions currently in that miner's block. How does a miner proceed in this scenario - dropping the 200 and adding 200 others from the mempool and trying to mine a block?

In a second scenario, two blocks are created almost at the same time and they each have some of the same and some different transactions. I'm assuming (a) that there is then a race to consensus for each and the first to 51% wins a confirmation. If so, then similar to above (b) the block with losing transactions has all the dissimilar transactions dumped back in the mempool. But what if a second chain surfaces with two blocks? Now all the confirmations in (a) that aren't confirmed in this second block get dumped back into the mempool and hopefully finally mined into the blockchain?

The takeway for me >>> Obviously this system does work since its very popular! But it seems that transactions can take a very long time and no way to really guarantee that they will occur unless a payor decides to pay a high fee to almost confirm that miners will pay attention to his transactions first and most will include that transaction into the miner's next block to add to the chain.

How does a miner proceed in this scenario - dropping the 200 and adding 200 others from the mempool and trying to mine a block?

If the miner is trying to build on top of the block that was received, then he will have to drop the 200 transactions that were included in the other block. He will also not be able to include the other transactions in the next block that were present in the block he received. Apart from this, he is not restricted which valid transaction he can include. He can fill in more valid transactions, remove some or remove all the transactions and just mine the block with coinbase transaction. It's up to his discretion.

  Two blocks are created almost at the same time and they each have some of the same and some different transactions.

Imagine a scenario where two miners find a solution at the same time and both the blocks are valid. As soon as they find the solution, they will relay the block to the full nodes. The nodes will add the block that reaches to them first and add it on top of the existing blockchain. However, when they receive the other block at the same height, they will not discard it but maintain a copy of it. So here you have a blockchain fork, where around half the nodes have a different version of the blockchain at the best height. Other mining nodes will start mining the subsequent block based on the copy of the blockchain that they are seeing (on top of the block that they received first.) Now, one of the miner will find a solution and propagate it to the network. More likely than not, it will not happen to be simultaneous like the previous block. So when that block is propagated, the network converges back to a shared state. Now, as the network converges the full nodes will discard the transactions from the mempool that are already confirmed.


get Armory to use an existing blockchain? I'm trying to set up Armory but it wants to download the whole blockchain.  The thing is I already have the blockchain downloaded on the same machine for bitcoin-qt.  Is there any way to get Armory to use the blockchain I already have, both to save space and avoid waiting for hours?

If your settings are correct, try restarting Armory, and let it run for a few minutes. I had the same concern thinking that Armory was redownloading the blockchain, but it was actually reading from the harddrive (Listen to the harddrive).

After roughly 10 minutes, the block synchronisation went from 0% very quickly to 100%, then the status changed to "Connected". Next Armory synced the transaction history for another 10 to 15 mins.

I guess there is a user experience bug here. Armory should have had a user friendly message somewhere saying something like: "Verifying local blockchain".


Why is POW/POS absolutely necessary to run public distributed ledger? my first question here, so please be patient with me. Thank you in advance.

Q: Why exactly are POW/POS mechanisms needed to secure the blockchain (in bitcoin as well as in other alts)? + what is terribly wrong with my example below and why ? (I feel like I am missing something very important here). Thank you very much.

I mean:
- why the block verifying and signing party cannot be just randomly selected node, that would every X minutes put new transactions into the block, calculate hash of block and sign it by its public key, broadcast it to other nodes for inclusion in the blockchain and collect some the reward ? (provided nodes on the network are able to reach some kind of consensus on selected random node - I know it is not easy task - but let's assume it can be done for a moment)

I mean, possible attacks on the network are still there, but it is same as with POW/POS, but:

if node is selected 'truly randomly' (I know, I know), the attacker would need to have just pure luck if he wants to fork the chain with his crafted transactions, because he does not know when he will have the privilege to sign the block...
Or he would need to increase its share of nodes in the network significantly (same with 51% attack in POW/POS)

Above can be (?) mitigated to some degree with including check points in every N blocks in the best chain and having the rule of including e.g. hash of N-x block into recent transactions. (at least from what I understand, that is what some POS coins do)

Why there needs to be POW/POS? (electricity burning/(locked) coins in wallet staking)

Thank you very much for putting my thought process back on track.

You can't do this due to the Sybil Problem. There is no way of proving a node is an individual participant in the system, you can't prove that a node existed at any point in time (or didn't), and there's no source of random numbers at all in the system which can't be influenced or altered.

Proof of Work is a side step to having potentially clones participants in a system vote on validity, it replaces this is with a system in which members of the network verifiably destroy real world resources in order to create additions to the ledger. By adding a real world cost to producing alternate histories, it becomes infeasible for people to modify the history of the system and present it as the truth to anybody else. When faced with multiple choices, participants have a tie breaker by simply comparing the relative amount of resources destroyed and picking the most destructive one.

In your described model:

How do you know that the network is really of this size?
How do you prove to a third party joining the network that you are not all the participants in the network pretending to be other people?
What is to prevent any node in the network signing many alternate histories in which people do and do not get paid, and using this to trick people out of money?

The proposed system breaks down as soon as you introduce malice, which is something cryptocurrencies must be design to defend against. Millions of fake nodes, lying, cheating, and denial of service attacks are all things the system must expect to encounter.

  at least from what I understand, that is what some POS coins do

Proof of Stake cryptocurrencies are usually completely centralized, due to the behavior you're describing here. Faced with the knowledge that PoS is not a method of distributed consensus they use centralized control in an attempt to ensure that the chain is coherent.


Funds received still shows pending and unavailable until confirmed in Exodus. Should I be concerned? I have a transaction I received in my account that has been marked as pending for the last 12 hours (now 16) and counting. The BTC and US equivalent shows in my wallet (Exodus) but  the wallet has it pending and states its unavailable until confirmed. This has me a bit worried that I will not receive my funds, even though when I check the transaction ID on BlockChair it shows 77 (now 102) confirmations.  This is first time a transaction has taken so long, the most time it took in the past was more or less 30 minutes.  Thanks in advance for educating me on the subject.

This has me a bit worried that I will not receive my funds, even though the blockchain shows 77 confirmations.

The blockchain is the only truth. Those funds have been received long ago.

The only question is why your wallet isn't showing it.

There are many possible reasons, some are

your wallet is a "custodial wallet" owned by some corporation  - you need to talk to the business involved
your wallet is a "full-node" type of "custodial" wallet - you need to check if it has fully synchronised.
there is some other problem with your wallet.
you have been tricked by a scammer.

For more precise help, you could edit your question to include details of the name and type of wallet and some general description of where the transaction came from (a friend? a customer? an investment manager?)


What is bitcoind.pid? The file bitcoind.pid is mentioned on "Running Bitcoin" wiki page, but it's not explained on the wiki. What does that file do?

Isn't it the file containing (the current running instance of) bitcoin's pid,
http://en.wikipedia.org/wiki/Process_identifier#Pidfile?


What is the point of miner signaling in a soft fork activation mechanism? What should the threshold be on miner signaling? What is the point of miner signaling in a soft fork activation mechanism? What should the threshold be on miner signaling?
The second part of this question was asked by devrandom on IRC.
A question on the risks of reducing the threshold to below 95 percent was asked back in 2017 here.

What is the point of miner signaling in a soft fork activation mechanism?

Miners are signaling readiness for a soft fork activation, they are not signaling to support (or vote for) a soft fork. It seems generally accepted at the time of writing (February 2021) that any opposition towards a soft fork should be raised and discussed before an activation mechanism is proposed. If arguments are raised that haven't previously been considered or that opposition is material and sustained across the wider community, activation for that soft fork shouldn't be considered.
Ideally you want as many miners enforcing the Taproot rules at the point it activates as possible. Otherwise an invalid Taproot spend could creep into a block and some miners wouldn't reject it as they would be treating it as an anyone-can-spend. It would need a small, naturally occurring re-org to get that invalid Taproot spend out of the blockchain. This wouldn't be a disaster but ideally you don't want a greater frequency or greater magnitude of re-orgs than usually occur. Ideally you want all miners enforcing the Taproot rules from the point of activation.
There is also the consideration of miners deliberately or inadvertently producing blocks with invalid Taproot spends in them and fooling SPV/non-upgraded clients that is discussed here.
As devrandom pointed out on IRC there is motivation for presumably unready miners who haven't yet signaled to get ready urgently if the soft fork is activating soon. They don't want to expend resources mining blocks (with an invalid Taproot spend in them) that will ultimately be rejected by a proportion of the network. But that doesn't guarantee they will be ready and may lead to miners rushing to get ready for activation which again is not optimal.

What should the threshold be on miner signaling?

This is harder to answer as the threshold chosen appears to be a trade-off between ensuring as many miners are ready to activate the soft fork as possible and preventing a small minority of miners from unnecessarily delaying the soft fork for political or strategic reasons. With the SegWit soft fork in 2017, a BIP 148 user activated soft fork needed to be proposed because miners were assessed to be deliberately blocking activation to attempt to force through an additional block size increase.
In this developer survey conducted by AJ Towns the question "What do you consider a reasonable threshold for activation by hashpower supermajority?" it appears 90 percent or 95 percent would be the preferred threshold. The threshold for the SegWit activation was set initially at 95 percent.


Is there any consensus over specific improvements Bitcoin needs? There has been some criticism from cryptography experts about the current Bitcoin algorithm(s). Now that Bitcoin has been released to the wild and everyone has had time to study it, is there any consensus for improvements that could be made to make Bitcoin better?

If it was possible to start over knowing what we know now could Bitcoin be designed any better?

There is no consensus. I think part of the reason for that is that many people involved in the Bitcoin project have a vested interest in maintaining that there is nothing wrong with Bitcoin.

In fact, there really is nothing wrong with Bitcoin, but there is lots of room for improvement. However, most improvements suggested have corresponding costs, and there is no consensus that the benefits outweigh the costs for many of the improvements.

Here are a few areas where improvements are likely possible:

The mining algorithm is only computation hard. It is not memory hard or decision hard.
Anonymity is limited by the inability to publish a receiving address without revealing how many coins are transferred to that address.
There is no good way to prune the block chain.
There is no good way to reverse a transaction or indicate acceptance of a transaction.
Transaction fees are not predictable long-term.
Mining pools have centralized the decision of which transactions to include and which chain to work on, defeating some of the protection diversified mining was supposed to provide.
There is no way to recover lost coins.
There is no good way to manage the currency if that turns out to be needed. For example, the block payout algorithm is all but fixed in stone but may make no sense in a decade.
There is no good way to pull coins out of the block chain such that they can be put back in.
A 51% attack can revert as much of the chain as desired, up to the last checkpoint.

My own opinion is that it's way too early to talk about Bitcoin 2.0. We don't know enough about what's really right and what's really wrong yet, and such efforts would actually work against broader adoption of crypto-currencies by reducing stability.


Bitcoin-ruby returns "nil" value for bitcoin-cli calls I am new to test "bitcoin-ruby" to parse bitcoin blockchain data. But while testing it, I am having issues to make some bitcoin-cli commands to get this to work. The environment I'm using is :

*Linux version- Ubuntu 16.04 LTS
*Bitcoin Core version- 0.14.2
*Rbenv version- 2.4.3
*Gem version -2.6.14
*Ruby version-
*Bitcoin-ruby version
*ruby -2.4.3p205 (2017-12-14 revision 61247)
*bitcoin-ruby version- 0.0.15

Here are the codes I am using to parse the data :

require 'bitcoin'
require 'net/http'
require 'json'
RPCUSER = "***"
RPCPASSWORD ="***"

HOST = "localhost"
PORT= 8332

def bitcoinRPC(method,param)
http = Net::HTTP.new(HOST,PORT)
request = Net::HTTP::Post.new('/')
request.basic_auth(RPCUSER,RPCPASSWORD)
request.content_type = 'application/json'
request.body = {method: method, param: param, id: 'jsonrpc'}.to_json
JSON.parse(http.request(request).body)["result"]
end

The following bitcoin-cli commands are working via bitcoinRPC :

bitcoinRPC("help",[])

bitcoinRPC("getnewaddress",[])

bitcoinRPC("getchaintips",[])

But following returns "nil" vale :

bid = "0000000000000000004bd4aff1966f6df18b1dba6f6ef83a878e526ab31eee73"
bitcoinRPC("getblock",[bid])-> "nil"

Any idea how to fix this issue?

Thanks in advance.

The above code is only using RPC to Bitcoin Core and bitcoin-ruby is not used.

The problem is the body parameter name when sending the request.
Change param key to params as follow.

request.body = {method: method, params: param, id: 'jsonrpc'}.to_json


Is using bitcoin for savings a risky choice? I'd like to start saving money and there are a few options.

Cash provides anonymity but it's very susceptible to steal and I must have a physical space for it.
A bank account is much safer but I don't really like the system to keep track of my savings.
An offline bitcoin wallet would provide both safety and anonymity.

It seems the last option is the best choice because the money saved can even go up in value as bitcoin deflates. But, what if it never takes off as a mass used currency? What if it somehow gets deprecated by a similar cryptocurrency?

How big is the risk of saving in a bitcoin address?

Buying bitcoins shouldn't be thought of as savings, it's a very high-risk speculative investment. It could go way up in value, or way down.

Luckily, if you want Bitcoin's power of secure storage without exposure to the exchange rate, you can do that too, in theory at least. Use most of your funds to buy X bitcoins, and use the rest as collateral to short-sell X bitcoins. You'd have to pay a bit more for the exchange, pay an interest rate, and trust some of your money with the platform, and there aren't currently very good margin trading platforms, but it can be done and might be worth it if you're sufficiently averse to the traditional alternatives.


UTXO all sent to change address? I have read this question that asks if all UTXOs in an address are sent to a change address or only the UTXO involved in the transaction.

As part of a spending transaction, the public address is revealed. And that is part of the reason people suggest not to reuse an address.

My questions are:

Are all UTXOs (even those not part of the transaction) sent to a change address or only the one involved in the transaction? (This was not really answered in the linked question.)
If only the one involved in the transaction is sent to a change address, is it not a security risk? The remaining UTXOs left in the bitcoin address now have their public key made public.

It is always up to the wallet client to decide which UTXOs are to be spent.  The protocol certainly doesn't require all UTXOs of an address to be spent at the same time.  A particular wallet client could be coded to do that, but I don't know of any that are.

Here you can see a testnet example.  Transaction 90d042b... spent only 2 of the 9 UTXOs available in address moooopfhBjQDSJQuCj4aVr6s4b5pFbQin4.  This transaction was created with just the ordinary sendtoaddress command in Bitcoin Core, no special options.

This isn't a significant security risk.  In a secure digital signature protocol, it should be infeasible to generate a valid signature without access to the private key, even if the public key is known.  That's what "public" means!  As far as we know, ECDSA is secure, so revealing the public key doesn't harm security.

Some people believe in planning for the possibility that an attack might someday be found on ECDSA.  If so, then there would be some advantage in not having revealed your public key.  After a new signing algorithm is incorporated into Bitcoin, you could create a transaction sending your coins to an address which uses the new algorithm.  This would reveal your public key and attackers could get started, but assuming the attack is fairly computationally intensive, you hope your transaction would be confirmed before an attacker could successfully create a forged signature on a transaction that would send your coins to him.

The tradeoff of this approach is that, as you note, as soon as you want to spend any coins from an address, you have to spend all the UTXOs.  This increases the size of the transaction and thus costs you more in fees.  That's why most clients don't do it; the security improvement is theoretical at best, but the costs are real.


Besides greater probablity of discovery, are there other **significant** optimizations a of mining pool? Besides the benefit of increased attempts, are there any other significant, measurable optimizations that mining pools provide? I'm referring to intrinsic functions such as non-duplication of failed "hashes" (assuming this is actually an implemented feature) that is a direct yield of mining hardware/software working in concert, not mining farm benefits such as economies of scale savings (i.e. group discounts on energy).

Yes.

Usually if you would solo-mine you will need to update/download the entire blockchain, which as of right now, is 141GB.

If you join a pool, this isn't the case, You actually don't even need to be connected to any of the peers/nodes from the bitcoin network.

This could greatly decrease the money you would spend on bandwith in some countries, which could be another reason to join Pool-mining.

It also saves you a lot of time, depending on your internet speed.


Why do we trust that the person who got a chance to add block will add a valid transaction block? I read about blockchain in many websites but didn't understand what actually blockchain offers the proof of work.

A transaction will be broadcasted to the every node in the network and then someone will get a chance to add a new block to the existing ledger. How can we trust that on the person who adds the block to ledger is valid i.e he can add invalid transaction and append to the ledger?

He can calculate the hash of existing ledger and invalid transaction and can append to the existing ledger? And what do the miners? By calculating nonce what they will do?  I didn't understand how the update to ledger is happening.

Miners don't calculate nonces, they calculate cryptographic hashes using nonces as one of the inputs.

A cryptographic hash is a function that takes as input some arbitrary data and produces as output a unique string.[1]  They always produce the same output string for the same input data.  Here's an example using the sha256 hash function (the basis for the function used in Bitcoin):

$ echo foo | sha256sum
b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c  -
$ echo foo | sha256sum
b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c  -
$ echo bar | sha256sum
7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730  -

In the above, "foo" and "bar" are the input and the strings starting with b5bb and 7d86 are the output.

What miners attempt to do is find a hash output that has a certain number of zeros in a certain location (we usually call this the start or front of the hash[2]).  To do this they start with the data they want to add to the ledger and then increment a nonce (or otherwise adjust the block) until they get the desired value.

For example, let's say we want to add a transaction of "Alice pays Bob 10 BTC" to the ledger and the number of zeros we want at the start of the hash is just 1.  We start by doing this:

$ echo "Alice pays Bob 10 BTC | nonce: 0" | sha256sum
39a946f968d6986b2d560bbb0d63af04578352f02f48c1bfd71e535cd1148a6f  -

As you can see, our first nonce of "0" didn't produce a hash starting with 0.  So we try again:

$ echo "Alice pays Bob 10 BTC | nonce: 1" | sha256sum
dce8dff1c536cdb43861e4ea1bc843e6f110e82768cfcca656d8c5f53cc7fc1d  -

Again, we don't get the desired result.  So we keep trying over and over until we do get the desired result:

$ echo "Alice pays Bob 10 BTC | nonce: 18" | sha256sum
005b8307be5a9447be13ba6f026e9d3b695bfd5dc6ce633ac928de8cd8634a1f  -

So we had to do the work of generating a hash 19 times before finding a hash starting with the number zero.  This is called proof of work.

Now the person who found this proof of work can share all of the data---both the transaction and the nonce---to other people, and those people can verify that the input data of "Alice pays Bob 10 BTC | nonce: 18" does equal the a hash with one zero worth of proof of work.

One zero worth of proof of work isn't much (it's 4 bits or odds of 1:15), but real miners deal with much greater amounts and producing all of the work requires consuming a large amount of electricity.  Normally miners are rewarded for consuming that electricity by receiving a reward for protecting transactions with proof of work---but they only receive the reward if the transactions they protect are valid.[3]  Otherwise any proof of work they generate is wasted, meaning the electricity they use is wasted and they'll be less profitable than other miners who protect valid transactions.

For example, in the above example, if Alice didn't have 10 BTC to give to Bob, then that transaction would be invalid and so it wouldn't matter that the hash of the data starts with a zero---users who verify every transaction using what's called a "full node" will simply ignore that transaction and its proof of work.

So in short, what prevents a miner from adding an invalid transaction to the ledger is a combination of users who reject invalid transactions with their full nodes and an economic incentive paid to miners who mine valid transactions.

[1] Hash functions don't always work like this, but that's the ideal.

[2] But that's because Bitcoin displays hashes weirdly.  To any other tool, it'd be the end or back of the hash.

[3] Technically, they only receive the reward if other people think their transactions are valid.  Currently, there are a lot of Bitcoin users who verify every transaction, so it's not possible to sneak in an invalid transaction.  In other cryptocurrencies or a sad future where Bitcoin becomes less secure, that may not be the case


How does bitcore handle transactions in orphan block situation? I know orphan blocks can occur naturally when two miners produce blocks at similar times.
in bitcore-node, How does this handled?
for example, when orphan block occur in node, does bitcore change blockHeight in transactions table?

If there are multiple chaintips that match in total work, Bitcoin Core will consider the one it heard first about the best chain. Only if another chaintip accumulates more work, it'll switch to that chaintip. As only one block can be part of the best chain at the same height, the competing block is essentially irrelevant unless it happens to become part of the best chaintip.

Example:
After block 99, there were two competing blocks found at the same time. Our full node first hears about block 100A (the asterisk marks the block our full node currently considers the chaintip), and a peer announces chaintip B with a different block at height 100. Bitcoin Core will not update its chaintip, but still consider 100A the best chaintip.

           100A*
98 ← 99 ↢
           100B

It's very unlikely that both 100A and 100B get a successor block at the same time. Let's say that the chaintip B is extended first.

           100A*
98 ← 99 ↢
           100B ← 101B

Upon learning about the new best chain, our full node will first revert block 100A: all of the transactions that got confirmed in block 100A get added back to the mempool and marked unconfirmed.

            100A
98 ← 99* ↢
            100B ← 101B

Then the full node follows the best chain by applying the two blocks 100B and 101B.

           100A
98 ← 99 ↢
           100B ← 101B*

Any transactions that had been confirmed in 100A might have now been associated with 100B or 101B instead, or they may still be in the mempool.


Can I use an old Pentium 4 desktop for mining if I upgrade it with a good GPU? I know that the most important thing for mining is a GPU. I read some stuff about it but I never read a specific answer to this simple question.

I have some old desktop computer. Pentium 4 (~1GHz) processor and (maybe 256-)512 MBs or RAM.
Can I use this computer as a base for a simple mining machine if I can just put in a decent GPU??
I'm just strolling the internet for second-hand GPUs and asking friends, but I cannot afford to invest too much in it, so I'd like to be able to use that desktop for my setup.

With a decent enough GPU (or GPUs), your machine will be a fine miner. The only spec that ACTUALLY matters for mining is the GPU. RAM, CPU, etc don't have much of an impact.


Where is the pubkey for segwit inputs? Normally when you spend an input, you reveal your public key and signature so that ECVERIFY can be done.

I look at segwit raw transactions and cannot find the public key inside them, where do they go?

Example: https://www.blockchain.com/btc/tx/3179d18d6f36fa77b88909496535485d8188d96b79d295843789a9e0ff6c3e6a

Is there a way to reliably retrieve the pubkey and it's position in the raw transaction?

It's in the witness right after the signature.

ScriptSig: PUSHDATA(22)[00144b9d2d3dd1174ad656754a0c664e7a129b131f3b]
Witness:     0247304402201cf8db0c4afc164970ec4397327fe9b1dd9b7ff4a9093f94e554d624b5ffdcb702202848072c17f2bcce16b8d3d7cb2efdad87bc6c942b79f44b79f1c52f817d81ea012102384052a5ecde83bf8ee7ed77f378edb58aa65de22c4e91af87eee68015b9d509

0247304402201cf8db0c4afc164970ec4397327fe9b1dd9b7ff4a9093f94e554d624b5ffdcb702202848072c17f2bcce16b8d3d7cb2efdad87bc6c942b79f44b79f1c52f817d81ea012102384052a5ecde83bf8ee7ed77f378edb58aa65de22c4e91af87eee68015b9d509

EDIT:

  Is there a way to reliably retrieve the pubkey and it's position in the raw transaction?

You have to parse the witness.

02 : 2 items to follow

47 : 0x47 = 71 bytes (signature)

304402201cf8db0c4afc164970ec4397327fe9b1dd9b7ff4a9093f94e554d624b5ffdcb702202848072c17f2bcce16b8d3d7cb2efdad87bc6c942b79f44b79f1c52f817d81ea01 : the actual signature (last byte is the sighash code)

21 : 0x21 = 33 bytes (the pubkey)

02384052a5ecde83bf8ee7ed77f378edb58aa65de22c4e91af87eee68015b9d509 : the actual pubkey


How do I export my private keys from my Bitcoin-Qt client? Trying to use this posted method:

To export a private key from your Satoshi bitcoin-qt client:

launch your bitcoin client as usual and wait for it to load the blockchain and start up
click on 'help' in the menu bar (top right)
click on 'debug window'
select the 'console' tab
type: walletpassphrase "your walletpassphrase here" 600
type: dumpprivkey [your bitcoin address here]
this will return the private key, you can copy it now; ensure you clear your clipboard/history afterwards
type: walletlock

I do not understand what "your walletpassphrase here" means.  I do not have a wallet pass phrase to the best of my knowledge.

Also, I am a bit of an amateur at this and I still don't understand the "your public key here"..... is that the address that corresponds to your wallet? [Update: Yes, the bitcoin address.]

Trying to export the private key to another wallet because the bitcoin wallet has taken 2 days to sync and is still not done.

Any help would be very appreciated.

I believe that listreceivedbyaddress 0 true does not list the change addresses that are created as part of the normal client operation.

Starting from bitcoin 0.7, you should use bitcoind listaddressgroupings to get all the addresses, and then follow up as usual with dumpprivkey.


Bitcoin TX decode failed while sending to a the network(regtest) I have created a signature manually (referring the signature output formats in bitcoin-cli). But i tried to send the same to the network I am getting

error code: -22

error message:

TX decode failed

Below is the signed tx

signed tx:

020000000138c059adfe41e80fb46e14d23949304343abc560a6fbcef4b2e3110f8241816d00000000002c2b0768616e756d616ea8201ca35897540ec7ae7294a8cacd11caf2c09f95f026c925c6ce4e4c29b20e3c4187ffffffff0280507401000000001976a9146a3ffadddae4ccb4223a8c7215d4b481daf6967788ac00d012130000000017a914def347cf3b01bf03a30d7ee9f62d86ed5109b5478700000000

Spliting the same signed tx:

02 00 00 00  // version

01   // number of inputs (var_uint)

38 c0 59 ad fe 41 e8 0f b4 6e 14 d2 39 49 30 43 43 ab c5 60 a6 fb ce f4 b2 e3

11 0f 82 41 81 6d  // input transaction hash

00 00 00 00 00 //  input index

2c // size of script (var_uint)

2b // data needs to be pushed  the below 43 bytes will be pushed

07 // push 7 bytes to stack

68 61 6e 75 6d 61 6e // data needs to be pushed

a8 // OP_HASH256

20 // push 32 bytes

1c a3 58 97 54 0e c7 ae 72 94 a8 ca cd 11 ca f2 c0 9f 95 f0 26 c9 25 c6 ce 4e

4c 29 b2 0e 3c 41

87 // OP_EQUAL

ff ff ff ff // sequence

02  // no of vouts

80 50 74 01 00 00 00 00 // amount

19 // size of script (var_uint)

76 //OP_DUP

a9 // OP_HAH160

14  // 20 bytes needs to be pushed

6a 3f fa dd da e4 cc b4 22 3a 8c 72 15 d4 b4 81 da f6 96 77

88 // OP_EQUALVERIFY

ac //OP_CHECKSIG

00 d0 12 13 00 00 00 00 // amount

17 // size of script (var_uint)

a9 //  OP_HASH160

14 // 20 bytes needs to be pushed

de f3 47 cf 3b 01 bf 03 a3 0d 7e e9 f6 2d 86 ed 51 09 b5 47

87 // OP_EQUAL

00000000 // lock time

Can anyone please help me to find what is that I am missing ?

Your input txid output index is 5 bytes, when it should be 4 bytes. Just remove the extra 00 byte and the transaction will not pop an error. However, you might need to sign this transaction again as signature involves signing the entire serialized transaction as a message and by changing the txid outpoint you will change the message that is signed.


Crypto Mining with PC I have PC - i7-6700K CPU @ 4.00GHz & graphic: Intel Corporation HD Graphics 530. My Os is Ubuntu. How many Mh/s i could receive for Ethereum? Let's assume the current is free.

You can use MinerGate app Benchmark feature to estimate how fast your PC is.
IMHO it's not possible to generate MH/s on a regular desktop PC. You need a rig to reach that speed. You can have some two-digit hashes, maybe 1 kH/s but no MH/s.


Guessing nonce - nonce pools/domains Blockchain miners calculate the hash of (block data + nonce value). They actually guess (are looking for) nonce in order to get hash staring with a defined number zeroes. (The number of required starting zeros in hash value define the difficulty of finding a nonce that fits - proof of work).

My question is do all miners guess/try nonces from the same pool or range (this way they actually non-efficiently test the same guesses many times) or they somehow split the pool of possible nonces among themselves in order not to try the same nonces multiple times?

The nonce value is indeed "guessed" by the miner.

The miner can also choose a part of the coinbase transaction (what the stratum protocol calls the ExtraNonce2). Another part of the coinbase transaction is imposed by the pool: this is the ExtraNonce1, in terms of the stratum protocol.

Pools are supposed to assign distinct ExtraNonce1 to all miners, to prevent duplication of work.


Trying to sync a new node and keep getting hashMerkleRoot mismatch I've tried syncing this same MacBook Pro multiple times and it keeps stalling. The debug.log file keeps repeating the same two lines at block 275162:

2017-07-07 03:09:59 ERROR: ConnectBlock: Consensus::CheckBlock: bad-txnmrklroot, hashMerkleRoot mismatch (code 16)
2017-07-07 03:09:59 ERROR: ConnectTip(): ConnectBlock 0000000000000002373cc5cc98604fa31361a495ec20eebb54861e9f489d3336 failed

Any light on the issue would be appreciated.

This error means that you have a corrupted block. The only surefire way to fix this is to redownload the entire blockchain. You can do that by going to the Bitcoin Core datadir (get the path by going to Help > Debug Window in Core and there will be a field labeled datadir) and deleting the blocks folder, after first shutting down Core. Then start Core and let it sync from scratch.


Why new public key for every new request? I created Bitcoin accounts using different clients but all clients I tried prompt for new public key for each request. My question is shouldn't be the public key one's identity which one should be able to publish and own even changing bitcoin clients.

Clients always give me new key which makes me feel insecure to use a single key for overtime use. For example I created and want to stick to this key: 1N3eYqC7EJdbBBXQ6ntQpmzedVrGeG8iqJ but if I go create another request new key will be generated, the main concern is should I be sure that this key will always be pointed to my wallet? As I am not sure and don't have bitcoins to test if coins are received at this address.

I have used multiBit and Android App, none of these give private key as far I browsed. I am looking for an 'identity' to publish for receiving any number of payment, like we can share our paypal email to receive payments.

The reason is privacy.

If you reuse the same key for every transaction, everyone who ever transacts with you can infer your entire balance.

No, public keys should not be identities, exactly because the transactions to them are public too. Your ability to create many pseudonyms in the system the only way through which it has any privacy. By reusing addresses you hurt your privacy, but also that of others who interact with you.


Can bitcoin script look at the output? I was wondering if it possible for a bitcoin script check part of the output of the transaction.
Lets say, I want to check that the transaction is splited equaly between 3 outputs, I dont care which.

No. With current script. There is a locking script, and an unlocking script. Basically the locking script (scriptPubKey) in the old transaction puts down the condition to spend BTC. The scriptSig in the spending tx must provide the data to satisfy these conditions. Problem is, that current script language does not provide an access to data „outsides“ the scripting language. So you would have to define conditions in the locking script „upfront“, while creating the tx. But then the unlock script does not allow for operators, and only accepts „push data“, like pushing the signatures or pubkey. This might change in the future, discussions are running to implement a new scripting subsystem, which is currently checked in a side chain. This will allow to access oracle data (not with „simplicity“ though), which could be a previous tx as well.

Keywords: RSK Elements, Ivy, Simplicity, Bitcoin Smart Contracts,  Scriptless Scripts and possibly some more.

Short answer: currently no.


Question about spam attacks From my understanding, an unconfirmed transaction can be accepted into the mempool provided that it has a fee that is generally at least 5460 satoshi, which is set as default in the current version of Bitcoin Core (assuming input=148B, output=34B, and relay node hasn't changed default settings). If a spammer sent a transaction like that, wouldn't it most likely not get picked up from the mempool by any miner (because of low fees) and thereby be returned to the original spammer at no loss? Couldn't this happen for a large number of similar transactions?

yes, but then the "spammer" hasn't really accomplished anything.

essentially with spamming its either
1) you paid to get a "spam" transaction included in a block
or
2) you paid nothing to get it in the mempool

not really spam either way at this point


BTC missing after strange negative transaction four years ago I've bought 1 BTC, made wallet.dat file and stored in the cloud. Now I wanted to check balance and after syncing on Bitcoin Core found negative transaction with no address.

I did not make second transaction. It has no address. What it is? What the second negative transaction means? Why strange icon? Here's second transaction ID 4837f44e4169f287ca6802c45ceab2dfef36ab7d8ecaa0eaebfa59ea6c76e17b

I have 2 public keys. I've tried to dumpprivkey. After obtaining private keys I've tried to import to one local Bitcoin service (spectrocoin) but after 24 hours nothing changed.

Does it mean that I've lost BTC? Is there anything else I can do? Thank you for your help.

It looks like, using just the 17nu address here:

https://longhorn.bullpay.com/?gateway=2&data=17nu7oViEtGCYaYwrKKVGyrs7jkcNwpVf2

Only 2 transactions occurred. This transaction:

https://longhorn.bullpay.com/?gateway=2&data=fae9171eea55eb69cbe73f8a23003f9267b71e5a7292d2bcd7b396a58aa82827

Resulted in the UTXO for 1 BTC to 17nu.

That UTXO was then used in this one:

https://longhorn.bullpay.com/?gateway=2&data=4837f44e4169f287ca6802c45ceab2dfef36ab7d8ecaa0eaebfa59ea6c76e17b

But it was combined with other transaction unrelated to the wallet. I'd say your wallet was compromised. Your transactions got bundled in with other UTXO's elsewhere not related to your wallet.

The address it was sent to:

https://longhorn.bullpay.com/?gateway=2&data=1NqJgMT4eLPycaD2i7T7xzbd9F9fycWE9u

had a flurry of activity on 5/6/14 within a 2 hour time period. In some cases with massive bundling of UTXO's. 34 inputs, 56 inputs. The transactions moving BTC from that wallet out left it with a zero balance.

Almost all of this funnels into address 17gH1u6VJwhVD9cWR59jfeinLMzag2GZ43:

https://longhorn.bullpay.com/?gateway=2&data=17gH1u6VJwhVD9cWR59jfeinLMzag2GZ43&grid-page=1

Which processed 17,990 transactions between March 2014 thru October 2014. The entire wallet was left empty with 120,347 BTC passing through it.

Either this address is used to launder BTC or simple as a convergence point for distribution. Either way this address is tied to a number of google search results in people getting hacked. Eg: https://bitcointalk.org/index.php?topic=754624.0;all

Final answer. You were hacked in some way.

Note: I added all the text in here to show how i traced his BTC from his address to an address known for hacking. This was to demonstrate how i came to the conclusion it was a hack and not an anomaly, software error, bug or something other.


Is it possible to exploit the use of the same private keys on different crypto coins? Suppose someone has single private key, and from that private key he made a public key for Bitcoin, Ethereum, Dogecoin, etc. - is it possible to figure out the private key having those multiple public keys?

It depends on how many times that private key has been used and whether the attacker has access to a side channel. Practically speaking if the attacker does not have access to a side channel and does not know a vulnerability in the secp256k1 curve (there are no known ones), then no, it's not practically possible to figure out the private key.


After various attempts to push through, this BTC transaction is taking forever to confirm? I have lodged it with ViaBTC for acceleration and yet no joy on it...Can anybody tell me what you think the issue is with this one?

b451ebd0ba7ff7b4d75117a3fd6a64a8e42b82da0135a03ed73fdc6bf4d52cf4

It is a transaction that I withdrew from Trady.io.

Suggestions....or can anyone potentially push through...as I have no idea what to do next?

Thanks!

You may pay a higher fee when you make a btc transfer. For instant in blockchain.info you can set it to fast transfer now!


What would happen if PoW cost were drastically reduced or eliminated? Assuming Bitcoin had a different method for selecting winning nodes and controlling block time creation, please describe step-by-step how the Bitcoin network would be vulnerable to various attacks. How would it play out?

Preferred format:

Bad Actor is selected as winning node
Bad Actor makes changes to an Old Block
Bad Actor re-hashes affected block segments, from Old Block to Last Block — (now possible due to low cost)
Bad Actor processes New Block

Please continue...

It think you have your steps of an exploit wrong.  It sounds like you are trying to describe a 51% attack, but are ignoring several factors

First off, step 1 isn't required for steps 2-4 to occur.  A bad actor could make changes to an old block (for example, removing a transaction) and then perform the proof of work on that block and all the blocks on top.  Winning the current block isn't required until all the blocks on top of the edited one are computed and caught up to the current block height (or really chainwork).  So the order of the attack would be step 2, step 3.

Step 4 also isn't really required.  Once the attacker has a longer chain than the rest of the network, she can simply publish their blocks, and other nodes will perform a reorganization.  Whether it's the attacker or someone else that wins the next block doesn't matter.  The edit of a previous block has already occurred, and the attack is complete.

So, in your preferred format:

Bad Actor makes changes to an Old Block
Bad Actor re-hashes affected
block segments, from Old Block to Last Block — (now possible due to
low cost)
Attack complete

The problem with this is that you are assuming that only the attacker has the reduced cost for PoW.  If everyone has access to cheaper hashing, then it doesn't matter that the attacker has access, because she would still have to out-compete the rest of the network combined.  Also, even if the attacker is the only one with access, there's only a limited amount of blocks she can reasonably recompute in a timeframe.  Every 2,016 blocks the difficulty is recalculated based on the amount of time that it took to calculate the previous 2,016 blocks.  If a decent number of those blocks were calculated in secret at this much higher rate, it will increase the difficulty even for blocks calculated in secret.  At some point, the attacker would be making her own job harder.

You may want to read this question to understand better:  What can an attacker with 51% of hash power do?


Security wise what stops me from canceling an unconfirmed transaction? I'm in a restaurant where they serve me my meal without waiting for the blockchain confirmation. Technically speaking I can cancel my transaction before the confirmation according to this

So what stops me from doing the same thing with bigger, riskier transactions?

So what stops me from doing the same thing with bigger, riskier transactions?

Because anyone accepting a bigger, riskier transaction should know enough to wait for at least a single confirmation.

Restaurants and stores all know that they will be subjected to a certain amount of theft and fraud, but since the amounts are so small, it's mitigated by their business volume.  Preventing easily-fraudable transactions from getting too high is the reason credit cards and debit cards have limits.

If you were to buy a house, however, you'll notice that the means of payment is a much slower and complex process than it is to buy a sandwich.  You don't just swipe a card at the realtor's office and walk out with the keys to a house.

Bitcoin isn't much different.  A zero-confirmation transaction is enough for a barista to hand you a cup of coffee, but not enough for someone to let you drive off with a new car.  For that, they would make you wait for at least one confirmation (about 10 minutes with a proper fee) or for 6 confirmations (60 minutes with a proper fee).  I should point out that this is still much faster than traditional financing in these situations.

Once even a single confirmation has occurred, it will now cost you a non-negligible amount of money in hashing power to reverse the transaction.  Every new confirmation compounds that amount.  In other words, unless the transaction is extremely large (think government budget sized), you would be losing money by attempting the fraud...and it wouldn't even be guaranteed to work.

In short, your own incentives prevent you from attempting fraud.


Bitcoin core and transaction fees I'm using combination of 'createrawtransaction' and 'fundrawtransaction' API calls to create my transactions. I don't pass 'feeRate' option to 'fundrawtransaction' and rely on bitcoin wallet to figure out the fee. Is this a good strategy for mission critical system like payment system or I have to manually estimate transaction fees and not rely on functionality provided by bitcoin core?

As far as I understand if fee is too low for a network conditions then transaction may stuck in the mempool of some nodes. Even worse it may be expelled from some nodes while still remain in others. Is there any way to cancel such transaction and make sure no miner will ever pick it up? If not then what are my options when dealing with stuck transactions?

Is there any way to cancel such transaction and make sure no miner will ever pick it up?

No

  If not then what are my options when dealing with stuck transactions?

Use replace by fee (RBF)?


Start cgminer only on the second card HOW? I have two video cards. My main card is a nvidia 650ti and my second is an AMD R9 280x. My monitor is connected to the nvidia and I use it for normal things. I want to start cgminer only on my second card - the AMD R9 280x. I tried with cgminer -d1 but it says:

ADL found less devices than opencl!
There is possibly more than one display attached to a GPU
Use the gpu map feature to reliably map OpenCL to ADL
WARNING: Number of OpenCL and ADL devices did not match!
Hardware monitoring may NOT match up with devices!

I saw that there is this command:

--gpu-map <arg> - Map OpenCL to ADL device order manually, paired CSV (e.g. 1:0,2:1 maps OpenCL 1 to ADL 0, 2 to 1)

I have tried it but I don't know exactly what arguments to use and it does not work.

How can I use the command to start cgminer only for my second card?

to maps gpus i use this script:

cgminer -n option

Timeout /t 3600

Make it a .bat file and put it in the same folder as you cgminer, then you can tell witch gpu that is 0,1,2...

but you have to turn off power saving in windows to prevent you 280x form sleep, if you don't have a dummy-plug or an screen put to that device.

I used this guide for all start up information's: http://www.cryptobadger.com/build-your-own-litecoin-mining-rig/

Regards

EDIT: and when you use the -d command remember to have a space before the number.


Adding watch-only addresses to Blockchain.info through an API? I want to set up a service to monitor the activity of various watch-only addresses. I know Blockchain.info offers an option to do URL callback notifications when a payment is made to an address in their wallet and I know you can add a watch-only address to their wallet by hand, but I can't seem to find an API call to be able to accomplish that. Is it possible to add watch-only addresses to Blockchain.info through an API call?

It seems that Blockchain.info, among others, is compliant to the bitcoin JSON RPC API. That given, you can use the most common programming languages to access your wallet, last but not least the simple bitcoin-cli command, from the original bitcoin distribution:

$ bitcoin-cli -rpcconnect=rpc.blockchain.info -rpcport=443 -rpcssl -rpcuser=YourWalletIdentifier -rpcpassword=YourPassword getinfo

-rpcconnect=rpc.blockchain.info will instruct bitcoin-cli to connect to blockchain.info's RPC interface; -rpcport=443 specifies the remote port; -rpcssl needs to require a SSL connection; -rpcuser and -rpcpassword speak for themselves.

The last word, getinfo, is the command itself.

In your case, it should be something like:

importaddress <bitcoinaddress> "" false

where importaddress is the command (or method) which instructs the wallet to include the <bitcoinaddress> in the wallet itself. Since you don't specify the private key of the address, but just the address itself, it will become a "watch address" inside your wallet: you will be able to track its status but not to broadcast transactions which involves it. The couple of double quotes "" can be replaced with the wallet's name, if you set one. false is a boolean value which instructs the bitcoin engine not to rescan the whole blockchain looking for transactions which involves the address you are adding. I am not a blockchain.info customer, so I don't know the effects of this particular flag. I believe that it is ok to set it true, since blockchain.info scans the blockchain in real time.


What economic incentives would help wider geographic distribution of bitcoin nodes? https://bitnodes.21.co/

Full nodes are important everywhere providing visibility and improved network latency. In areas where bitcoin mining is not profitable due to the high cost electricity or other factors what incentives can be used to increase the number of nodes?

Will 21.co be successful in its efforts to install mining equipment in mobile phones and other consumer devices across the world?

No incentives to run nodes are required. As people in these countries are presented with more use cases to use bitcoin, organic growth in the number of nodes will follow.

International money transfers and a superior alternative to M-Pesa for retail transactions are both attractive areas for growth in some of the areas with limited node counts today.


Converting xpub key to core format I am experiencing some major issues which I honestly can't understand.
When I am generating a wallet from Electrum the public key looks like this: xpub661MyMwAqRbcG8Zah6TcX3QpP5yJApaXcyLK8CJcZkuYjczivsHxVL5qm9cw8BYLYehgFeddK5WrxhntpcvqJKTVg96dUVL9P7hZ7Kcvqvd

When I am generating a wallet address from bitcoin core rpc, the public key looks like this: 037acd3408dfb612a69204c5f5bafe2a326646398cdd16c85fedd65a4e96a28278

When I am trying to create a multisig address in the core using this type of public keys, I get errror: xpub661MyMwAqRbcG8Zah6TcX3QpP5yJApaXcyLK8CJcZkuYjczivsHxVL5qm9cw8BYLYehgFeddK5WrxhntpcvqJKTVg96dUVL9P7hZ7Kcvqvd

When I am trying to create a multisig address in the core ( via PHP ) using this type of public keys, it works: 037acd3408dfb612a69204c5f5bafe2a326646398cdd16c85fedd65a4e96a28278

I am super confused.

I am developing a multisig system for bitcoin, but it seems that I can't do it, since the clients will almost always use this type of public key generated from Electrum: xpub661MyMwAqRbcG8Zah6TcX3QpP5yJApaXcyLK8CJcZkuYjczivsHxVL5qm9cw8BYLYehgFeddK5WrxhntpcvqJKTVg96dUVL9P7hZ7Kcvqvd

Is there any type of conversion way in PHP from this type of public key:  xpub661MyMwAqRbcG8Zah6TcX3QpP5yJApaXcyLK8CJcZkuYjczivsHxVL5qm9cw8BYLYehgFeddK5WrxhntpcvqJKTVg96dUVL9P7hZ7Kcvqvd to this type: 037acd3408dfb612a69204c5f5bafe2a326646398cdd16c85fedd65a4e96a28278 ?
I am trying to understand what I am doing wrong

Thank you for your time, and hope to get an answer!

The electrum public key xpub661MyMwAqRbcG8Zah6TcX3QpP5yJApaXcyLK8CJcZkuYjczivsHxVL5qm9cw8BYLYehgFeddK5WrxhntpcvqJKTVg96dUVL9P7hZ7Kcvqvd is a BIP32 extended public key. This can be used to derive child addresses.

The Bitcoin-Core public key 037acd3408dfb612a69204c5f5bafe2a326646398cdd16c85fedd65a4e96a28278 is a hex representation of the compressed form of a public key.

In order to convert to from the extended to compressed format, all you need to do is decode from Base58Check and grab the last 33 bytes (32 for private keys). I'm sure there's an implementation in PHP for Base58Check decoding. See BIP32 - Extended Key Serialization:

$ printf "xpub661MyMwAqRbcG8Zah6TcX3QpP5yJApaXcyLK8CJcZkuYjczivsHxVL5qm9cw8BYLYehgFeddK5WrxhntpcvqJKTVg96dUVL9P7hZ7Kcvqvd" | base58 -dc | xxd -p 0488b21e0000000000000000009f8b20f34eceef6ea60d35db00446763f7 dc76bd60ec8cf6fd63dc912499cbd4039edccce0e93f436a283947412378 8b33a28ed7ad7cffc3a130889f232344ad1c

The last 33 bytes represent the hex version of the compressed public key (last 32 bytes for private keys).

039edccce0e93f436a2839474123788b33a28ed7ad7cffc3a130889f232344ad1c