There is a bitcoin-cli available for OSX. I also ran into this issue, and it is because I missed one of the setup steps. Here they are for posterity!

Install Xcode:

$ xcode-select --install

Install Homebrew =>
 https://brew.sh/

Clone the repo:

$ git clone https://github.com/bitcoin/bitcoin.git

Navigate into bitcoin directory, and run the autogen script:

$ cd bitcoin
$ ./autogen.sh

  The autogen.sh script creates a set of automatic configuration scripts
  that will interrogate your system to discover the correct settings and
  ensure you have all the necessary libraries to compile the code.

Run the configure script:

$ ./configure

  This will automatically discover all the necessary libraries and
  create a customized build script for your system.
  If all went well, the configure command will end by creating the
  customized build scripts that will allow us to compile bitcoind.

Compile the bitcoin source:

$ make

Install the executables on your system:

$ sudo make install

Default install location of bitcoind is /usr/local/bin.
Confirm Bitcoin Core is installed:

$ which bitcoind
/usr/local/bin/bitcoind

$ which bitcoin-cli
/usr/local/bin/bitcoin-cli

Full disclosure this information worked for me, and it is from Andreas M. Antonopoulos' Mastering Bitcoin book!


From my own experience, running ABCore on a Nexus 5X, Android is too eager to kill processes that use a large amount of memory on systems with less than 3 GB.


salvagewallet is not in the Bitcoin Core Console

-salvagewallet is not a command that is run from the debug console. It is not one of Bitcoin Core's RPC calls. Rather -salvagewallet is a command line option. You set it in the command that is used to run Bitcoin Core or you set it in the bitcoin.conf file by adding salvagewallet=1 to the bitcoin.conf file and then starting Bitcoin Core.

Note that -salvagewallet does not always work and sometimes may result in corruption of your wallet if it is not already corrupted. It is only as a last resort option. You should always make a backup of your wallet file prior to starting Bitcoin Core with -salvagewallet.


Why does Bitcoin need transaction fees prior to hitting its maximum coin limit?

One reason behind a transactions fees is to make spam attacks expensive.
Without fees, a malicious party could create a lot of no-fee transactions for a DoS attack on blockspace. And without fees a miner wouldn't be incentivised to include the highest fee transactions in a block. He could attack the network by mining empty blocks or including spam transactions. (e.g. transactions with clearly and solely exist to bloat the UTXO-set or to fill up blocks).

And correct - with a high enough transaction fee some people in e.g. third world country's can't pay for the transaction. However enabling users to select a transaction fee is necessary. A user that doesn't need fast confirmations can pay a lower fee than a user with a need for an instant confirmation. Thus a fee-market can develop.

This might be an interesting read regarding this topic:
The Fee Market Explained by Jimmy Song


Maybe the client is having a hard time finding peers.  If you close it and remove the addr.dat then restart, it will go through the dnsseed process again.

http://en.bitcoin.it/wiki/Data_directory


What does "16: mandatory-script-verify-flag-failed (Non-canonical DER signature)" error mean?

What can this error mean?

This error can only mean that this function returned false:

bool static IsValidSignatureEncoding(const std::vector<unsigned char> &sig) {

When does this function return true? When all of these conditions are satisfied:

/**
 * A canonical signature exists of: <30> <total len> <02> <len R> <R> <02> <len S> <S> <hashtype>
 * Where R and S are not negative (their first byte has its highest bit not set), and not
 * excessively padded (do not start with a 0 byte, unless an otherwise negative number follows,
 * in which case a single 0 byte is necessary and even required).

How are you generating your signature?


Did BitGo terminate its "BitGO instant" service? Why?

I can't say for sure, as I don't use the service, but the current page appears to be here: https://www.bitgo.com/info/solutions#instant .  It's linked in the Solutions menu on the header of every page, so they're not hiding it.


What are recourse or non-recourse transactions?

Recourse is a term used in general terms to refer to things being made right.

If I kick a ball and the ball breaks my neighbor's window, my neighbor can insist that I make things right -- such as paying for the replacement cost.  If I don't, there are a number of approaches that can help make it so that I'll make things right, including posting a note on the mailbox sharing with my neighbors my action and response.  So in that scenario, my neighbor has some degree of recourse and I'll likely make things right.

When a person borrows money to buy titled property and there is a lienholder, the ability to foreclose / repossess the property is among the methods of recourse available to the lender.

When I order an item from someone on eBay and instead of my item arriving I get only an empty box, I can simply contact my credit card company to file a dispute and have the charges reversed.  That is my recourse.

With Bitcoin transactions, once they have confirmed it can be presumed they will never be reversed.  If in the example above with eBay, but instead where you had paid with bitcoins, there is little recourse available to you.  eBay might let you enter a negative in the seller's history, but they won't be able to reverse your payment.

So when accepting bitcoins for payment after seeing the transaction's status with 0/unconfirmed there is no guarantee yet that you'll receive the funds.   If you hand over cash to someone who you don't know, there's little you can do if the payment transaction to you gets double spent and your transaction never confirms.  Even if you know who the person is, there's likely very little you can do to get the bitcoins you were expecting from the transaction that never confirmed.  So that's why 0/unconfirmed transactions carry risk -- as they are not guaranteed and bitcoin offers no recourse if you do get scammed.

If you use an escrow party, at least then the recourse to scamming is the possibility that the escrow will not deliver the funds to the scammer.  Escrow provides some level of recourse for transactions where little existed.


What are the biggest motivations for common people to adopt crypto currencies?

One of the benefits of cryptocurrencies that I recently heard at a Bitcoin Meetup that seemed very promising was how they lower the cost of remittances. I've heard remittances be defined as the act of returning a payment you previously accepted, and as the act of sending money across borders such as when immigrant workers earning income outside of their home country try to send money they earned back to their home country. The first definition of remittance benefits from cryptocurrencies because the Bitcoin protocol allows you to program money. Just like web technologies like HTML, CSS, and Javascript allow you to program the information that flows through the web, Bitcoin allows you to program how money flows through a financial system (whether that system be your immediate family, a school system, or a nation). If one could automate the return of payments when certain conditions are met, then much of the accounting apparatus that exists would not be needed. This is difficult to do, though. For instance, If you were a merchant that sold radios and you wanted to guarantee customers that they could return a radio they bought if the transmitter didn't work, how can you programmatically instruct 0.1 BTC to be sent to the customer when their transmitter breaks? You could write broken-transmitter recognition software, but then your remittance system is only as good as your recognition software. Nevertheless, the Bitcoin protocol let's the common person who has the necessary programming skills automate this general type  of service.

With regards to the second type of remittance, since the bitcoin network is made up of a bunch of connected nodes that exist all over the world, a computer with internet access is all someone from a migrant-worker-sending country would need to receive bitcoins from a family member working abroad. The industry for this type of remittance is in the 10's of billions, so people are waiting for the regulatory environment to become a little bit clearer before implementing services that do this sort of thing.

In general I think bitcoin makes more sense for citizens in a developing country who don't have trusted organizations like exist in developed countries. If you live in a place where the government can arbitrarily freeze your bank accounts which holds your life savings, then Bitcoin offer the common person the ability to store their money in a trustless system where nobody can seize their value. Unless of course you divulge your private keys, or they physically come to your home and demand you give them your private keys.


No it is not predictable. If it was that would break how block discovery works.

To explain in very broad terms: a nonce is simply an incrementing number. It is combined with a random set of as yet unconfirmed transactions and passed through a simple hashing algorithm, which turns it into a long number called a hash.

It's this answer (the hash) that has to match the test : it needs to begin with a certain number of zeros for the block of transactions to have been considered "discovered", and hence confirmed.

If it does not match this test, the nonce is incremented by and the process begins again.

It is the fact that the number and content of the transactions combined with the nonce supplies the essential unpredictability of the process, meaning that ultimately nobody can say which miner will find the block.

As this is quite a heavy computing task (to continuously try new nonces and transactions until you find the block) the nonce also serves another purpose : to help other bitcoin nodes take a shortcut to check if the block you claim you discovered is correct. They simply need to take all the transactions in the block (you have to tell them which ones) and use the nonce to arrive at the correct Hash with the right number of zeros. This by contrast is a very light computing task.


Bitcoin-QT with standard settings will keep 100 unused addresses in your wallet at all times. The goal is that backups will be future proof to some extent.

A key pool allows to create backups in bigger intervals

Every time you create a transaction, the remainder of the input balance is sent to a new address in your own wallet. If addresses were generated only then, you would have to create a new backup after each transaction, or be at risk to lose any funds associated with that new address if your wallet got lost. By keeping a pool of unused addresses in store, your backup will be sufficient for the next 100 transactions before you will be at risk of losing something.

To create a bigger key pool, with e.g. 10000 keys, the client can be started with the parameter -keypool=10000.

I don't have intimate knowledge of either multibit or electrum, but suspect that they keep a key pool for the exact same reason.

One vs. many addresses

Using many addresses, i.e. a new address for each transaction,

increases your privacy by making it harder to determine that your different transactions belong to the same person.
obfuscate which part of your transaction went to the recipient and which was the change.
create plausible deniability as sending funds to yourself looks the same as sending to another user.
By giving out a new address for each incoming payment, it is easier associate payments to specific senders. Say, you go out with a three business partners and each ends up owing you 0.10 BTC. How would you know who paid already, if you only received two payments to the same address?

Using only one address

allows your backup to last forever
reduces the overhead if people send funds to you more than once.
Your privacy, and the privacy of your business partners might be reduced.


Will I pay BID price or lowest necessary amount?

First account gets nothing.

Second account buys them starting from the lowest offer, going up.

Such as, there are sells:

0.30 units @ a price of 100
0.10 @ 150
0.40 @ 650
0.80 @ 850
1.00 @ 1000 (your first offer)

You post a limit order to buy 1.00 unit @ a maximum price of 1000, you get:

0.30 @ 100 (total spent 30)
0.10 @ 150 (total 45)
0.40 @ 650 (total 305)
0.20 @ 850 (total 475)

You got the amount requested (1.00 units), spending 475 instead of 1000 (the maximum you were willing to spend).

The new market depth will be:

0.60 @ 850
1.00 @ 1000 (your first offer)


Security and recover issues in blockchain.info wallet

(1) what should I do in order to save my bitcoins if something happens
  to blockchain.info. Can I access to my bitcoin with ANY wallet, if I
  know my address and private key, or if I know my address and password?
  if so, how do I find my private key?

You should backup your wallet, using one or more of the options blockchain.info provides.

  (2) I've also noticed a backup option in blockchain.info wallet. If I
  use it, can I get access to my bitcoins with this backup, with every
  wallet? should I save a new backup after every transmission of
  bitcoins from my blockchain.info wallet?

With wallets that are compatible with the format, such as Multibit, yes. I think it's safe to say that there'll always be some tool on the Internet you can use to read the file, but downloading the Multibit client (even if you don't plan to use it right now) wouldn't hurt.

As for how often to backup, I'm unsure of blockchain.info's setup...if you only have one address, then you only have one private key, and you don't need to rebackup. If you have multiple addresses, then you need to backup periodically or even after every transaction. You can see if the backup file is any different to see if you actually needed a different export.

Blockchain.info has the following instructions for accessing your backup, even if blockchain.info is permanently offline:

  Download the Multibit desktop client available for Windows, Mac OSX
  and Linux.
  Launch the application. Choose Tools -> Import Private
  Keys.
  Click the "Choose Import File" button and navigate to your
  wallet.aes.json file. Change the file format to *.aes.json and open
  the file.
  Enter the wallet password and press unlock. If required
  enter the second password and press unlock again.
  Click The Import
  Private Keys Button to complete the process. Your balance will be
  restored once the blockchain has downloaded.

  (3) Wha'ts the best way to prevent a situation where a malware "reads"
  my password when I enter it?

Make sure there's no such malware when you enter your password. One way to be sure this is true, is to work from an offline Linux Live CD. E.g. see How to set up a secure offline savings wallet and/or bitBuntu. You can decide for yourself, based on how likely you think it is that you're infected and how much money you're dealing with, whether that's worth the trouble to you.


It is resolved.

block_array: List = list()
block_array.append(struct.pack('<L', block['version']))
block_array.append(bytes.fromhex(block['prev_block_hash'])[::-1])
block_array.append(bytes.fromhex(block['merkle_root'])[::-1])
block_array.append(struct.pack("<L", block['height']))  # 632295
block_array.append(bytes.fromhex(block['reserved']))  # 0
block_array.append(struct.pack("<L", block['timestamp']))
block_array.append(struct.pack("<L", block['bits']))
block_array.append(bytes.fromhex(block['nonce'])[::-1])
block_array.append(bytes.fromhex(block['solution'])[::-1])

header_hex: bytes = bytes.join(b'', block_array)
hash = double_sha256(header_hex)

Fun

def double_sha256(bytes_str: bytes):
    result = sha256(sha256(bytes_str).digest()).digest()
    return result[::-1]  # little endian


I would advise not giving anyone direct access to your bitcoind instance. You need either a queue/ or an API in between that can throttle requests/ and manage ACL's as you require.


You can download the icons from the source repo at https://github.com/bitcoin/bitcoin/tree/master/share/pixmaps.


What is the current status of Multi-Sign function in bitcoin network?

This topic has gotten a lot of traction recently, with new implementations continually popping out.

For example, there's a really nice standalone HTML5 app with slick interface called Copay, developed by Bitpay. There's also an online service BitGo (haven't tried this one though).


What is the "certain criteria" to be a valid Bitcoin block?

A valid block is found when any miner authors a block candidate whose block hash interpreted as a number is lower than the target. This is equivalent to meeting or surpassing the required difficulty.

To this end, miners create templates of a block that they would like to confirm by selecting a set of transactions and creating their unique coinbase transaction to collect the block reward. Each block template can be tried a number of times by cycling through all possible values of the arbitrarily picked nonce in the block header. After that, the template can be slightly adapted e.g. by changing the block time in the header, by incrementing the extranonce in the coinbase transaction or introducing any other change into the block template.


Can one rig run multiple different graphics cards?

Nope, you're good to go. You don't even have to connect them all through PCI-e. With cgminer, you can set the settings uniquely for each card. You can use any kind of adapter that would normally bottleneck GPU performance.


How would the network respond to an ability to crack the private keys?

This would be a global issue, not just Bitcoin related

If someone discovered how to extract the private key from an arbitrary ECDSA public key in an economically viable timeframe, then there would be serious ramifications for many other economies that depend upon that branch of mathematics. For example, international banking, secure data transmission and many other users of cryptography would need to manage the change so it would not just lie on the Bitcoin community to save it.

That said, the response would depend on the nature of the attack. It may be that the attack could be easily mitigated by constantly changing private keys in which case a fairly minor update could be built into the various clients to support this.

If the problem was with the choice of cryptographic algorithm then work would have to take place to find an appropriate replacement that was not subject to the given attack vector, and then to apply that to protecting the integrity of the transactions taking place through the blockchain.

From a community point of view, there is already a process in place to manage these kinds of responses (see BIP) which has had several successful uses when critical bugs or attacks have been uncovered.


What stops a miner from including arbitrary transactions in their block?

This isn't possible because every node in the network enforces the consensus rules.

A miner is only allowed to include 1 transaction that moves coins with no previous inputs, which is the coinbase transaction. The output value of the coinbase transaction must not exceed the block reward plus any transaction fees from transactions in that block. If the value exceeds this amount, the block will be rejected by the network, and the miner loses the work they did to create it.

If the miner includes the "Alice sent me 100 bitcoin" tx by using previous outputs from Alice as inputs, they must be part of a valid transaction. That is to say, Alice must have signed those inputs to prove that she wants the BTC to be spent. If the miner includes them as unsigned inputs, the transaction is invalid, and any block they create including it is also invalid.


How are fees charged?
They are charged in the currency fee set during a trade.

Due to a discreet nature of trade matching process, it's rather tricky to give a definite answer on how each individual fee is applied. However, a good rule of thumb is to choose a fee currency when placing an order, as this is the one in which fee will be subtracted.

Are the fees applied separately from my account's balance? Or are they included in trade costs?
Usually the former is the case - but the latter can occur under certain circumstances:

Normally, fees are NOT included in a trade and are subtracted from the remaining account balance.
However, if you quote your order in a chosen fee currency (for example, you Buy 500 EUR worth of XBT in XBT/EUR pair), then fee will be included in an order*.

*This means: if your account's balance is 500€, you'll be able to buy bitcoins worth 500€ minus transaction fees.
Can I set the currency I want my fees to be charged in? Can I choose to be always charged in a single Currency?
Yes to the first, no to the second.

Fees can be chosen to get applied in either quote or base currency. So if you're trading LTC/XBT, then it's either XBT or LTC. If, however, you're trading XBT/USD, it's either XBT or USD.

All quotes taken from the Kraken Support Ticket.
Cheers!


Good question! There are two concepts here. The finite field Fp, and the EC Group defined by secp256k1.

In Fp, elements are just numbers modulo p. Addition, Subtraction, Multiplication, and Division are all defined for this finite field.

In the EC Group, however, each element is a pair of elements in Fp, such as (f1, f2). You can add and subtract these pairs to get different pairs, but the addition and subtraction has little to do with the addition and subtraction of elements of Fp (technically it uses those operations under the hood, but it's not direct addition. That would be pretty boring if (f1, f2) + (g1, g2) just gave you (f1+g1, f2+g2)).

Also note that since these pairs are a mathematical Group, rather than a field, there's no way to multiply two pairs. You may have seen the syntax k*G before, but this is just shorthand for adding G to itself k times, k is an integer rather than another element of the EC Group defined by secp256k1.

Additionally, if you look at the ECDSA algorithm, you will see that here the final elements are (r, s), but just because it is a pair does not mean it is a pair that lives on the secp256k1 curve! This is a pair of integers mod n (the curve order), as defined by the algorithm, not a point on the curve.


If you're looking for something technically straight-forward, I suggest using an "e-wallet" and giving your partner access to the wallet account.

Review these links:
https://en.bitcoin.it/wiki/Browser-based_wallet

And here are several e-wallet's listed:
https://en.bitcoin.it/wiki/Category:EWallets


How to find my transaction from root of Merkle Tree

First of all, you need to use gettxoutproof

$ bitcoin-cli help gettxoutproof
gettxoutproof ["txid",...] ( "blockhash" )

Returns a hex-encoded proof that "txid" was included in a block.
...

you receive data including your transaction id with another txids (privacy purpose).
then you need create empty merkle tree and place txids inside leafs, check this link to know how you can do it. You need to work even with little and big endian

After that you have to concat leafs and do SHA256 twice until the merkle root.


What can be done with a bitcoin besides exchanging it for goods or services?

A Bitcoin can be used to permanently trace the association between different public keys.  For example a user can send a transaction to a second user and publicly and permanently link the accounts.  This may have utility in Web Of Trust scenarios.
The low value bits of an individual bitcoin can cheaply store metadata.
Saving them as a collectors item
Sharing (p2p style) a small amount of data


Connect to regnet from my WalletAppKit Android app

If you're connecting to a bitcoind regtest node and you're trying to connect as an RPC client to it via bitcoinj, it's possible.

Figure out what your Android's IP address is, say x.y.z.w and use the -rpcallowip parameter in bitcoind to allow your (remote) Android app to talk to the regtest bitcoind node.

Spawn bitcoind like this, for example:

bitcoind -debug=1 -printtoconsole -server \
    -regtest -listen -rpcport=8332        \
    -rpcuser=yourrpcuser -rpcpassword=yourrpcpass -rpcallowip=18.138.5.97

WARNING: Security-wise, keep in mind that the RPC password is transmitted over the network in plaintext.


C# code for Bitcoin Cash address conversion between legacy and new format

Just found a SharpCashAddr library.
Has pure C# implementation of address conversion in both ways.


The block files are indexed (the blocks/index subdirectory), and if you just delete the index, bitcoind will assume you have no blocks and start over downloading from the network.

You could instead have used the -reindex option to scan for blocks on disk and rebuild the index. This may still work, but likely won't as you've already started downloading again, and overwriting the existing block files.


It is not possible to determine if multiple addresses belong to one wallet, whether it is a deterministic wallet or not.

At best, you can do some form of chain analysis that traces UTXOs back along the chain until you find a common root. For most transactions in a single wallet, there will usually be a convergence point of the coins. However, this is not an exact science, and the results may not be of a high enough confidence to be certain it is happening.

Similarly, you can trace the future spending of the outputs created to see if they converge into a single address. If so, it may indicate the same person was selling/buying items.


Could many large forks cause a DoS attack on the miner?

If you mean a miner as in a computer that only does mining, it should be generally as resistant to DOS attacks as any casual computer on the network - it doesn't open its ports.

If you are worried about a standard client being flooded with many blocks and having to store it - the developers did think of that and they put in the checkpoint system. Basically, making a lot of forks of the new blocks would require a lot of computational power and so forth, so it is highly unlikely. However, changing some of the earliest blocks in existence would be dirt cheap nowadays. However, the standard client will not accept any block chain forks that branch out from blocks older than the most recent checkpoint.


Why does Bitcoin Core mention "Coinbase transactions", and what are they?

Coinbase transactions are the coin generation transaction of a block. They are the first transaction in a block. These are special transactions which do not spend any UTXOs and only create UTXOs "out of thin air". Hence UTXOs created by coinbase transactions are categorized as "generate".
Coinbase transactions are completely unrelated to the exchange named Coinbase. They named themselves after these special transactions.
UTXOs created by a coinbase transaction cannot be spent until they have more than 100 confirmations. This is known as the coinbase maturity period. While there are less than or equal to 100 confirmations, the transaction is considered to be "immature". Once there are more than 100 confirmations, the transaction and its UTXOs are considered to be "mature".
The reason there is a maturity requirement is because sometimes blocks do not become part of the main chain. These are referred to as stale or orphan blocks. To avoid issues where a transaction spends a UTXO from a coinbase of a stale block, the consensus rules require that enough blocks have been mined on top of the block with that coinase transaction such that it is extremely unlikely to be reorged out of the main chain. But for the coinbase transactions that are part of stale blocks, they are categorized as "orphan".


Understanding Transactions, Mining, and the 10 minutes block solved

How do miners decide how many transactions they should have in a block in order to mine 1 bitcoin?

The amount of work miners do has no impact on the amount of Bitcoin they make. The block subsidy is a fixed amount, and transaction fees are determined from transactions. Mining 1 Bitcoin does not require some specific amount of work.
Miners determine how many transaction they should have by determining how much in transaction fees they stand to gain from including those transactions. This is typically done by ordering all known unconfirmed transactions by their fee rate. Then the miner just includes as many transactions that is allowed by the consensus rules, starting from the transaction with the highest transaction fees.

When miners compete to find the "nonce" that has the smallest possible hash number, would it be faster/easier to find the "nonce" if there are fewer transactions?

No. The number of transactions has no significant effect on the difficulty of a block or the amount of work required to mine a block. While including more transaction nominally requires computing more hashes, this is negligible in the grand scheme of things, especially since this calculation is only done once for a set of nonces and extraNonces.

Do all miners try to solve a solution where all the transactions should be the same in a single block and everyone's trying to compete to finding the nonce and hash?

Everyone chooses their own set of transactions to include. Everyone is making their own block, just each block points to the same parent block.

Or is it random, and its just whoever finds a hash the quickest, saves those transactions and adds it to the blockchain?

It is entirely random. It's however finds a block first and broadcasts it.

Also, I noticed looking at btc.com, there are blocks being mined less than 10 minutes back to back, I thought it needs to be 10 minutes to be mined?

The average time between blocks is 10 minutes, but that is an average, not a requirement. Blocks can be found in less than 10 minutes, or more than 10 minutes. The average block is ~10 minutes.


I add a block, but instead of claiming 6.25 bitcoins, I claim 50 bitcoins. Who is going to verify that my claim is wrong?

Every full node will validate every block and enforce that it adheres to the consensus rules. Such a block would be rejected, because it is invalid.
For example, the network rejected an invalid block in July 2019 when Antpool mined a block that claimed transaction fees but forgot to include the corresponding transactions.


Where does change go when making a transaction from funds imported from a paper wallet?

Great to see that you are learning about BTC.

A paper wallet contains all the necessary details which you require to access your BTC.
But the true purpose of a paper wallet is security. Once you create one paper wallet and transfer BTC to the address, unless the person get's the physical paper, there will be no way to steal it by hacking or any other way.

Now coming back to your question, there are two ways how you use a software for your paper wallet.

By importing
In this method, if you transfer your BTC as you say in your question, your paper wallet will remain the rest 1.5 BTC
By sweeping/transfer to software
In this method, your total BTC will be transferred from your paper wallet to software wallet. In this case, after your transaction, the software will contain your remaining amount.

Note: Some software uses change addresses, so even if you use any of the above method, the rest goes into the change address created by that software wallet rather than your paper wallet. This is for privacy concern and mainly depends on the software you choose.

Hope this answers your question.


Is Bitcoin suitable for fast transactions, eg in shops?

The time for when a block has been confirmed is the main issue that seems to arrise. The coffee shop problem (I want my coffee now but this may take 10 minutes to confirm payment)

The mobile reception issue could be resolved by allowing restricted open access with on-site wifi service

There are third party services which may help this very effectively (www.flexcoin.com)

Also SolidCoin offers 3 minute blocks and may be substantially more elegant if a third party service was chosen not to be used for small transactions.


How do people using thin clients know the correct merkle path of transactions they've sent without knowing the full block?

how do A and B know the correct merkle path without needing the entire block?

Many light-clients will sync to the longest chain of headers, under the assumption that other nodes on the network will be checking the full content of those blocks for validity. (Consider: if every node was a light-client, miners could include invalid transactions in blocks, and none of the light-clients would know it!)

By requesting the intermediate states of the merkle tree from a node that has the full block, a light-client can verify that a transaction the user is interested in is indeed included in a block that is part of the longest chain, in a more efficient manner than validating the entirety of the block themselves (the caveat being the assumption of validity mentioned above).

  Do they need a centralized provider that processes the blocks to calculate these for them? Is it possible to do in a decentralized way?

This entirely depends on the implementation. Some light-wallets might just call back to a certain server, operated by the wallet's developers, for example. Other light-clients might attempt to pull this information from random nodes on the network. Some are even built to connect to your own node.

Ultimately, the highest level of certainty will come from running a fully-validating node yourself (ie, a full node). As bitcoiners like to say: don't trust, verify.


Why can't Bitcoin transactions be stopped like SWIFT transfers?

A transaction that steals money looks exactly the same as a transaction that sends money from one person to another. They are exactly the same thing, just that the person who initiated the transactions are different. The Bitcoin network does not know and cannot distinguish between a theft transaction and a normal transaction since they are exactly identical. Furthermore, the idea of identities don't really exist; there is no way to identify that an address is a thief's just by looking at the blockchain alone (which is all that nodes have access to).

Because the transaction is perfectly valid and no one except for the owner of the wallet and the thief know that the transaction was actually one that stole Bitcoin, the transaction will be propagated through the Bitcoin network by full nodes and included in blocks by miners. There is no central authority that can issue a stop nor is there a way for anyone else to know that a transaction pertains to a theft.


Using Ripple for assets accounting, loans, deposits, stock exchange, etc

Ripple has a contract system under development. This will allow people to bind Ripple assets or accounts to a set of rules. This should be usable for most of the things mentioned in your question.

Loans, ideally, would be done just as negative balances on a pathway.


Accepting Donations For Your Charity In BITCOIN

Try to use btcpayserver. Fully non-custodial bitcoin payment processor.


How do transaction volume and block reward relate?

Yes, the miner gets 25BTC regardless of the value of the bitcoins in the block. And yes, if blocks were all that small the economics would not make sense at all, but they are not that small, they are almost always much larger. Still, 25BTC per block works out at around $10 per transaction processed at the moment. Which is still an interesting number and is presently funded by the continuing investment flowing into the Bitcoin economy.


Can SegWit block weight be increased without a hard fork?

The explicit block weight limit cannot be changed without a hard fork.


Newbie question about the security of mixing

Technically the others nodes you are connected to would see you sending the transaction to them but they wouldn’t know if it is your transaction or someone else’s and you are just relaying it.
There might be a scenario where someone has strategically placed lots and lots of nodes into the network and monitors when certain transactions arrive to each of them and might be able to narrow down where the transaction originally came from to a small set of nodes.
Using TOR would limit this potential deanonymization by obfuscating your IP (which is the identifying piece of info)


What is the size and weight of a P2WPKH input?

TL;DR:
A P2WPKH input should be conservatively estimated with 68.0 vbytes. Standard P2WPKH inputs generally weigh 67.75 or 68.0 vbytes, depending on whether the r-value in the signature is low or high. A wallet using signature grinding (which is highly recommended) will always produce 67.75 vbyte inputs. 68.0 vbytes is the conservative estimate allowing for high-r signatures.
Composition of a P2WPKH input
Each input commits to spending a specific UTXO by providing its transaction outpoint:
PREVOUT: hash (32 bytes)
         index (4 bytes)

The scriptsig for a P2WPKH input is empty, however, the scriptsig length must be provided as 0:
SCRIPTSIG: length (1 byte)
  <no content>

Each transaction input has its own sequence number:
sequence (4 bytes)

A P2WPKH input requires a witness in the transaction's witness block:
WITNESS: item count (1 byte)
  signature length (1 byte)
  signature (71 or 72 bytes)¹
  pubkey length (1 byte)
  pubkey (33 bytes)

Conservative weight, vsize, and size estimate
A P2WPKH transaction input adds to a transactions…
weight:
4 × (32 + 4 + 1 + 4) + 1 + 1 + 72 + 1 + 33 = 272 WU

vsize:
32 + 4 + 1 + 4 + (1 + 1 + 72 + 1 + 33) / 4 = 68 vbytes

serialized byte length:
32 + 4 + 1 + 4 + 1 + 1 + 72 + 1 + 33 = 149 bytes

If the signing wallet uses signature grinding, the r-value is always 32 bytes, reducing the signature to 71 bytes and the above maxima to 271 WU, 67.75 vbytes, and 148 bytes respectively.
Note that using at least one segwit input adds 2 witness bytes to the transaction header, the witness marker and witness flag. Also, when there is at least one segwit input, the witness block must have a witness count item for every input, which must be provided as a 0x00 byte for non-segwit inputs.
The overall transaction elements of a segwit transaction therefore are:
version (4 bytes)
witness marker (1 WU)
witness flag (1 WU)
input count (1 byte)
  inputs (variable size)
output count (1 byte)
  outputs (variable size)
witness item counts (1 WU × input count)
  witnesses (variable weight)
locktime (4 bytes)

Mentioned for completeness, a P2WPKH input that has a non-standard signature with both high-s and high-r weighs 273 WU, 68.25 vbytes, and 150 bytes accordingly.

¹ also see What is the maximum size of a DER encoded ECDSA signature?.


Transaction was succesful. I just verified in blockexplorer https://blockexplorer.com/tx/254d1352749e9a18effecbd6d340479d75ca4500e2da8eda1a77f51634ee3f6f

Make sure you sent this to the correct address. If yes, then ask the recipient to check in a blockexplorer. That's enough.


Is there anything I can do to speed up the synchronization of litecoinj?

So after digging I got the solution, using this kit.setCheckpoints( new FileInputStream("checkpoints")); it was checking the file in the same package so to provide the exact path I have used
kit.setCheckpoints( ReadProperties.class.getClassLoader().getResourceAsStream("checkpoints"));


Transaction Malleability, How can I change signature?

Question 1) It says that when bob makes a transaction to alice, that transaction goes to bob's malicious node. then bob changes signature so that It still stays valid transaction. and After that, there's a chance that this transaction will take place quicker than the original transaction that some other nodes have in mempool. and BOb has a chance of getting double * amount that alice is intended to transfer.

No, Bob will not get double. He will see two transactions that conflict with each other. No additional coins are created or spent. It is just annoying and wallets do not handle these conflicting transactions very well.

  I'm curious what bob's malicious node change in a signature part that it still stays alice's signature and still valid? how is it possible?

The signature is malleable. An ECDSA signature is composed of two values, R and s. Due to how the signature verification algorithm works, it is possible to replace the s with it's negation (-s). -s is easily computable by a third party, so an attacker can compute -s, replace the s value with the inverse, and send the new transaction. Because the contents of the transaction are now different due to the replacement of s with -s, the transaction has a different id so is considered different. But it is still completely valid.

  QUestion 2) How does segwit work? I know scriptSig is deleted from transaction, but where is it saved?

Segwit defines a new transaction format which is an extension of the original transaction format. In this format, a new field is added that is known as scriptWitness. The scriptWitness is where the signatures go. For nodes that do not have segwit, they only receive transactions in the old format. They won't see the scriptWitness.

The signatures are not deleted from the transaction. They are just moved elsewhere.

  QUestion 3) if it's saved in blockchain still, then how is it a less size and how can block have more transactions than now?

Blocks are not actually physically smaller. The block size has increased without a hard fork.

What segwit also did was redefine the metric of block size from bytes to a new unit called weight. To calculate the weight of a block, you have to look at the transactions. Each byte of a transaction that is part of the original transaction format is counted as 4 weight units. Each byte that is part of the new segwit transaction format is 1 weight unit. The maximum number of weight units in a block is 4000000. The math works out such that an old node will not see a block with more than 1 MB of data (since they do not receive transaction in the new format).

So with this new definition of a weight unit, transactions without segwit have more weight units than transactions that use segwit. Thus transactions are "smaller" so more transactions can fit in a block.

  Question 4) They say signature part is saved as the merkle root hash. but how can a node check that specific signature is related to specific transaction?

The signature is not saved in the merkle root hash. You cannot save any data in a hash. The signatures are committed to in the merkle root hash. What that means is that the data that went into the merkle root hash includes the signatures. This makes it so that the signatures cannot be once the transactions are in a block. The reason that this needs to be done is because the merkle root is only over the txids, which the scriptWitnesses are not part of (they are ignored in the txid calculation). So the full transaction hash (known as the wtxid) is used in a witness merkle root which is included in the coinbase transaction. This results in that hash being part of the coinbase transaction's txid which goes into the merkle root of the block.


Wouldn't bitcoin benefit from distributing partial blockchains over each node?

Why doesn't each node store only a portion of the blockchain?

This has been proposed before and is possible with Bitcoin, but it's not clear how it would be executed. The blocks aren't an important part of a running node, for most people you can throw them out as soon as you have processed them into your UTXO database.

The problem comes when deciding which parts to store, and signalling to other people in the network that you have a certain subset of blocks. You can't advertise a list of hashes as that would be massive and inefficient (many megabytes for each peer), and making a deterministic random selection is extremely problematic. Choosing ranges of blocks is not ideal because the sizes are not consistent, 1,000 blocks at the beginning of the chain is servers orders of magnitude smaller than ones at the tip. In a naive implementation of random selections peers attempting to sync with the network may need to make thousands of connections to find a single peer that has a specific block, which is obviously not feasible.

  From my understanding of the blockchain, let's assume a particular node starts at the genesis block. Let's assume another node stores 1% of the blockchain past the genesis block. Couldn't multiple node verify block hashes for their shared 9% at a rate of once every 10 minutes? It wouldn't really use that much data -- you could hash the 9% of the blockchain to a particular value, produce a public key, and see if the other nodes can match a private key to said public key.

This is not necessary and highly vulnerable to Sybil attacks, you don't need to verify blocks once you have seen them. Pruned nodes work like this today, only they throw away every block and store absolutely nothing more than they are specified to sore. They don't advertise which blocks they have because there is no mechanism for that.

You might want to read up on how the autoprune patch works and get a better grasp on the threat models that need to be tackled here. You've missed some of the operation slightly, note that pruning for nodes nodes does not operate in the way described in the white paper, the UTXO is a newish concept added in 0.8.0 era Bitcoin Core.

  A related question: Is this what Electrum does?

Not at all, Electrum servers are a full node and an extremely heavy address based index, almost doubling the storage size. The client is light weight but the sever most definitely is not. There's no sensible way of maintaining these indexes in a sharded way, though you could break addresses into multiple pools and hope that people maintained enough of each shard for clients to be able to request subscriptions for all of their addresses. Ideally systems would be designed that don't require full indexes as they are getting increasingly unwieldy to work with.


Bitcoin Block Size - What are the rules?

The current maximum block size is 1MB (but it could be increased in the future with a protocol change), there is no minimum size per se, but the block needs to have all its components to be valid (check Protocol Specification). Each block needs to have at least one transaction - one paying the miner the reward for mining the block.


Is it possible to withdraw other cryptocurrencies besides bitcoin (ex: etherum) into a Bitcoin paper wallet?

It may work, depending on the currency.

You will likely be able to send BCH to a BTC paper wallet, and LTC to a BTC paper wallet with a 3-address, due to address format overlaps.

You will not be able to send currencies with other address formats, such as Ethereum, Monero, ZCash, etc.

Do note that even if you do succeed in sending the currency, there is no guarantee that you will be able to spend it. For example, sending BCH to a BTC segwit address will work, but spending it will be extremely hard, as segwit is not enabled on the BCH network.


How to connect to several Bitcoin nodes using Bitcoin

If you want to communicate with several nodes, you can use existing JSON RPC libraries and issue requests via the API. Check out these libraries:

JSON-RPC
python-jsonrpc


Are there already several ways to do "smart contracts" with cryptocurrencies?

There is Orisi.org - you can read the whitepaper here Orisi.org/distributed oracles whitepaper, and run an example Timelock contract here.

The differences between distributed oracles/Orisi and Ethereum are:

Orisi works on top of Bitcoin, so there are no other currencies inbetween
oracles can reference external inputs, so you can create a contract that finalizes based on weather/currency prices, or even mechanical turk
it's available today
on the other hand, it has a different trust mechanism than Ethereum - oracles are supposed to be run by trusted independent parties. So, instead of proof of work, you have a proof of identity.

You can also read this blogpost by one of the bitcoin core devs: bit-thereum. It explains why m of n oracles might be a good solution for contracts.


Could a large group of miners theoretically lower the network hashrate to manipulate difficulty?

The difficulty adjusts every 2016 blocks based on the average block time for all of those 2016 blocks. So just making the 2016th block take longer to mine has little effect on adjustment. A miner would have to manipulate block times for the entire 2016 block period to get any significant difficulty change.


Could Hadoop be used as a mining pool architecture?

Map Reduce isn't the best idea, because distributed mining is solved and works well.  The magic of mining is described here, and when that is complete that Bitcoin protocol allows for 25 new Bitcoins to be send to any address.  This is encapsulated into a block that is either accepted (and used as the "previous" block), or rejected, for example if the protocol rules are broken.

Your time is best spent running your own mining pool.


Setting wallet directory independent to data directory

I don't think you can make bitcoin core look for the wallet.dat file outside of the specified data directory, but I think you can make a symbolic link called wallet.dat in the data directory and have it connected to the actual file on another drive. You can find info on how to do that here:
http://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/


Does "fail the channel" mean unilateral close in BOLTS?


See https://nxtforum.org/testnet/public-testnet-node/ for a description how to setup a testnet node.


What is the maximum of receive addresses the default wallet can handle?

A while ago I created an extension for BitcoinLib in order to put bitcoind to the test. The setup was trivial: call getnewaddress() in the main network for ever

My performance index was the number of addresses generated per second.

It took off on an average of 35 addresses/sec. I left it running on a VM for a whole month. The rounded results were:

Total empty receiving addresses    Generated addresses/sec
 < 650,000                         35
 < 960,000                         32
 < 1,240,000                       29
 ...........                       ..
 <  75,000,000                     28

The most noticeable slowdown was from 700,000 to 1,300,000.

Restarting the test client from the 75,000,000 point didn't improve the newly generated addresses per second rate. Restarting the host didn't make any difference either.

I then sent 3 payments to that wallet and they showed up instantly.

I don't know how it would affect the wallet if there were transactions linked to each of the 75 million receiving addresses but it would be really interesting to see. One thing also to be tested is whether or not there are delays during the daemon initialization when the wallet contains such a big number of addresses.

If someone has a really fast spare machine I could share the testing code and we could get to the 100 million benchmark much faster than in a month. Freewil's testnet box could be useful for that test.

Also, some related questions:

Does the original Bitcoin client scale to contain millions of addresses?

How to handle a ridiculous amount of receiving addresses?


Bitstamp does not offer credit, so your balance can not go below zero.


Are mining pools evenly distributed across the planet?

Evenly distributed, no.

There are pools on nearly every continent.

But a pool only has the hashing power of the individual miners participating.  Miners can (and do) jump from one pool to another when connectivity issues occur, or when workload isn't received, or when payouts stop.

Individual miners are much more spread out. Areas with cheaper electricity got higher participation than areas with lower electricity, but now with ASICs that will probably not be as much of a factor for a couple years again.


Why do transactions with lower input age require higher fees?

There is no time difference to check old or new outputs, because the database of them (UTXO) is a HashTable. The reason to take obligatory fees from new funds is preventing useless transfers from one account to another wasting the blockchain and increasing its size without reasons.


Give your website address in Merchant Settings then check by clicking Test


Type and Amount of Transaction in Blockchain API

There is a better API, and it is the Bitcoin core API. You get all the data you require there. Blockchain.info must probably also be using the core API's (or they must have made a parser to parse the binary data of the blockchain on the machine running the full node). Using the core API's and the corresponding bindings present for various programming languages, you can access all the data from the blockchain you need.

There seems to be no txid field above but there's one tx_index which refers to that hex. You can get the number of BTC's in that transaction (input and output) by using the core api getrawtransaction(to access non-wallet transactions, you need to rebuild your blockchain after adding the line txindex=1 in the conf file and restarting the server with -reindex option)


How to connect my mining pool to another mining pool

Outsourcing to a larger pool is definitely possible and can help reduce variance. Conceptually, to them you're just a very large miner. On your side, instead of submitting a found block directly to the network, you submit it to the larger pool, and any shares you accept can be passed on the larger pool. (Regarding difficulty settings: Having different difficulty settings between your miners and the larger pool is find as long as the larger pool's difficulty does not exceed that of any of your miners. If that is the case, you must either bring down the difficulty of your miners or convince the larger pool operator to raise your difficulty (which they may very well agree to, since it reduces the load on their stratum).

For the actual implementation, I'd talk to someone who's done it before. TradeMyBit outsources its LTC and DOGE mining to MultiPool. I've talked to the owner merc before, and he seems like a nice guy. You could try contacting him here to see if he's willing to give you any tips.


Recover Electron wallet with bad seed phrase

Electrum used BIP 39 seeds for some time. So your seed may be a BIP 39 seed, in which case you will need to tell Electrum that you are importing a BIP 39 seed. When you are importing the seed, click the Options button and then check the checkbox for BIP 39 seed.


The proof-of-work is the fact that the hash of the block is a low number, when you interpret the hash as a long 256-bit number. If you change anything in the block then the hash changes and is very unlikely to be low enough (below the target), so the proof-of-work is gone. And quite right, you did not do any work to create that modified block.

So you can't modify the block after it is mined, which means you cannot change the bitcoin address that this block sends its miner income (new coins and transaction fees) to.

You cannot steal the miner income from a block after the block is mined.

However, if a mining pool server is insecure you could hack into it and make the mining pool mine blocks that pay your bitcoin address instead of their own.

You could also make individual miners in a pool mine for you instead of themselves. They wouldn't even need to have an insecure system. BGP routing attacks have been used to hijack miners before, making them connect to the hacker's server instead of the mining pool server they want to connect to. See https://www.wired.com/2014/08/isp-bitcoin-theft/ This could be mitigated by using TLS, just like web servers use TLS (https addresses).

So there are multiple ways to steal from miners, but doing something with a block that is already mined is not one of them.


Not sure what exactly you need to do once you have found your information as that can be a big drive in what tool you use as well. However you can use bitcoind api which is packaged with bitcoin-qt to get all infromation about a transaction using this command.

gettransaction <txid>

It will return to you all the infromation about that transaction, I would use some other tool build on top of it such as a php api or whatever your favorite language is. Here is one that I made to interact with it via PHP https://github.com/michaeljs1990/Bitcoin-PHP-API .

More about the bitcoind API can be found at https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list


What incentives do Crypto 2.0 systems provide for IOU Gateways?

Universal

In most if not all Crypto 2.0 systems, a Gateway can:

Charge the users for IOU deposits
Charge the users for IOU withdrawals

Ripple

In Ripple, a Gateway can set a percentage fee for whenever their IOU is transferred from one user to another. Say, at 1% fee, to send someone $100, one needs to spend $101. The recipient receives $100, while the Gateway's liabilities decrease by $1, giving them that much in profit.

Ethereum

In Ethereum, a Gateway can create an arbitrary contract for how its currency will be used. This contract can include any fee for currency being transferred or exchanged, demurrage, or anything else that can be coded in a smart contract.


Yes Monero mining pools generally use the Stratum protocol for communication between the pool and the miners. However a modified version of the Stratum protocol is used. I've yet find proper documentation like the one you've linked, so your best bet is to look through the source code for the exact definition.

Also there is a separate Stackexchange for the Monero community, so your likely to get even better help there.


If you are not able to know the exact date and the address that was used to take the BTC from your MtGox account, I dont think there are any way to know where they went.

And even if you could find where they are (or where you think they are) there are no way to take them back.


Shortest and Longest block interval time ever recorded in Bitcoin

(This data is current through block 535276.)

Based on block timestamps (which do not have to be accurate), the longest difference between successive blocks is 463160 seconds (5 days, 8 hours, 39 minutes, 20 seconds) between blocks 0 and 1.  The second longest is 90532 seconds (1 day 1 hour 8 minutes 52 seconds) between blocks 15323 and 15324.

For "shortest", since timestamps are not strictly enforced and can be fudged accidentally or intentionally, it is possible for a block to have an earlier timestamp than its predecessor, by up to 2 hours (7200 seconds), in which case the time difference is negative.  This has happened 13828 times.  The most negative difference is −7125 seconds (1 hour 58 minutes 45 seconds) between blocks 156113 and 156114.

There have been 222 blocks with the same timestamp as their predecessor, giving a difference of 0.

The script I used to gather this data is at https://github.com/neldredge/bitcoin-blocks.

Actual block intervals are hard to know precisely, since we have no way of knowing for sure the actual time at which each block was mined.  Some sites like blockchain.info record the first time at which their node received the block, but there is an unknown propagation delay between the time a block is actually mined and the time at which some other node receives it (though for a well connected node it is probably not much more than 1 second).  It is also possible to receive blocks out of order, so the difference in receive times could also be negative.  Moreover, such data is obviously not available for early blocks before the existence of the site in question.

In principle it could be possible to look for the longest and shortest difference between receive times, but I don't know how to retrieve that data in bulk.


What technical properties does a confirmed Tx have that an unconfirmed Tx does not?

when we speak about specific transaction: no. The unconfirmed transaction looks exactly the same as the same transaction with 1,2.. confirmations.

yes. There are 3 types of transaction: confirmed, unconfirmed, and nonexistent

example of nonexistent are those 10BTC I'll give you tomorrow.

difference between unconfirmed and nonexistent is not "obvious"

When you see an Unconfirmed tx on your PC, this does not "guarantee" that everybody else sees it too. If internet connectivity fails, you may be precisely the only person who sees it.

Unconfirmed transactions can be very different from confirmed, in many ways:

Unconfirmed transaction can spend funds that already have been spend, or funds that never existed.

Unconfirmed transaction get lost in the Internet (never get confirmed).

Unconfirmed transaction can be reversed and be replaced by different Unconfirmed transaction sending the funds to somebody else.

Unconfirmed transaction can contain technical error that prevent it to be confirmed.

Unconfirmed transaction can have low fee (less than dust limit) and this can cause confirmation delay of 12 or more hours.

Unconfirmed transaction can be one of many abusive (spam) transaction (in an attack). Such Unconfirmed transactions will typically never get confirmed and most likely all miners will delete these abusive transactions.

Unconfirmed transaction can be censored by all miners. This can happen if some address belongs to a person who is anti-bitcoin or some large corporation that has a conflict of interest with bitcoin (like a large bank). If all miners agree that they do not wish such entity to transact on bitcoin, they may decide to censor the activity of such an entity or person. This transaction may never get confirmed.


Bitcoins are stored in the blockchain in the form of unspent transaction outputs, i.e. the product of confirmed transactions. These unspent transaction outputs can be spent if you control the private key corresponding to the address they were signed over to. If a private key is lost irretrievably, the coins will never become spendable again. There is no key recovery service. You're responsible of creating sufficient backups and keeping your private keys safe.

If a company shuts down their service, they should pay out any remaining balances to their users. If they have full custody and go out of business without returning balances, you're probably (depending on the exact circumstances) out ouf luck.


Bitcoin-Qt wallet is taking forever to synchronise. Can I just use the same address elsewhere to collect coins?

Are you sure the syncing is not advancing? If you hover the icon in the lower right corner, you should see the block count. Can you see it increase?

You can export your client's wallet.dat file and import it into a new Bitcoin-Qt wallet or into another Bitcoin wallet, either using the wallet.dat file directly or by extracting the private keys from it.


It depends on what you mean by 'double spend'. Spending bitcoin just means using it to buy something. Therefore 'successfully' double spending bitcoin would just mean that you were able to buy something from two different people, even though one (or maybe both) end up being short of the bitcoin they thought they received.

The way bitcoin works is that there is a blockchain which contains all the bitcoin transactions that have ever happened. An interesting property of the blockchain is that the longer a transaction has been included in the blockchain, the more certain you can be that it'll remain there in the future. Transactions are added in 'blocks' which are produced on average every 10 minutes.

In this way, merchants would decide how long to wait before considering a transaction as 'final', ie when they will complete their half of the exchange with a customer. So for example, if a merchant was selling a house, they may wait until 6 blocks before handing over the deeds. Similarly, a coffee shop might accept a bitcoin transaction even before it has been added to the blockchain, as long as they can see it has been broadcast.

Since most online stores would wait for say 3 blocks, and it probably isn't that profitable to pull it off in any coffee shops or bars accepting bitcoins, it probably doesn't happen that often.

It's worth noting that nobody can know for sure how often double spends happen, not even miners. There's no information on the blockchain about whether bitcoins were successfully exchanged for other goods.


Do transactions happen globally synchronized?

No, that is not correct. Transactions can happen in parallel, asynchronously, and do not need to wait their turn.

When someone creates a transaction, they send the transaction statement to their peers. Those peers verify the validity of the transaction, i.e. they check whether it adheres to the rules of the protocol, then in turn will inform their peers about the transaction, so that the news of a new transaction cascades through the network quickly. The nodes will relay transactions as they get to know them, so a lot of transactions can be spread around the network at the same time.

As you can see, different nodes will know about different transactions at the same time. That's fine though, because order doesn't matter at that point unless transactions depend on each other. This uncertainty gets resolved, once a transaction gets included in a block, which we call "confirming a transaction".

As miners learn of a new transaction, they'll include it in their set of transactions that they are trying to confirm. When a miner succeeds and finds a new block, this block includes the list of transactions that they wrote into the block. All these transactions are considered confirmed by the block, the block represents an atomic increment of the network's state. Just as transactions before, the block will then get relayed through the network.

As other nodes receive the block, they verify that it is valid, and subsequently update their local representation of the network's state: They update their blockchain, remove consumed and add new transaction outputs to their "Unspent transaction outputs pool", and remove confirmed transactions from the "Unconfirmed transaction pool".


Where can I get intraday orderbook BTC/USD?

Be it a stock exchange or a crypto one, it is kind of standard that the exchanges only show a portion of the orderbook and not the entire orderbook to the users.
You could possibly try crawling the exchange but that would still be futile since the orderbook displayed are sorted and only the top 20-30 entries. You won't get the entire data.
Bittrex has their set of API's to retrieve exchange data, however that is not the intraday data. It updates timely. So you will  have to come up with a time based service which hits these API's on a regular time interval keeping in mind the hourly API usage limit and the activeness of the market.

Similarly a lot of the other exchanges also provide with API's which you can use to consolidate into one huge intraday order book.


I suppose you are the same person who made this thread on bitcointalk: https://bitcointalk.org/index.php?topic=1969807.0

I'll answer you here too to help other people too.

You are treating the pubkey as a string, but it is really a blob of binary data that is 33 bytes long. What you want to do instead is initialize an array with your pubkey and then use that to initialize your CPubKey.

Your code should look like this:

unsigned char pk[] = {0x03, 0x96, 0xf8, 0x78, 0x1a, 0x49, 0x00, 0x37, 0x2a, 0x5d, 0x72, 0xd8, 0x47, 0x18, 0xd1, 0x46, 0x17, 0x0d, 0x59, 0x83, 0xe6, 0x7d, 0xff, 0x8b, 0x4a, 0x28, 0xfe, 0xf8, 0x06, 0x90, 0xc0, 0x97, 0x67};
std::vector<unsigned char> vec(pk, pk+ sizeof(pk));

CPubKey pubkey(vec);
if (pubkey.IsValid()) {
    cout << "valid" << endl;
} else {
    cout << "invalid" << endl;
}


.bit domains are not recognized by ICANN, the company that runs the main internet DNS. This means that most operating systems have no support for them built-in.

So, to be able to visit .bit domains, you will have to do some configuration first. You basically need to let your computer know where to search for the IP address translation of the .bit domain, as most computers head over to ICANN's DNS servers for doing that.

Considering the reliability of the network, that's not easy to measure. I'd suggest you look at the number of clients connected to the Namecoin network (I cannot find a reference for that.) and the amount and speed of the available DNS proxies. On the page I just mentioned, you can see that a decent number of DNS proxies exist for Namecoin. I have no experience with using them. Considering you choose one that is close to your physical location, I'd guess they are fast enough.

On the amount of available domains, I think the .bit TLD is not quite adopted yet. But you can see on the Namecoin explorer page that new addresses are added at a fast pace. Here you can find a list with some popular .bit addresses.


Aren't blocks generated too slowly to catch up to transactions?

Yes. If there are more unconfirmed transactions than can fit in one block at a time, then those unconfirmed transactions can be confirmed in the next block.

However having more transactions than can be confirmed in one block is not a bad thing. If the sum of the transaction fees of all of the unconfirmed transaction is high, then that means that miners are more incentivized to mine the next block instead of engaging in fee sniping where they will continue to mine for the block that was just found so that they can collect the transaction fees for that block. If all unconfirmed transactions were cleared, it would be more profitable (for some time) for a miner to continue mining the previous block as the reward for that block would include transaction fees and thus be greater than the reward for the next block which, for some time, would not include any transaction fees.


I guess the rate base on daily, and 2 days mean to lock down for 2 day. so you have chance to cancel, or change the higher rate some how.

Rate: The daily interest rate you are offering your funds at.

here is the link to explain in more detail officially


How does MultiBit figure out balance of an imported address?

When MultiBit imports a private key also in the import file is the key birthdate I.e when it was first generated.

From that date it looks up the most recent checkpoint (about every 2000 blocks) in a list of checkpoints it stores.

Then it contacts a bitcoind and says 'give me all the blocks from block (say) 200,000. Here is the bloom filter I want you to use to filter the blocks'.

This is fairly time consuming  compared to if you have a blockstore. (Or something like a remote server like Electrum and Mycelium do). The advantage is that it only uses the Bitcoin Network.

It now has all the relevant transactions for that private key and hence can calculate the overall balance.


Any side-effects of upgrading to HD wallet in relationship to hard forks

There will be no effect on those other chains since they are now independent of each other, the private key corresponding to your previous UTXO will still hold the same amount of coins at the time of their fork from bitcoin core.

Here is what happen when you run -upgradewallet from: https://bitcoin.org/en/release/v0.17.0#upgrading-non-hd-wallets-to-hd-wallets

  Upgrading non-HD wallets to HD wallets
  Since Bitcoin Core 0.13.0, creating new BIP 32 Hierarchical Deterministic wallets has been supported by Bitcoin Core but old non-HD wallets could not be upgraded to HD. Now non-HD wallets can be upgraded to HD using the -upgradewallet command line option. This upgrade will result in the all keys in the keypool being marked as used and a new keypool generated. A new backup must be made when this upgrade is performed.

  Additionally, -upgradewallet can be used to upgraded from a non-split
  HD chain (all keys generated with m/0'/0'/i') to a split HD chain
  (receiving keys generated with 'm/0'/0'/i' and change keys generated
  with m'/0'/1'/i'). When this upgrade occurs, all keys already in the
  keypool will remain in the keypool to be used until all keys from
  before the upgrade are exhausted. This is to avoid issues with backups
  and downgrades when some keys may come from the change key keypool.
  Users can begin using the new split HD chain keypools by using the
  newkeypool RPC to mark all keys in the keypool as used and begin using
  a new keypool generated from the split HD chain.

For a proper way to upgrade to an hd wallet check How do I migrate my Bitcoin Core wallet to an HD wallet?


How do you validate a bitcoin address using bitcoinjs library in javascript?

If you call

bitcoin.address.toOutputScript(address, bitcoin.networks.bitcoin)

It will throw an error if the address cannot be parsed as P2SH or P2PKH, or if the checksum is not valid. Replace the second argument with bitcoin.networks.testnet for testnet.


bitcoind offers a zmq hook which you can use to receive notifications on new blocks and transactions.


Bitcoind daemon return "timeoffset" : -10,-15,-50,-60 and more

The timeoffset simply shows the relative time with respect to the peers you are connected to (actually the median of your peers). A consistent increase in the count would indicate that your server's clock is drifting, hence your server is counting time a bit faster than it's peers. This is normal (although 1 second/day drift is already quite a lot) and is not a cause for concern. If you'd like to fix it I suggest to synchronize with some timeserver over NTP.


How does the graph of money supply of PPCoin look like?

Here it is:

Note that this chart goes only up to March 2014. In the future, when proof of stake dominates, there will be a steady 1% inflation every year, but also 0.01 PPC will be destroyed every transaction. It is not known exactly what will happen, i.e. whether the 1% inflation or the destruction of coins every transaction will be a more significant factor.


Source code for SPV node on iOS - where to start?

BreadWallet for iOS is open source, has a permissive license, and uses SPV https://github.com/voisine/breadwallet/blob/78d67870cdb887bab69ffeab8d808a3cb24d3759/BreadWallet/BRPeer.m


Gregory Maxwell in IRC:

  the scheme would have the pariticiants specify the size they want, and
  at the end the period the smallest 25% would be tossed and the
  smallest remaining would be used.

So in each block there would be a field, initially set to 2 MByte. A miner is free to set any value (up to 2x the current limit).
Assuming we have the following values set in the last 12,000 blocks:

20% 2 MByte
20% 3 MByte
60% 4 MByte

Then, because only 60% want 4 MByte but 80% agree to have 3 MByte, the limit is increased to 3 MByte.

There would be a new vote every 12,000 blocks, and a decrease also would be possible if that is what the miners want.


How does the bitcoin client make the initial connection to the bitcoin network?

The Bitcoin client has a number of sources that it uses to locate the network on initial startup. In order of importance:

1) The primary mechanism, if the client has ever run on this machine before and its database is intact, is to look at its database. It tracks every node it has seen on the network, how long ago it last saw it, and its IP address.

2) The client can use DNS to locate a list of nodes connected to the network. One such seed is bitseed.xf2.org. The client will resolve this and get a list of Bitcoin nodes.

3) The client has a list of semi-permanent nodes compiled into it.

4) The client can connect to a well-known IRC network, irc.lfnet.org, and find other nodes that way. (This method has been removed as of version 0.8.2)

5) It takes IP addresses from the commandline (-addnode).


Privacy issues with storing entire information in blockchain

They could be anywhere between no one but your doctors (and maybe your insurance company) knows anything and every single person alive knows all of your health records.

Showing the second case is easy: Build a blockchain for whatever purpose containing all health records of a country, a union, the world, whatever.

Showing the first case isn't much harder: Your doctor creates the health records + a long enough nonce and keeps them until the end of a constant period of time (e.g. til the end of the month), and hashes them + the nonce. They then send the hash to an authority which builds a blockchain from them for every doctor. In this case, no one even figures out whether you visited a doctor (Note that the data accumulated at the end of the month can be empty. In fact, it is likely to be empty for the majority of patients.) or which doctors you ever visited because of the blockchain.


accept bitcoin payments for orders without 3rd party software

I don't think you need a third-party library if you have a reasonable level of programing experience.  (If you don't, you probably shouldn't be handling money directly.)

Here are the steps from the Blockchain.info (BC.i) page recreated for Bitcoin Core.

Get A Receiving Address

Use the getnewaddress RPC.  The JSON-RPC result will be a string with the address.

Get A Callback When An Address Receives A Payment

Use the -walletnotify bitcoind command line switch to run a program every time a wallet transaction is received, sent, or confirmed.  Your program can use the following commands:

gettransaction to get details about the transaction, including everything BC.i would've sent you and more.  (See link for an example.)  When Bitcoin Core runs the walletnotify command, it can pass an argument with the TXID, so you would run gettransaction <txid>
Something like curl to send an HTTP GET to your callback URL with whatever details you need

That's it.  As long as you can write a script that can parse JSON, you can do everything BC.i does with just a few lines of code.  That's also probably why you don't see any code on GitHub: it's too simple to make a project out of.

Before you get started, I highly recommend reading the Bitcoin Wiki proper money handling page to learn how to handle high-precision bitcoin values.  Also, if this is your first money-handling program, please remember the high stakes that come with holding on to money.  Hackers love stealing bitcoins.


While Creating new CryptoCurrency should we create Smart Contract?

From your question it sounds like you don't know what the difference between a smart contract and coin is.

First of all, smart contracts are ran by the Ethereum network. If you forked litecoin or bitcoin, it makes no sense on why you are talking about smart contracts.

Second, if you forked litecoin and created a new coin, you still need to mine it. This can be done either by compiling the GUI wallets, or coind in which you will need two peers to run so mining can start (I'd recommend purchasing a VPS). You cannot transfer funds you don't have. If you want to premine you will need to add some code in the block reward function to give a big reward to the first block.

Third, why would you need a pool for a coin that is not popular? The point of pool mining is because it is too hard for a single miner to find a block for themselves. Instead, they can work together and split the block reward to how much work each miner put in. So no, generating pool would not be a good idea unless the coin is popular.


Security risk(s) in running bitcoin core full node

1) None. Don't open the port (default).

2) None required.
Obviously you don't want to download Bitcoin Core binary from random sites, you want validate it, etc. as per bitcoincore.org's instructions.


Multibit export private key to usb possible?

Private keys can be exported to usb sticks or harddrives.
As for 2) when you export a private key for a back up or whatever else reason, you actually export a copy of the key . You original keys doesn't get moved out, so no, you don't neeed to re-import it.


Why does Electrum keep creating receiving addresses?

Electrum allow you to create HD wallets that use seed to generate a near infinite amount of addresses.
All bitcoin addresses are public so it is better to use different addresses each time you receive coins for privacy reasons
Here is the official answer to your question from electrum: https://bitcoinelectrum.com/frequently-asked-questions/#why-does-electrum-give-me-a-different-address-everytime


Has Apple stated its view on legality of apps using alternative electronic payment systems?

As I read here Google does not allow 3th party merchanting services:
https://stackoverflow.com/questions/10217727/apple-android-3rd-party-merchant-services

I'm quite sure that Apple wouldn't allow them either.

Although, by law, Bitcoin is not considered as a payment, since law does not recognize Bitcoin as a currency.

So by the rules i don't think they can ban you for using Bitcoin, but as we all know, Apple just decides itself what it allows and what not.


How do I start accepting bitcoins legally in Canada?

IANAL. Yet, I am baffled, why a different payment method should exempt you from paying taxes. I'd just treat Bitcoin in that regard like another fiat currency or different payment method. E.g. a shop at the border to the US taking US dollars in exchange for goods certainly wouldn't be legally exempt from paying taxes on that sale just because of it being paid in USD instead of CAD.

So, in my experience the flow would be something like:

Calculate your customers bill just as you would in any other case in Canadian dollars.
Add shipping fee and similar.
Apply VAT based on CAD value. (1)
Present the bill stating the amount in CAD, "payable in X Bitcoin to address 1xyz".
Put the transaction into your bookkeeping with the CAD value, including a remark "payment method: Bitcoin, X BTC".
Keep Bitcoin/Sell Bitcoin/Whatever floats your boat.
When paying taxes for your business, include amount of CAD in height of (1) for the transaction just as you would with any other sale.

I am not a lawyer, I have never lived in Canada, the above is solely based on my experience of how the world works. ;)


Given the recent <0.8 bug, when can we safely have larger block sizes?

I don't think anyone known exactly what the problem is, yet (note to future readers: the flaw was discovered just few moments ago).

I found this on the #bitcoin-dev IRC channel:

  sipa:  Diablo-D3: just saying that the breaking block had 1700
  transactions, but affected over 5000 block index entries

It's probably is a problem with "Berkeley DB" (0.8 use LevelDB and this is could be why 0.8 isn't affected).

Also why was the solution to push the 0.7 chain instead of 0.8?

The 0.7 chain is accepted by both 0.7 and 0.8 clients/miners. The 0.8 chain is only accepted by 0.8 clients/miners. So to avoid creating a (larger) fork, most 0.8 mining pools have downgraded to 0.7


Bitcoin HD Wallets with hardened derivation and watch-only addresses

Use the master key (call it m) to derive m/44'/0'/0'. This will give you a pair of public/private keys, let's call them xpub-a and xprv-a.
Now you can take xpub-a onto your online machine, and use xpub-a to derive receive addresses (xpub-a/0/0, xpub-a/0/1, etc) and change addresses (xpub-a/1/0, xpub-a/1/1, etc).
In this way, you've used hardened derivation concatenated with non-hardened derivation for your change and receive addresses. Your final addresses from the path of your master key (m), will then be:
Receive addresses:
m/44'/0'/0'/0/0
m/44'/0'/0'/0/1
... etc.
and Change addresses:
m/44'/0'/0'/1/0
m/44'/0'/0'/1/1
...etc...
Example using bip32:

let master = bip32.fromBase58('xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi')
let final = master.derivePath("m/44'/0'/0'/0/0")
let middle = master.derivePath("m/44'/0'/0'").neutered() // "neutered" removes the private key
let final2 = middle.derivePath("0/0");
// observe that final.neutered().toBase58() === final2.toBase58()


Will any network participant be able to send to a native segwit address?

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

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


How can I get the uncompressed public key from the compressed public key in openssl?

If you have a compressed octet pubkey, use octet to point, then point to octet.

EC_POINT_oct2point(group, point, data, size, ctx);
EC_POINT_point2oct(group, point, POINT_CONVERSION_UNCOMPRESSED, data, len, ctx);


What is the difference between Consensus and Distributed Consensus?

A consensus is an agreement between several agents. So it's always distributed in that sense.
But here it is about the process of how to achieve such consensus.
It's not dictated by one master. But agreed on by distributed voting.
Due to temporal logic being a nasty beast, you can't assume everyone to be on the same page at a specific point of time. But eventually everyone will reach a certain state of consensus.


Does the Mt Gox attack constitute theft of Bitcoins or just a Denial-of-Service attack?

As I understand it (and wrote at more length in this question), the statement is technically correct but incomplete.

The result of a malleable transaction attack is that the targeted transaction (in which the victim voluntarily sent coins to the attacker) does not confirm, but an equivalent transaction with a different ID does confirm.  It is true that this does not steal any coins: the recipient gets the same coins they were already getting.

The theft occurs in the next step, not described in your statement: the attacker points out to the victim that the original transaction didn't confirm, and convinces him to resend the amount, in a new and independent transaction.  If the victim doesn't notice the attacker's equivalent transaction, he might do this; then the attacker has received twice as many coins as he was supposed to.


How much does SegWit affect transaction size?

On bitcoincore.org:

The segwit transaction formats (see BIP 141 - witness program) have the following impact when serialised:

Compared to P2PKH, P2WPKH uses 3 fewer bytes (-1%) in the scriptPubKey, and the same number of witness bytes as P2PKH scriptSig.

Compared to P2SH, P2WSH uses 11 additional bytes (6%) in the scriptPubKey, and the same number of witness bytes as P2SH scriptSig.

Compared to P2PKH, P2WPKH/P2SH uses 21 additional bytes (11%), due to using 24 bytes in scriptPubKey, 3 fewer bytes in scriptSig than in P2PKH scriptPubKey, and the same number of witness bytes as P2PKH scriptSig.

Compared to P2SH, P2WSH/P2SH uses 35 additional bytes (19%), due to using 24 bytes in scriptPubKey, 11 additional bytes in scriptSig compared to P2SH scriptPubKey, and the same number of witness bytes as P2SH scriptSig.

And "How much does it affect block size?"

A witness commitment is included in the coinbase transaction, adding between 38 and 47 bytes, or about 0.005% of a block. (See BIP 141 - commitment structure)

A new transaction serialisation that includes the segregated witness data is defined (see BIP 141, or BIP 144). This adds an overhead of 2 bytes per transaction to allow the serialisation formats to be easily distinguished, and an overhead of 1 byte per input for the count of witness items for each input. These combine to about 1% per transaction.


The following using libbitcoin bitcoin-explorer (bx) piped command lines, see documentation to better understand the two piped examples below.

The 512 bit output below, leads me to believe the base64 encoded key is an HD key that already might have BIP 39 conversion and possibly BIP 39 passphrase applied.

1% echo -n LZEuGNcDIJI5mRCATBouTmQgdpaycce0rDH/B//+w7v0hofB6+Apt0bepR8pUUxHEHAXHHAv7+67AHwh80Lx9g== | bx base64-decode | bx base16-encode
2d912e18d7032092399910804c1a2e4e64207696b271c7b4ac31ff07fffec3bbf48687c1ebe029b746dea51f29514c471070171c702fefeebb007c21f342f1f6

Let's assume the path is the following Bitcoin path m/44'/0'/0'/0/0, then the compressed WIF key can be computed as follows:

2% echo -n LZEuGNcDIJI5mRCATBouTmQgdpaycce0rDH/B//+w7v0hofB6+Apt0bepR8pUUxHEHAXHHAv7+67AHwh80Lx9g== | bx base64-decode | bx base16-encode | bx hd-new -v 76066276 | bx hd-private -d -i 44 | bx hd-private -d -i 0 | bx hd-private -d -i 0 | bx hd-private -i 0 | bx hd-private -i 0 | bx hd-to-ec | sed 's/$/01/' | bx base58check-encode -v 128

L2Xa6v3zo12E813ssicXbjEeatdXa37J5532WwtdXYRzgzL9QSxw

The associated public address is as follows:

3% echo -n LZEuGNcDIJI5mRCATBouTmQgdpaycce0rDH/B//+w7v0hofB6+Apt0bepR8pUUxHEHAXHHAv7+67AHwh80Lx9g== | bx base64-decode | bx base16-encode | bx hd-new -v 76066276 | bx hd-private -d -i 44 | bx hd-private -d -i 0 | bx hd-private -d -i 0 | bx hd-private -i 0 | bx hd-private -i 0 | bx hd-to-ec | bx ec-to-public | bx ec-to-address -v 0

17Wnq9Nm5KcFtvhunSPN9WRTZxTUvkvri5

Your HD path path might be different.


I agree this may be a duplicate question, but fundamentally you probably need to understand what is going on to understand what is at risk.

The blockchain is where the record of of your bitcoins are kept - they are not "on your computer".

What is "on your computer" is a set of keys which allow you to "approve" a transaction to move Bitcoins from a specified address.

There are two keys:
Private Key
Public key.

The private key is used to generate the public key, so as long as you have the private key, then you have the ability to:
a) create a public key
b) sign transactions

You cannot derive the private key from the public key - that would break all cryptography!

You do not have to do this with the Bitcoin QT client - there are other alternatives, Multibit being a good alternative as it is very quick to syncronise, and you can upload private keys easily.

If you keep only one copy of that private key - then you may have a problem if it gets lost or destroyed.

Therefore you should keep multiple copies.

To answer your question specifically - if you do not copy the file correctly you are screwed. If your computer is hacked, you are potentially screwed.

Checkout the link in the comment from @frisco for more information.


The best gaming PCs gave up in 2013. Now you need ASIC hardware to mine. Even 1 TH/s (1000 GH/s) is not fast anymore - I wouldn't buy slower than that. The device bfgminer is looking for is an old and slow ASIC that connects to the USB port of your PC.

Modern miners are stand-alone machines which connect directly to your network, not to your PC. You don't need your PC or bfgminer for the mining. You use a browser on your PC to configure the miner, after that it mines on its own.


How can I calculate/estimate how quickly a machine can verify transactions on the blockchain?

You can enable logging of benchmarks for block validation. If you add debug=bench to your bitcoin.conf file, the time it took to verify each block will be written to the debug.log file and you can look in there.

There aren't any benchmarks for individual transaction verification time.


Do not use Ebay to buy Bitcoins, it is against their terms and conditions are may cause problems for both you and the seller.


If I just leave them as is, what happens?

Nothing, if a fork occurs, you get coins on the two sides of it.

  If I switch my Trezor to UASF, what happens?

If you do not spend your coins after a fork happens, nothing happens. If you spend coins after the fork, you might expose yourself to replay attacks even though you are transacting on the UASF chain. That means your transaction on the UASF chain might also happen on the other chain without you intending to. You can find more information about replay attacks here.

  Do I get coins from both chains? Do I need to pick one before August 1st?

You'll get coins from both chains for all the coins you have before the split occurs. If you buy coins after the split, you'll only get coins from the chain you bought them on.


If user sends BTC to an address for which he does't own private keys, its not non-custodial.
Most of the websites that do such crypto-crypto exchange ask for a refund address in advance and other issues are solved depending on the case.
Best way to verify things without KYC is by asking the user to sign a message for one or more bitcoin addresses that he used earlier. Example: Someone sent me 1 BTC and I need to verify in an email communication that he is the same person, I can ask him to sign a message using bitcoin address that was used as input in the transaction.


What use is a transaction that is never relayed?

None, unless it is generated by the same person who mines it into a block. But it is not the case that non-standard transactions are never relayed. There are nodes that relay non-standard transactions and miners who include them.

  How did the transaction make it into a block in the first place if it cannot be relayed? Did this transaction come directly from a client? Was it created at an origin node and put in a block somehow by that node?

Nobody said it "cannot be relayed", merely that this particular piece of software does not, by default, relay it.

  What does it mean that the script is "accepted" if it's "in a block"? (I'm aware of the script evaluation process, but the sense of the word "accepted" here doesn't seem to be the same as the standard "evaluate to true" verification process.)

It means that the client cannot reject it or otherwise ignore it. If it gets into a block, it's officially done and its outputs are spendable if the transaction script rules say si.

  Perhaps most importantly: What good is all this wonderful scripting capability if interesting transactions are not relayed? Won't this cripple the scripting capability for more complex transaction types?

That's a good question.


How can you sign a transaction without that signature being forged in the future?

In bitcoin(and most other altcoins) uses Asymmetric signature scheme where every user has a pair of (public key, private key) pair where the public key is known to everyone(including the attacker) but the private key is only known to the account holder. To this signature scheme, the catch is only the person having the private key will be able to sign a message on behalf of the public key, but everybody having the public key will be able to verify that the signature is correct.

  What is stopping me from taking your "signature" and signing another transaction with it in the future? How does this signature prevent itself from being forged by a malicious actor?

A transaction say from Alice to Bob in bitcoin is of the form
I Alice pay x amount of coin to B which I got from Carol in block number i. Alice signs this message with its private key and sends it to the blockchain. Observe that each signature is unique to the message signing it.

Since each signature is unique the if the attacker retransmits the same signature again the miners will get to know about it due to the invalidation of UTXO at the first trial and reject the transaction immediately.


My bitcoin transaction has not yet gone through. (4 days)

Has the blockchain fully downloaded yet?
If you haven't totally downloaded the chain yet, you wont see any money you have received.
Do you have to create a raw transaction?
https://en.bitcoin.it/wiki/Raw_Transactions

If you are really struggling, send me an email. Maybe we can do SSH or remote desktop, and I can save your bitcoins.
If you run "bitcoind listtransactions" in a terminal and send me the output, I might be able to get you better instructions.


how to prevent losses after a hard or soft fork

what happens to transactions on the stale chain; if i understand correctly those transactions are simply given up?

Correct. In the case of a stale (abandoned) chain, any transactions that happened in the stale blocks (that did not also happen in the active chain's blocks) would no longer exist on the bitcoin network.

  but this looks like people would lose their money if they received payments on the stale chain; how does the bitcoin protocol protect them in this case?

Also correct. There is no built-in 'protection' against having a transaction included in a stale chain. As a user, it is almost always recommended that you wait for a few confirmations before you consider a transaction as fully settled. This helps ensure that your transaction isn't included in what will eventually become a stale chain. Often, people quote six blocks as being a high level of assurance.

In practice, we can see that it is exceedingly rare for there to be a stale fork that runs longer than just a couple of blocks. See this question for some examples of past forks.


How do you get the balance of an address in your wallet using the rpc interface?

If you are only using Bitcoin through RPC commands, you might want to look into accounts. Using those you can just call getbalance and you will know how much Bitcoins are in each of the accounts.

If you are using only addresses, you can only see how many Bitcoins you received with it through listreceivedbyaddress, which can be not reliable if you spend any money from them.

All in all, you ought to just use accounts, as they can encompass many addresses and provide a lot of functionality for separating your coins into many parts in the same wallet.


Building on Ubuntu 16, missing SSL during ./configure

I fixed the issue by installing extra libraries, the whole list

sudo apt-get install -y autoconf g++ make openssl libssl-dev libcurl4-openssl-dev

sudo apt-get install -y libcurl4-openssl-dev pkg-config

sudo apt-get install -y libsasl2-dev

Source: https://github.com/mongodb/mongo-php-driver/issues/138#issuecomment-184749966


I have a HW.1 too. I purchased mine, so it came with the recovery card. If you have your recovery card, you might be able to contact their support and ask how you could convert your security card's details into the 16 byte key

If you can't do this, then use the link you posted previously to generate a random key, and then generate your card. Remember to save both.

Delete the seed currently on the HW.1 by typing in the seed 3 times incorrectly.

Plug your ledger in and then try to update the firmware. Once it prompts you, put in your random key. If this doesn't work, try using their online site. It may not be as safe. IIRC you can download their special initializing software and mount it as a boot drive on a USB and do it air-gapped.

If it still doesn't work, I guess your best bet would be to contact their support.


You must use Armory 0.96.2 and be in expert mode. When you go to request new addresses, there will be an option for you to choose P2SH-P2WPKH addresses. When you send Bitcoin, you can also choose to make your change P2SH-P2WPKH.


Multibit Classic Wallet broken - Ballence unspendable

I had the same problem.
But it is not directly the fault of the wallet.
The wallet sends the transaction with the standard miners fee, not that high.
So miners won't focus on your transaction, because of the low miner fee. This has becoming a more frequent problem since Bitcoin is becoming so big.

But there is a solution!
Try this website ViaBTC

I recommend reading there service statement first.
Than just insert your transaction ID fill in the captcha and press submit.