Missing unconfirmed transaction from trezor https://btc4.trezor.io/tx/a23173e98ac492eb84c4324ce66817a6900d89c2fb408a85daf9ba98f1a7b513
Hello guys, I sent this transaction like every other time from trezor, the fee was set on high. But this time I cant even find it in any blockchain explorer by its ID and the btc did not come

This is not your fault. I have published the transaction.
You may track it here: https://blockchair.com/bitcoin/transaction/a23173e98ac492eb84c4324ce66817a6900d89c2fb408a85daf9ba98f1a7b513 or here:
https://blockstream.info/tx/a23173e98ac492eb84c4324ce66817a6900d89c2fb408a85daf9ba98f1a7b513?input:3

At the bottom of https://btc4.trezor.io/tx/a23173e98ac492eb84c4324ce66817a6900d89c2fb408a85daf9ba98f1a7b513
you can see the

  "hex": "0100000000010871f83...

which has the full hex-encoded raw transaction.
I have copied this to push it here.


BITCOIN SCRIPT: Write the bitcoin ScriptPubKey script for a transaction that can be redeemed by anybody who supplies a square root of 1764? Bitcoin script: For the following questions, you're free to use non-standard transactions and op codes that are currently disabled. You can use as a shorthand to represent data values pushed onto the stack. For a quick reference, see here: https://en.bitcoin.it/wiki/Script a. Write the Bitcoin ScriptPubKey script for a transaction that can be redeemed by anybody who supplies a square root of 1764. Write a corresponding ScriptSig script to redeem your transaction. Suppose you wanted to issue a new RSA factoring challenge by publishing a transaction that can be redeemed by anybody who can factor a 1024-bit RSA number (RSA numbers are the product of two large, secret prime numbers). What difficulties might you run into?

decodescript 769502e40687
{
  "asm": "OP_DUP OP_MUL 1764 OP_EQUAL",
  "type": "nonstandard",
  "p2sh": "3JQspThZ3pAdZZjUfb6hni5f8rW9yYonJv"
}

https://bchsvexplorer.com/address/3JQspThZ3pAdZZjUfb6hni5f8rW9yYonJv


What information can an attacker gain from watching the users behavior in block chain? Given the blockchain is a public ledger, if user chooses not not change their public key (address) every time they make a transaction, what information can an attacker gain from watching the users behavior?

If you use the same address for every transaction you receive, then anyone who knows that address is yours (and is watching the blockchain) will have record of your entire history of transactions. You will have zero financial privacy.

Address reuse is also indirectly bad for the users you transact with: anyone who knows the other user's address will now also know that they transacted with you. Approximate time, and the transaction amount will all be public knowledge.

Thankfully, by using a new address for each transaction, it becomes extremely difficult to make such assumptions, as doing so creates a very high level of plausible deniability and uncertainty when attempting blockchain analysis.

Bitcoin privacy is a highly nuanced topic, for a much more in depth explanation see: https://en.bitcoin.it/wiki/Privacy


How do I start -testnet in -deprecatedrpc to test a script? I hope all is well during our COVID-19 pandemic.
My question: How do I start "bitcoind -testnet" in "-deprecatedrpc=signtransaction" mode?
Do I simply start it the same way without being a test and insert "-testnet" between "bitcoind" and "deprecatedrpc" like this"bitcoind -testnet -deprecatedrpc=signrawtransaction" (I mean, I need this to make sure my script is tested before running it and it keeps saying "error: Could not connect to the server 127.0.0.1:18332 (error code 1 - "EOF reached").
Thanks.

I was able to start -testnet in deprecated mode to test my script like this:
bitcoind -testnet -deprecatedrpc=signrawtransaction


How does bitcoin handle extreme transaction volume? What would happen if the amount of active Bitcoin users grows up enough so that the average rate at which transactions are created becomes faster than the average rate at which transactions are included in the blockchain?

Even if it doesn't grow up to that point, what if someone simulates this by creating too many transactions?

Basically, transactions just sort of get put in a backlog until there is space enough for them to be processed. That's the usual case anyway.

The more extreme case is when there are too many transactions to even keep in the backlog. To understand what would happen here, you need to know a little bit about the software/people that put transactions into blocks: miners. Miners basically keep a priority queue of transactions, where the transaction priority is determined by the size (in bytes) and the fees it pays. Higher fees and lower size transactions tend to have higher priority. The software that miners run only has so much memory, so if so many transactions are broadcasted to the network that miners can't even keep up, they tend to just 'forget about' the transactions with the least priority.

For users, miners choosing higher priority transactions means that it may be harder for them to get their transaction included in a block. They either have to pay more fees or make smaller transactions to be able to compete.


Incentives for Segwit vs BTU I had the (appearntly wrong) impression that miners as a whole would prefer limiting the block size / scalability / TPS in order to increase fees (basically limiting the supply), and users and companies would prefer to increase capacity to reduce fees.

However, reading some contradicting opinions among miners, and allegations against Bitcoin Core developers of pushing the miners to accept Segwit, I realized my understanding is lacking.

Assuming no agreement on what is the truth, what are the alleged incentives of the different parties, as reported by their opposers?

Some Core developers work for Blockstream. Some people say they want small blocks so that you will be forced to use Blockstream products (sidechains) to use bitcoin.

Some say Bitmain uses ASICboost for a 20% benefit on their mining operations - a huge advantage in the mining world of thin margins. Some say they don't want segwit because it would hinder ASICboost.

At the time of writing, mining fees constitute about 20% extra income on top of the new coins that miners mint. However, several companies have already switched from Bitcoin to Ethereum because of the high fees. Higher prices is good for business, but losing customers not so much. Miners may want just the right amount of scaling, to maximize income.

People also don't agree on what Bitcoin should be. Some want every human being (and computer) to be able to use Bitcoin directly. Others want Bitcoin to be a settlement network used only by big financial institutions, while regular people use something else. For everyone to be able to use Bitcoin we'd need scaling in a huge way. For a settlement network you don't need further scaling, which is what we are seeing so far. You may think that since individuals and small companies are leaving bitcoin, this means the settlement supporters are winning. However, noone is using bitcoin for settlements and there are no signs that this will change.

Then there are people who want bitcoin to fail. Whether it is because they invested heavily in an alt coin or because they benefit greatly from the status quo of the economy. As long as bitcoin is unable to support a growing user base, these are the people who are winning.

There is also the possibility that many of these people are just idiots who don't understand the benefits of cooperation. As the saying goes, don't attribute to malice what can be attributed to incompetence.


Duplex micropayment channels: criticisms of Lightning and implementation A paper from 2015 by Decker and Wattenhofer proposes an interesting design for a payment channel network, which differs from the Lightning network. The authors claim in the Related work section that Lightning:

"requires exchanging keying material for each update in the channels, which results in either massive storage or computational requirements", and
"cannot be decomposed into smaller units that can be analyzed in isolation, making the security analysis difficult and resulting in complex implementations".

I have two questions:

To what extent are those criticisms of Lightning valid as of November 2017?
Is there an implementation of Duplex micropayment channels or at least plans to create one?

As of today, (November 2018):

  To what extent are those criticisms of Lightning valid as of November 2017?

This is still a case for Lightning. Eltoo was the first to suggest a simpler way of coping with such storage requirement. They do not require storing keys or older transactions. Their disadvantage is that there is no punishment in the event of fraud, leading to selfish users always publishing the transaction that maximises their balance. In current Lightning Implementations, it is important to keep track of Breach Remedy Transactions, and of course never lose new Commitment Transactions (as this can incur in a punishment to oneself after publishing an old balance unknowingly).

  Is there an implementation of Duplex micropayment channels or at least plans to create one?

Current implementations are focusing in Lightning Channels for two main reasons:
1. Eltoo channels are too recent (perhaps somebody is working publicly in an implementation, I am not aware)
2. DMC channels have a trade-off between the utility of the channel and the worst-case collateral cost of the channel, that discourages its use. This is even more important when considering n parties (such as factories). For more information about this trade-off, see the results in this document

DMCs are however better when one knows of a period of time that one will be offline, so I believe it will be implemented in the future. But there is no current implementation in the main ligthning development teams.


Does every node has a whole copy of the blockchain? As i read here, in a blockchain "each node the has a copy of all transactions ever made". This to me seems impossible, bitcoin exists for a long time, and the memory size of the intere blockchain would be enormous.

ps: if i have to pay for a service using bitcoins, do i become a node of the blockchain ?

To join the network, a Bitcoin full node will work its way through the network history, independently verifying the state of the network through time. So yes, each node will have downloaded and validated the entire transaction history, but a node can choose to use 'pruning mode', where it will discard unneeded transaction history after validation is complete.

The ever-increasing size of the blockchain is a heavy consideration when considering network and protocol updates. Bitcoin requires a distributed network in order to maintain its function, so it is important that the software can be run on inexpensive hardware, so that more people can participate.

  ps: if i have to pay for a service using bitcoins, do i become a node of the blockchain ?

There are other ways to interact with the network. Many wallets are lite-wallets, which validate the chain via headers instead of the entire block. This is a less robust security model, but it works well for many people.

You generally do not need to pay a service in order to interact with the network (as a full node, a lite-wallet, etc).


How do non-deterministic wallets violate the principle of address reuse? In chapter 5 of Mastering Bitcoin, Andreas writes:

"The disadvantage of random keys is that if you generate many of them you must keep copies of all of them, meaning that the wallet must be backed up frequently.
Each key must be backed up, or the funds it controls are irrevocably lost if the wallet becomes inaccessible.
This conflicts directly with the principle of avoiding address reuse, by using each bitcoin address for only one transaction."

If we are using each bitcoin address for only one transaction, how does this result in address reuse?

The text indeed doesn't make it's case clear, but the idea is that random key generation makes for inconvenient backups.  The more keys you generate, the more frequently you will have to back up the wallet.

To avoid this, some users of non deterministic wallets have resorted to reusing keys\addresses, as a sort of easy way out of having to follow the demanding practice of frequent wallet backups that are needed when new keys are generated.


What is going to happen when it is totally infeasible to download the entire bitcoin transaction history? As far as I know, the bitcoin system currently relies on the principle that all transactions are made by someone with access to the entire history of previous transactions. Since bitcoin's public debut 2.5ish years ago, these records have stayed small enough that it's still easy for one person to download and update it.

Once it gets large enough, though, it's going to be hard to do that. When I ask most people about this problem they just tell me that eventually we will start trusting our money to some bank-organization-type-thing (e.g. Coinbase) and we won't have to worry about the integrity of our records.

Imagine that in the distant future, the bitcoin system becomes widespread enough that the rate at which transactions history grows exceeds the rate of change in disk space technology. (far cry, I know, but let's just assume a worst-case scenario.) How would bitcoin account for this problem?

Is a better, more widely agreed on solution?

The default answer to scaling is SPV (lightweight) clients, which allow very good security and control of funds without the entire blockchain. Full nodes will still exist but the cost of running one will not be prohibitive.
In practice many people will use some sort of bank service. If the funds are in full control of the bank it has some disadvantages, but yes - in this case of course the banks will settle intra- and inter-bank transfers with internal records and reciprocity agreements, not with the blockchain.
There are some schemes which allow making a payment without it being recorded as a transaction in the blockchain, and without having to trust a bank with your money. This will greatly reduce the total size of the blockchain.


Is there any way to prevent intra wallet transaction fees? I heard about it somewhere, but no where found a complete step by step solution.

I've heard that for addresses in the same wallet, the transaction fees can be avoided. Is it a rumor ?

If no, then please help on how to attain it.

By wallet, I mean to say the wallet that is being used by bitcoind/litecoind or bitcoin-qt/litecoin-qt on a machine. (they usually use the wallet.dat)

A traditional Bitcoin wallet contains a bunch of private keys and a bunch of accounts. Each private key has a corresponding Bitcoin address.

For each private key that the wallet has issued, some account is associated with that key. This serves only one purpose -- it determine which account gets its balance raised when funds are received at that address.

Intra-wallet transfers require no transaction and thus pay no fee. I can switch from 10 Bitcoins in account "Jeff" and 0 in account "Judy" to 0 in "Jeff" and 10 in "Judy" just by swapping a 0 and a 10 inside the wallet. The Bitcoins remain at the same address, they are just credited to a different account.


sendFrom with fee inclusive I am using Bitcoin JSON RPC 14 version so how can I use sendFrom
  command in the case of fee inclusive.

sendfrom has these parameters:

sendfrom "fromaccount" "toaddress" amount , minconf, "comment" "comment_to"

As you can see there is no subtractfeefromamount boolean parameter.So you can't deduct fee from the amount itself.

You can use sendmany option with single destination address. sendmany has these parameter:

sendmany "fromaccount" {"address":amount,...} ,minconf, "comment", subtractfeefrom

Here subtractfeefrom in above parameter accept array of address from which fee will be deducted.

example:

bitcoin-cli sendmany "1521" "{\"n3jYBjCzgGNydQwf83Hz6GBzGBhMkKfgL1\":0.01}" 1 "" "[\"n3jYBjCzgGNydQwf83Hz6GBzGBhMkKfgL1\"]"

n3jYBjCzgGNydQwf83Hz6GBzGBhMkKfgL1 will get 0.0098(approx) and not 0.01


Zcash t-addr + z-addr transactions Is it possible to "break" the traceability of the blockchain by sending ZEC between z-addr and t-addr?

tl;dr You should use rounded values of ZEC when unshielding, and even then you will have less privacy than if you only use z-addrs.

We address this exact question in this blog post (images from which I reproduce below).

Transactions using the Bitcoin-inherited t-addresses are obviously traceable. However, the zero-knowledge property associated with the use of z-addresses means that when you send ZEC to a z-address (creating a "note", the private equivalent of a TXO), and then use that note in a subsequent transaction, the two transactions are not directly linked on the block chain (that is, the second transaction does not contain a prevout field referencing the first one, like would happen with t-addresses).

This means that if you send ZEC from a t-address to a z-address (a "shielding" transaction) and then from the z-address to a different t-address, you end up with transaction chain (b) below:

This "breaks" the link between Alice's and Carol's t-addresses (for this transaction; other transparent payments could still link those addresses, so the same care should be taken as with Bitcoin). Considered more widely, you can imagine "islands" of t-address activity, separated from each other by murky z-address transaction "seas" (see this blog post for related ecosystem discussion).

Now for the caveat! The z-address hides all details (recipients, values, and memo fields) of the output notes in the shielding transaction, and the corresponding properties of the input notes in the unshielding transaction. But the ZEC values are still public, because they are visible in the transparent halves of the transactions! This means you can run into problems when you send the full balance of a t-address with no change:

The full value is visible in the first transaction, and then later a second transaction appears with an output value equal to the original input value minus two transaction fees. Timing data is also available (because the transactions are inherently ordered and timestamped in the block chain), meaning that it can be possible to statistically link the two transactions based on those values alone [0].

The solution to this is pretty simple: use "rounded" amounts when unshielding (with the change going back to the z-address). That way, there is no value link between the shielding and unshielding transactions.

EDIT: Note that the particular rounding strategy you use can itself leak information! For example, if you always round down to the nearest whole ZEC, and someone else always rounds down to the nearest 10 ZEC, then over time, your unshielding transactions will look markedly different to theirs, and someone who is looking for patterns in the block chain can start separating your unshielding transactions from the rest. In general, the larger and more standard the buckets you use are, the less information is leaked; additionally, you want everyone else to be using the same buckets as you too!

The upshot is, if you want to minimize the amount of information you leak, the simplest way to do so is to minimize your usage of t-addrs.

[0] It's a little more complex that this. The shielded part of an unshielding transaction still has the same two output notes as any other shielded transaction part (they just contain dummy notes for a z->t transaction), and those parts could be filled (ie. using a z-address to pay both z-addresses and t-addresses). So while matching values is a strong link, it is not a definitive link, and in fact can be intentionally subverted by wallets choosing vpub_new values for their unshielding transactions from the set of vpub_old values that have been seen on the block chain. Rounding the values is effectively a social consensus mechanism for achieving this.


Do pool operators usually set block version numbers before their clients hash? I know that pool operators have the power to modify the actual transactions in a block. I also know that pool operators can decide on block transaction orderings and even commit double spends pretty easily.  I know that pool operators send the merkle root hash of this block to miners. The miner then provides the nonce, which is the hard work of mining.

But, there's another part to mining, which is the block version number. Do most pool operators set this, for e.g. voting, and which bits are able to be set for votes?

I know that pool operators have the power to modify the actual blocks inside a transaction.

Transactions don't contain blocks. Miners/pool operators can't modify any of the normal transactions inside of a block. They can only change things in the block header, the coinbase transaction, and the transaction ordering.

  I also know that pool operators can decide on block transaction orderings and even commit double spends pretty easily. I know that pool operators send the merkle root hash of this block to miners. The miner then provides the nonce, which is the hard work of mining.

Not necessarily. It depends on the protocol being used. If it is stratum, this is largely true (except the merkle root thing. Stratum only provides part of the merkle tree for the merkle root so that an extranonce in the coinbase can be used.)

If getblocktemplate is used, the miner has a lot of control over what is being hashed. With GBT, instead of just part of the header and hashed data being sent to the miner, the entire block structure is sent and the miner constructs the block and block header himself before hashing it. This means that the miner could choose to change whatever he wants in the block.

  But, there's another part to mining, which is the block version number. Do most pool operators set this, for e.g. voting, and which bits are able to be set for votes?

If the pool is using stratum without ASICBOOST support, then the pool operator sets the bits for the miner. If ASICBOOST is supported, the miner can modify some of the bits in the version number in order to use ASICBOOST. With GBT, the miner can modify the version number if the pool indicates that they will accept a block with a version number different from the one that they set in the block template.

Also, note that miners do not vote. Setting the version number for soft forks is not a vote, it is signalling that the miner is prepared to enforce the rules of a soft fork. It is a signal of readiness, not a vote.


If you have two chains of same length and you add your block to one chain while n/w selects the other If you have two block-chains of same length and you add your block to one chain while the network selects the other chain, what happens to the transactions in your block ?

That block and the transactions in that block will not be accepted as confirmed by the network.

Few things can happen with these transactions though:

some or all of these transactions are possibly included in the other chain
the transactions that are not included in other chain are returned to the pool of unconfirmed transactions, waiting to be included in some future block
if conflicting transaction is included in other chain than the transaction will be considered invalid (as a double spend) and will be removed from the pool and will not be included in the future


Method not found when I use bitcoin-cli to generate blocks under regtest mode As the picture shows,I am really confuesd.

For the upcoming Bitcoin Core 0.18 release, the generate command has been deprecated and its functionality disabled. For the following major release, 0.19.0, the generate command has been removed entirely. This removal is already in the master branch of Bitcoin Core's source code. If you have built that branch from source, then the generate command does not exist.

Use generatetoaddress instead.


How we can use Blockchain to prevent Plagiarism in scientific papers? I have a research in "plagiarism prevention using blockchain" topic, and it is specialized in scientific papers. Anyone has any idea to help me through this topic?

"Blockchain" can't be made to prevent, or even detect plagiarism. The most useful thing related to your problem which the chain can help with, is it enables you to timestamp a document in order to prove that the document must have existed before a certain point in time. It can't tell you when the document was created or who the document was created by. It can only tell you who first pushed the document onto "Blockchain".

Assume author A publishes a document, by whatever medium, and person B receives the document. B checks "Blockchain" to see if the document has been published on it already, and if not, B publishes the document themselves, linked to an address which they have the private keys for.

Now B can go around pretending they created the document, and since A didn't pre-emptively publish the document onto "Blockchain", they are unable to use this tool to disprove B's copyright ownership. "Blockchain" actively prevents A from asserting their ownership this way because only B has the private keys.

So for such tool to ever have practical use, it would need to be absolutely ubiquitous in use, such that nobody would ever publish any document without first timestamping it onto "Blockchain" linked to their own private keys.

You also have the case of private key loss or theft, which would prevent an author being able to assert their ownership of the document using "Blockchain".


Does any exchange site let me automatically sell Bitcoin to USDT (or USD) right after I receive it? I want to sell Bitcoin automatically and immediately after I receive it.

Is there any exchange site has this feature?

You can use one of the Bitcoin exchanges and using their API, create something with the following logic:
while True:
    current_balance = get_balance("BTC")
    if  current_balance > 0:
        crypto_exchange.sell_market_order(current_balance)
        print("Sold %s" % current_balance)
        break
    else:
        time.sleep(60)

This would automatically sell your crypto as soon as its confirmed as an active balance on the exchange and it would "hedge" your crypto exposure in the process.


segregated witness adoption What happens if segregated witness never reaches the 95% adoption threshold from miners? Will it still take effect for those transactions where the miners have adopted it?

By current agreement Segregated Witness will only activate after it reaches 95% of the miners signaling readiness.

Sending Segregated Witness transactions before that would be foolish, as if they were to be included in a block, anyone would be able to spend the outputs before Segregated Witness is enforced. They are however, non-standard to current versions of Bitcoin Core.

If the 95% threshold is not achieved for an extended period of time, there might be a proposal to lower the threshold.


Why does the decode function of the segwit bech32 encoder/decoder take a hrp (human readable part) as input? Looking at the code referenced in bip-0173, specifically for example here:
https://github.com/sipa/bech32/blob/master/ref/javascript/segwit_addr.js

  function decode (hrp, addr) {
      var dec = bech32.decode(addr);
      if (dec === null || dec.hrp !== hrp || dec.data.length < 1 || dec.data[0] > 16) {
        return null;
      }
      ...

I understand that this is an error checking statement, but why check a (user?) inputted hrp vs the decoded hrp from bech32.decode?

Also I'm assuming that the "dec.data[0] > 16" check is to make sure that the byte at index zero doesn't exceed a value of 16, which would be invalid hex.  Is this correct?

The HRP is part of the bech32 encoded string, and in the bech32 decoding API, it is returned along with the payload by the decoder, after checking the checksum.

We still want to compare it with the expected HRP in BIP173, which encodes the chain the software is operating on.

Otherwise you could have a testnet node that accepts mainnet BIP173 addresses or the other way around.


High activity on exchanges vs. low transaction rate on blockchain I a bit puzzled to see high transaction rates on BTC exchanges yet read that the blockchain only confirms about 6 transactions per second. Given that every transaction on an exchange requires also a transaction on the blockchain, how does it work? Is my perception of the volume just wrong? Or are there quiet times at exchanges when the blockchain can catch up?

Given that every transaction on an exchange requires also a transaction on the blockchain, how does it work?

They don't, movements on exchanges are internal, not Bitcoin transactions.


Is bitcoinica.com planning to reopen after the 11th May 2012 theft? On 11th May, 2012, 18,547 BTC were reported stolen from bitcoinica.com as stated here: https://bitcointalk.org/index.php?topic=81045.0

The bitcoinica.com website is unresponsive at the time of writing this. Are they planning to reopen? Have they stated whether their users' deposits will be refunded? If yes to either of those question, have they give a timeframe?

Zhou tong has stated here that reopening is being considered, with a time frame of several months.

He has also stated that deposits will be refunded; Most recently, he has stated that a claim page has been opened at https://claims.bitcoinica.com/, but at the time of this writing it seems to be unavailable.

Update: I can now access it.


What makes a Bitcoin Miner chip such as an Antminer different than a usual CPU? Is it the processor? Or maybe RAM? I'm sure, it's not the GPU though. Which and what part does it make them powerful to mine?

Bitcoin miners have ASIC (application-specific integrated circuits), special chips which can perform mining calculations and nothing else, and are very efficient for it. The specific calculations required are encoded in the hardware - the transistors are arranged in the pattern "calculate SHA-256".

In contrast, the CPU that exists in normal computers can do everything, but is not very efficient at any one task. The transistors are arranged in the pattern "execute the instructions that you are given". So you can give it any instructions you want, including "calculate SHA-256" - but it will not be as efficient as a special-purpose chip.


what are vin_sz and vout_sz in tx part? I am trying to understand the raw blocks better:

vin_sz and vout_sz are some of the unknowns. does this values (sz=size?) have something to do with a number of confirmations?

example:
https://blockexplorer.com/rawblock/00000000000008d11f13eed2e13f2765eceaf00de36e0ec040a10cc3738bdc74

I believe it stands for vector input size and vector output size.

vin_sz is the number of inputs and vout_sz is the number of outputs.


Solo Mine with an AntMiner How do I solo mine with an AntMiner?

AntMiners use cgminer, which certainly supports GBT, but when I use http://<my_local_net_ip>:8332/ and my bitcoind username and password for "Worker" and "Password," respectively, on the "Miner Configuration" tab of my AntMiner's page, the AntMiner says my "pool" is dead. bfgminer can connect, via RPC, to my local bitcoind "pool" just fine, so the issue is with AntMiner/cgminer.

Check your rpcallowip configuration, you will need to explicitly allow connections incoming to your RPC port from the network. If your local network for example is 192.168.0.x, the rpcallowip configuation in your bitcoin.conf will need to be 192.168.0.0/24 (this is CIDR notation).


What part of the code is responsible for coinbase payouts? Looking for the part of the code responsible for doling out coinbase to the miner who solves the puzzle. I'm guessing it's somewhere in src/rpc/mining.cpp, but it's tough to figure out from the code where the payout is happening. Can anyone clear this up?

You're really asking about two separate but related pieces of code. One piece of code claims the mining reward, and the other piece of code says that it is okay for miners to claim a mining reward.

The first is here: https://github.com/bitcoin/bitcoin/blob/1afc22a7667a7a5c66b4b5d7f50832356dd5ec12/src/miner.cpp#L161

The second is here: https://github.com/bitcoin/bitcoin/blob/470c730e3fa9d1120dda1de2d433304023c8aa78/src/validation.cpp#L1819


What is the key differences between bitcoin-qt, bitcoin-cli, bitcoind, bitcoin rpc, and daemon? Can someone please give a brief explanation on these? I'm getting very confused with the differences, and every tutorial article I read uses these terms interchangeably (I'm trying to set up a pruned node...)

bitcoin-qt
bitcoin-cli
bitcoind
bitcoin-rpc
daemon

Thank you!

All of those things are part of the same program, Bitcoin Core.

bitcoin-qt: The GUI version of Bitcoin Core. Most users will use this as it provides a nice Graphical User Interface that uses the Qt framework. It does all of Bitcoin Core's functionality, including being a full node and handling your private keys and transactions.

bitcoind: The Bitcoin daemon. It is the version of Bitcoin Core which can run in the background. It still does all of the full node and wallet things that bitcoin-qt does but is harder to access. bitcoind is primarily used for machines without a GUI (e.g. headless server). It can be accessed and interacted with using the JSON-RPC protocol.

bitcoin-cli: A tool that you can use to interact with bitcoind. It speaks the JSON-RPC protocol that bitcoind uses and lets you send commands to bitcoind and get the results back.

bitcoin-rpc: The Bitcoin Core RPC server. This is part of bitcoind and bitcoin-qt (it must be set explicitly to be enabled in bitcoin-qt). This is the interface that bitcoin-cli interacts with.

daemon: A daemon is any service which runs in the background. bitcoind is a daemon, and so are many other software which run in the background and have no GUI.


How is wallet balance from unspent transactions in cryptography terms? There is already a good almost complete answer here (but missing the cryptography explanation):
How is a wallet's balance computed?

Is a bitcoin wallets balance calculated on the client computer app? eg. Leger Live

How is bitcoin wallet balance calculated cryptographically?

Does Ledger Live app check/compare each transaction+hash & transaction+signature hash like mempool nodes do?

Or does it only look at the unspent output addresses and check if they are children of wallet public key? If so how does it do this in cryptography terms?

Is a bitcoin wallets balance calculated on the client computer app? eg. Leger Live

yes.

How is bitcoin wallet balance calculated cryptographically?

There's no cryptography involved, certainly no encryption.
You add the credits and subtract the debits.

Does Ledger Live app check/compare each transaction+hash & transaction+signature hash like mempool nodes do?

All nodes verify the data they receive, so far as they are able to. This involves computing hashes and verifying digital signatures. see Wikipedia article and Mastering Bitcoin, Chapter 4

Or does it only look at the unspent output addresses and check if they are children of wallet public key?

Yes.

If so how does it do this in cryptography terms?

Since wallets derive these keys and addresses, they just keep a list of them.
The original derivation involves hashes. The hashing algorithms come from the world of cryptography but are not encryption.
The method for deriving many addresses from a single seed is described in BIP32


Does mining power of different miners add up in mining pools? I have this doubt regarding bitcoin mining, assuming I have two miners of hashpower 500 H/s .

Can I add up my hashpower and make it work like a single processor of 1000H/s
OR
Both both miners would be acting independently?

According to what I have read, option 1 is how it takes place.

So this means a mining pool has combined power of all the associated miners and working on one block?
OR
All miner are working on different block of their own ??

According to what I have learnt, option 3 is how it takes place.

Now, referring to the attached chart by blockchain.info and assuming option 1 & 3 for the questions
Only top 3-4 mining pools should be making profit. Relatively other miners have a very low probability with available hashpower to mine a block. And say for profit if all the miners decide to join big mining pools, eventually the network will become centralized.

Mining is a lottery, not a race.

The fastest miner doesn't always win. In general, if you have X% of the hashrate, you will find X% of the blocks.

This is because not just all pools, but every every, every chip, ... is attempting to solve a different block proposal. Every attempt has an independent chance of winning. There are an infinite number of potentially valid blocks, but they're still only a tiny fraction of all possible blocks. Everyone is not trying to find the next block - they're trying to find a next block.

So:

  Can I add up my hashpower and make it work like a single processor of 1000H/s

Yes. You can't distinguish the different processors - more hashpower just tries more block proposals at the same time.

  Both both miners would be acting independently?

Yes. Everything always acts independently.

  So this means a mining pool has combined power of all the associated miners and working on one block?

Yes.

  All miner are working on different block of their own ??

Yes.


Could miners steal money? I've been reading around: https://en.bitcoin.it/wiki/How_bitcoin_works

What prevents a miner's block from being accepted across the network if the hash checks out when miner forges transactions in the block?

For example, lets say I'm mining and I want to steal money from address A and put it into my address B. So I build a block with the A->B transaction along with some requested transactions. Now if I can compute a hash for the block before anyone else, and send off to peers in the network, how could they reject it? How would they know that's not a real transaction? If bitcoin clients record requests to verify, maybe this request was blocked by some NAT issue.

I can't think of a good way of fixing this and I didn't find anything about in documentation. Any insight would be appreciated. Thanks.

Transactions are signed with ECDSA. Incidentally, bitcoin addresses are hashes of the ECDSA public key that can spend them. You can't spend somebody else's coins unless you 1) do a bruteforce search to find their private key or 2) find a public key that hashes out to the same thing. Both are much, much harder than doing a double spend attack.


Is it possible to identify mining pools? I am doing research on Selfish Mining in Bitcoin. Here is the article
http://hackingdistributed.com/2013/11/04/bitcoin-is-broken/
I wanted to know is there a way to identify minining pools? I wanted to know how can we know that when someone finds a proof of work is it done by an individual or a mining pool?

Thanks

We can make an educated guess about it.

We can look at the hashrate that various pools advertise. We can look at what IP address the mined block was first seen at. We can look at the coinbase of the block. (Eligius.st famously embedded bible quotes.) We can also guess at the size of a mining pool by looking at its Alexa rank.

But we don't know for sure.

This page uses the advertised hashrates of the pools: https://blockchain.info/pools


Why does my implementation of hex to Base58check produce different results than the example? Step 8 of this wiki page gives this hex value: 00010966776006953D5567439E5E39F86A0D273BEED61967F6

Step 9 converts it to this base58 string:16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM

I'm trying to implement the conversion function using the pseudocode from this wiki page. This is my implementation (in Java):

    String input = "00010966776006953D5567439E5E39F86A0D273BEED61967F6"
    BigInteger bigInteger = new BigInteger(input , 16);
    String code_string = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz";
    StringBuilder output = new StringBuilder();

    while(bigInteger.compareTo(BigInteger.ZERO) == 1){
        BigInteger[] divAndRemainder = bigInteger.divideAndRemainder(BigInteger.valueOf(58));
        output.append(code_string.charAt(divAndRemainder[1].intValue()));
        bigInteger = divAndRemainder[0];
    }

    int i=0;
    while(concat.charAt(i) == '0'){
        i++;
        output.append(code_string.charAt(0));
    }
    System.out.println(output.reverse());

This prints out 1116UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM. This is close to what the wiki page produces, but not quite, there are 2 extra leading 1s. This is from the 2 leading 0s in the input string. Why doesn't the wiki example get my result?

Each hexadecimal character has four bits of information. Two hex characters contains eight bits of information, so they form a byte.

For each byte in front of the address, a 1 should be put. Since two characters form a byte:

int i=0;
while(concat.charAt(i) == '0' && concat.charAt(i + 1) == '0'){
    i += 2;
    output.append(code_string.charAt(0));
}

BTW, it would look better if it was a for loop:

for (int i = 0; concat.charAt(i++) == '0' && concat.charAt(i++) == '0';) {
    output.append(code_string.charAt(0));
}

Also, probably you've made a mistake while copying the code: You haven't declared a variable named concat. It's input.

Last note: If you're going to use this encoding for things other than Bitcoin addresses (which have checksum), make sure that i will always be smaller than concat.length()


How is a node in the middle prohibited from keeping the money in a routed Payment in Lightning network? It is my understanding that Lightning is to scale with users having only few payment channels by leveraging the six degrees of separation theory to facilitate payment routing. I understand how onion routing is employed to obfuscate origin and target of the payment.

I have read claims that it is also not possible for a node in the middle to receive but not forward the payment. This appears to be implemented by having either all hops of the payment execute at once, or none at all.

How can it be assured that the whole payment chain executes the payment at once?

Lightning forwards payments using a construction called a "hashed timelock contract" (HTLC), which allows the payee to redeem the transaction if they know the preimage to a given hash, or allows the payer to redeem the transaction after a given timeout.

So eg if I'm selling you something for $2 over lightning, I might say "I'll tell you the sha256 preimage of 1bc9852364a8aa073daedb3965716ab63d84570c645b091f535a3677010d9984 when you pay me $2. You setup an HTLC with Alice giving them $2 when they know the preimage with a timeout of 50 hours, Alice sets up an HTLC with Bob for $2 with a timeout of 28 hours, and Bob sets up an HTLC with me for $2 with a timeout of 4 hours. At this point no money has actually changed hands -- if I don't reveal the preimage, everyone gets their money back. If I do reveal the preimage ("the password is xyzzy"), I get $2 from Bob; but Alice and you still haven't actually paid any money. But Bob knows the preimage, so he can claim $2 from Alice; and then Alice can claim $2 from you.

So the effect is, the middlemen never have the option of running away with the money, they can only run away having paid the money, but not collected it from you: if Bob received the preimage, but didn't collect from Alice before the 28 hour time limit expired, I'd be paid, while Alice and you would get your money back.

This would be pretty stupid of Bob, so we assume that mostly people like Bob will avoid doing things like this, and in effect the whole chain will be cleared at once.


Proof of work: optimal number of transactions? I've been struggling with this Q for a while: My initial understanding was that miners start to work on PoW for new block immediately after the previous round's block is confirmed. My Q is this:  given how the SHA-256 works, we know that each new transaction added to a block that is being worked on will change the hash in a apparently random way.  To me this means, that every time a new transaction is added to the block that the PoW process of "guessing" the nonce needs to restart.

Given that the probability of finding the correct nonce will be marginally higher if you've already tested thousands of nonces for a given merkle root, at some point, is there an optimal number of transactions in a block, after which a miner would be better off not accepting new transactions to a block?

I recognize that this Q may reflect a fundamental misunderstanding of the PoW, so any guidance is very welcome.

Thanks,

Given that the probability of finding the correct nonce will be marginally higher if you've already tested thousands of nonces for a given merkle root

This isn't true. No block header is guaranteed to return a solution. (In fact, most do not.) Each attempt to hash a block header is equally likely to result in a valid block, regardless of how many nonces have already been checked.


Are virus signatures a serious threat to the bitcoin network? I read this in a forum post on another site. Here's my recap. But by "I" I mean me, not the original poster.

All transactions over the bitcoin network is stored as raw data forever in the distributed database (all bitcoin clients has the same copy of the database .. and if they lose by, e.g. by reinstalling the client, they'll synchronize with the distributed one again).

You can "inject" whatever 20 byte binary strings you want into the flat files (described here http://pastebin.com/ct2WHUK5 ). I'm pretty sure there are other ways to do it as well (apparently you can add text messages to transactions?.. I don't really know).

Now, here's my question. What'd happen if the bitcoin database were flooded with virus signatures? Is this a serious matter or just a "Meh"?

The pastebin you linked describes the harm caused as follows:

  What'll happen is that that will trigger the anti-virus program for
  every bitcoin client user that has an anti-virus program installed
  (and this won't go away ever.. you can't clean the database). Those
  virus signatures are harmless in their own, but they are something
  that anti-virus program use to recognize viruses. The anti-virus
  programs will think that the local bitcoin database is infected.

If a transaction manages to trigger an anti-virus alert for someone, I'd blame it on the anti-virus program being badly designed.

Yes it will probably be annoying for a bunch of users but Bitcoin already has a strict enough rule set to make this hard to happen. 20 bytes isn't a lot, for most computers, a single standard word character is 1 byte. If a virus program goes around looking for suspicious data that is 20 bytes long they will run into a lot of false positives. And I doubt that there is any seriously dangerous virus that is under 20 bytes in size.

TL;DR

It's very hard to pull off anything harmful, you will need to develop a virus that only takes up <20 bytes and can destroy a system. Otherwise anti-virus programs would show you a warning that you can possibly close/ignore, it's up to the anti-virus programs to be smart enough to discern.


Bitcoin Core Vs Daemon (Windows 10) I assume that if I've Bitcoin installed locally and I either run the GUI or the Daemon... It's the same wallet, data?
To that end, if I want to use the RPC interface, can i just use the GUI while developing (I like that at alerts on any action) rather than the daemon?
TL:DR: is the RPC 8332 port active when using the GUI, Vs the Daemon?

It's the same wallet, data?

This depends on your configuration like -datadir. This can be specified by command line, or something like a registry key value (when you are using Microsoft Windows).
Note that recent versions of Bitcoin Core supports loading multiple wallet at same time.

TL:DR: is the RPC 8332 port active when using the GUI, Vs the Daemon?

Yes, of course both bitcoin-qt and bitcoind supports JSON-RPC.
Edit: My apologies. For bitcoin-qt GUI, to enable JSON-RPC you must specify -server=1 in command line options, or edit bitcoin.conf to add server=1 to it. For command-line bitcoind, JSON-RPC is enabled by default. Thanks for Pieter Wuille for pointing this out.


How to import p2wsh-in-p2sh multisig as watch-only? I've created a p2wsh-in-p2sh multisig address using an offline node. I have the address and redeem script, as provided by bitcoin-cli addmultisigaddress on the offline node. How do I import this as a watch-only address on an online node, so I can use the online node to create transactions?

I have tried the following:

$ bitcoin-cli -testnet -rpcwallet=glacier importmulti '[{ "scriptPubKey": { "address": "2MzqiaZzpLT2SSBfsFqqo3FpZsP8g6WTvyC" }, "timestamp":"now", "redeemscript":"5221029f531503facdac2496f50a446d9bd29846a06a04a45e3845b656bb471df422fc2102e30787703a990e4015a2cb9071fcfd1c7d4641fb294e4b4c3f5f6b450a1925132102da28088a8022651171c4f13429b98709dabe13bc6da526537fdd2d0730dd2dbb2103286c96ecaa850a6ba43cc45fbb539c1fb1d65c23cc0f3cd09fcf9765826ff9de54ae", "watchonly":true, "label":"Glacier 2012-12-21" }]'
[
  {
    "success": true
  }
]

That seemed to work, but getaddressinfo doesn't look correct:

$ bitcoin-cli -testnet -rpcwallet=glacier getaddressinfo "2MzqiaZzpLT2SSBfsFqqo3FpZsP8g6WTvyC"
{
    "address": "2MzqiaZzpLT2SSBfsFqqo3FpZsP8g6WTvyC",
    "scriptPubKey": "a914534ee3ce21b8f805128f76b9d977e351bbbea20d87",
    "ismine": false,
    "iswatchonly": false,
    "isscript": true,
    "iswitness": false,
    "label": "Glacier 2012-12-21",
    "labels": [
       {
           "name": "Glacier 2012-12-21",
           "purpose": "receive"
       }
    ]
}

Shouldn't ismine and iswatchonly be true, and more details appear, such as hex and script?

Note that the glacier wallet was created with disable_private_keys=true. I'm running Bitcoin Core v0.17.0.1.

The issue here is that you've provided the p2wsh redeemscript as the script for the p2sh level of the nesting.  The redeemscript for the p2sh address is

0020dabea3445c14e4a08d6705db4373bef467d4c64e7c8ddf149be50670de6878ae

This can be seen by running

bitcoin-cli -testnet decodescript 5221029f531503facdac2496f50a446d9bd29846a06a04a45e3845b656bb471df422fc2102e30787703a990e4015a2cb9071fcfd1c7d4641fb294e4b4c3f5f6b450a1925132102da28088a8022651171c4f13429b98709dabe13bc6da526537fdd2d0730dd2dbb2103286c96ecaa850a6ba43cc45fbb539c1fb1d65c23cc0f3cd09fcf9765826ff9de54ae

With it, you can import the p2sh-p2wsh by setting the redeemscript for each level of the nesting :

$ bitcoin-cli -testnet importmulti '[{ "scriptPubKey": { "address": "2MzqiaZzpLT2SSBfsFqqo3FpZsP8g6WTvyC" }, "timestamp":"now", "redeemscript":"0020DABEA3445C14E4A08D6705DB4373BEF467D4C64E7C8DDF149BE50670DE6878AE", "label":"Glacier 2012-12-21" }, {"scriptPubKey": { "address": "2MzqiaZzpLT2SSBfsFqqo3FpZsP8g6WTvyC" }, "redeemscript": "5221029f531503facdac2496f50a446d9bd29846a06a04a45e3845b656bb471df422fc2102e30787703a990e4015a2cb9071fcfd1c7d4641fb294e4b4c3f5f6b450a1925132102da28088a8022651171c4f13429b98709dabe13bc6da526537fdd2d0730dd2dbb2103286c96ecaa850a6ba43cc45fbb539c1fb1d65c23cc0f3cd09fcf9765826ff9de54ae", "label":"Glacier 2012-12-21", "timestamp":"now"}]'
[
  {
    "success": true
  },
  {
    "success": true
  }
]

Then you'll see the expected result from getaddressinfo :

bitcoin-cli -testnet getaddressinfo 2MzqiaZzpLT2SSBfsFqqo3FpZsP8g6WTvyC
{
  "address": "2MzqiaZzpLT2SSBfsFqqo3FpZsP8g6WTvyC",
  "scriptPubKey": "a914534ee3ce21b8f805128f76b9d977e351bbbea20d87",
  "ismine": false,
  "iswatchonly": true,
  "isscript": true,
  "iswitness": false,
  "script": "witness_v0_scripthash",
  "hex": "0020dabea3445c14e4a08d6705db4373bef467d4c64e7c8ddf149be50670de6878ae",
  "embedded": {
    "isscript": true,
    "iswitness": true,
    "witness_version": 0,
    "witness_program": "dabea3445c14e4a08d6705db4373bef467d4c64e7c8ddf149be50670de6878ae",
    "script": "multisig",
    "hex": "5221029f531503facdac2496f50a446d9bd29846a06a04a45e3845b656bb471df422fc2102e30787703a990e4015a2cb9071fcfd1c7d4641fb294e4b4c3f5f6b450a1925132102da28088a8022651171c4f13429b98709dabe13bc6da526537fdd2d0730dd2dbb2103286c96ecaa850a6ba43cc45fbb539c1fb1d65c23cc0f3cd09fcf9765826ff9de54ae",
    "sigsrequired": 2,
    "pubkeys": [
      "029f531503facdac2496f50a446d9bd29846a06a04a45e3845b656bb471df422fc",
      "02e30787703a990e4015a2cb9071fcfd1c7d4641fb294e4b4c3f5f6b450a192513",
      "02da28088a8022651171c4f13429b98709dabe13bc6da526537fdd2d0730dd2dbb",
      "03286c96ecaa850a6ba43cc45fbb539c1fb1d65c23cc0f3cd09fcf9765826ff9de"
    ],
    "address": "tb1qm2l2x3zuznj2prt8qhd5xua773naf3jw0jxa79ymu5r8phng0zhqrkkueu",
    "scriptPubKey": "0020dabea3445c14e4a08d6705db4373bef467d4c64e7c8ddf149be50670de6878ae"
  },
  "label": "Glacier 2012-12-21",
  "timestamp": 1296688602,
  "labels": [
    {
      "name": "Glacier 2012-12-21",
      "purpose": "receive"
    }
  ]
}

Note, ismine is never true for scripts\addresses for which you can't sign completely on your own.


Difference between Outpoint structure returned from Blockchain.info and what is in the Protocol Specification if you follow this link, you will see a specific bitcoin address. If you look closely at the prev_out field, it is not an outpoint structure. Inside of the protocol specification under transactions, you can find the outpoint structure.

The outpoint structure is:

Field Size Description  Data type   Comments
32  hash    char[32]    The hash of the referenced transaction.
4   index   uint32_t    The index of the specific output in the transaction. The first output is 0, etc.

Where as prev_out in the above query is structure as:

prev_out:{"spent":true,"tx_index":50341289,"type":0,"addr":"15e2tHrbiUd4RxnBmHKYorMysyKtk1ohXF","value":2000000,"n":0,"script":"76a91432e17777e35dedafd578ffd90fa21ea8835dd50e88ac"}

Why is this different? What am I misunderstanding? Is blockchain.info not following the Bitcoin protocol for transactions on their json messages?

Why is this different?

Blockchain.info has an API that provides the same data, but not necessarily formatted in the exact same way. When bitcoin nodes talk to each other, they must use the protocol as specified in the link you gave, but the Blockchain.info API is just a utility for getting some data about the contents of the block chain.

  Is blockchain.info not following the Bitcoin protocol for transactions on their json messages?

In their API, technically, no. I'm sure they have more than a few nodes running, though, which do follow the bitcoin protocol. Their API can call upon these nodes and a few database to return the JSON with the requested info.


What is the difference between time, blocktime and timereceived? What is exactly the difference between

time, blocktime and timereceived

in transaction information returned by Bitcoind JSON RPC API? For example:

{
    "amount": 0.02,
    "blockindex": 45,
    "time": 1306179671,
    "category": "receive",
    "confirmations": 109244,
    "timereceived": 1306179671,
    "address": "1P5xanGEdgPKYNt4BnATambHpbZ2h89bYv",
    "txid": "91eb6cb34b9253cce0ab5da171a0f5aae9d3d36208e23062ba61cd9e21c09a3d",
    "blockhash": "0000000000002e65f5cc554e99c352af958a63f4be663627f2c569e5a996a03a",
    "account": "",
    "blocktime": 1306173564
}

timereceived is when your client first learned of the transaction. If you sent the transaction, it's the time when you sent the transaction. If you received the transaction, it's when your client first saw the transaction on the network.

time can be different from timereceived if you first learned about the transaction by seeing it in a block. This usually happens when your client was offline for a while and you're getting caught up with the block chain. In this case, time will use the block's timestamp if it seems reasonable. Specifically:

If the block timestamp is in the future, time will be the same as timereceived.
If the block timestamp is before the latest transaction in the wallet, time will be equal to the time of the latest transaction in the wallet.
Otherwise, the block timestamp will be used.

Transaction times don't change, even after a reorg, and new transactions will never have a time earlier than an existing transaction. This was not always the case (old versions preferred to use the block timestamp, which is usually more accurate), but the current method makes it easier to deal with transaction timestamps safely.


How to use Copay with Trezor? I have a trezor. Now I want to use it with Copay, how should I?
I would like to think the seed should stay in Trezor so I should not key in anything to Copay. But when I tried with the recent Copay version 3.7.0 it doesn't lead me anywhere.

How can I use Copay with trezor, specifically the later 3.7.0 version of Copay? (My trezor also setup today with its latest firmware).

Last time I check, Copay has not supported trezor on mobile devices yet. You can only use trezor with Copay on desktop. Just create new wallet with hardware wallet type.


Can I use a single Hardware Ledger for multiple coins I am about to buy a hardware ledger to store my coins but I was wondering if I would be needing one ledger per coin I own or if one can hold all or some.

Yes, you can use a single Ledger for multiple coins.

Here is the list of supported coins.


Viewing .bit Domain Names in Firefox I'm following the instructions on http://dot-bit.org/How_To_Browse_Bit_Domains and I have installed foxy proxy and I have gone to several .bit sites. But all of them I see are exactly the same. All of the .bit sites say the following?

Namecoin is a peer-to-peer, alternative distributed Domain Name System based on Bitcoin software. It provides cheap .bit domain names that are not regulated by any central authority.

Download the Namecoin client
Install the Namecoin client on your computer to access the Namecoin network and register your .bit domains.

Configure your DNS
Change your DNS settings on your computer or on your whole network to enable access to .bit websites.

Spread the word
Namecoin is still growing. Use the Facebook and Twitter share buttons on this page to spread the word and help it grow even faster!

Have the site owners not put any websites up and I'm seeing the default installation pages? Or have I configured my browser wrong?

I got it working. I had was using the proxy 178.32.31.43 and the port 80 and I changed Port 80 to port 8888 and it works –


Requested wallet does not exist or is not loaded I need to perform rpc requests per wallet. Here is my url
http://127.0.0.1:18332/wallet/another_wallet/wallet.dat

but I get error  Requested wallet does not exist or is not loaded
I run daemon with this command
bitcoind -daemon -rpcuser=myrpc01 -rpcpassword=password01 -testnet -datadir=/media/ax/6f6ceb40-fbbc-4959-b2b2-dbb1ae9ce24a/bitcoin/testnet3

So what the wallet path I should set for correct load?

If you are trying to load a wallet, then you do not need to be using a wallet specific endpoint. loadwallet is not actually a wallet RPC so it does not need the wallet specific endpoint.
If you are trying to access a wallet that has already been loaded, then you have the wrong endpoint. The endpoint does not include the wallet.dat file. Bitcoin Core gives wallets names based on the directory that contains the wallet.dat file, and when it creates wallets, it puts them in directories of the name that was provided. The wallet RPC endpoints work similarly - they use just the wallet name. So the URL to access a particular wallet should actually be
http://127.0.0.1/18332/wallet/another_wallet

Note that this URL does not have a trailing slash (/). If you have a trailing slash, then Bitcoin Core will incorrectly determine the wallet name to be another_wallet/ where it is actually another_wallet.


Modifying the last block in a blockchain I am trying to get my head around how blockchains work.

I have two blocks in my blockchain:

Block #0 has been added to the blockchain!
Hash: b3bc62c2b75e70fcc3fe709a5e724c7230d89bb70db17c1d2f5c3687b44b4c31
Block #1 has been added to the blockchain!
Hash: 76915298f65b261dbe8b5e2300c77b13966a8dd68175e49ffe5cbc59b055042d

The hash is derived from passing the block's timestamp, data and the previous block's hash through sha256. I understand that if I am in the middle of a blockchain and then try to modify the data the other blocks will be corrupt because the hash won't be correct. E.g. I modify block 2, change the data and even generate a new hash using the correct function, this will invalidate block 3's hash because the previous hash won't generate the correct hash for block 3.

However if I modify the last block in the chain how does it work? I can just change the data and generate a new hash, there is no next hash to verify it.

Any clarification on how this works would be great! Thanks!

It's true, you can have two different valid blocks (with different hashes) that both refer to the same previous block.  Call them A and B.  Then there are effectively two different branches of the block chain (so it's really a tree rather than a chain).  In such a case, each node must make their own decision as to which one to accept.  If both are at the end of the block chain, usually each node will choose the one they saw first.

In particular, a miner must decide which of A or B to use as the previous block hash in a new block.  Let's say the next winning miner chose A and mined a new block C.  Then future miners will prefer to mine on top of C instead of B, since the branch ending in C (which contains A) is longer (has more total proof-of-work) than the one that ends in B.  In the long run, the branch containing A will probably be considered as the "true" blockchain.  B becomes an orphan block and is disregarded.

If B contained transactions which A did not, and they are otherwise valid, those transactions can be included in C or some later block in the dominant branch, so they are not lost.


How to limit the debug.log file while running bitcoind? The debug.log file is getting pretty big on bitcoind. How do you limit the size of the file? I'm on Ubuntu 12.

You can use logrotate.
Create a file named bitcoin-debug in /etc/logrotate.d.

This is the contents:

/home/bitcoin/.bitcoin/debug.log
{
        rotate 36
        monthly
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
        postrotate
                kill -HUP `cat /home/bitcoin/.bitcoin/bitcoind.pid`
        endscript
}

Replace /home/bitcoin/.bitcoin with the actual path to your bitcoin directory.

The full logrotate manpage is here: http://manpages.ubuntu.com/manpages/jaunty/man8/logrotate.8.html

In ubuntu the logrotate daemon manages many different log files.  In the /etc/logrotate.d folder, each file contains instructions for the logrotate deamon.  Adding this file tells logrotate that you want to start a new log file once a month. The other options tell it to compress the old logs after a day and to keep only 36 months worth (3 years) of logs.

I originally found out about logrotate from this thread: https://bitcointalk.org/index.php?topic=130533.0

Another thing to bear in mind is that given this sends the SIGHUP signal to the bitcoin server, if you happen to be running bitcoin within gdb, it becomes necessary to tell gdb to ignore the SIGHUP signal, so far example, bitcoind can be run using: gdb $HOME/.bitcoin/bitcoin-qt -ex 'handle SIGHUP nostop' -ex run


Bitcoin regulation by country I am looking for a straightforward Bitcoin regulation list accepted in each country. About how it's legal, illegal or denied and if it's legal is there any specific rules in each country?

There is a page on Wikipedia that tracks Bitcoin legality by country or territory.

Another one can be found on Coin.dance.


How to install Hard Fork of Bitcoin, such as Bitcoin Cash and Bitcoin Gold? Just like the title, how do I install hard fork of Bitcoin, such as Bitcoin Cash or Bitcoin Gold?

I would like to install Bitcoin Cash core in Ubuntu 16.04. It seems like there is not a single authoritative implementation according to this answer from "Install Bitcoin and Bitcoin cash".

But, I feel really confused by the name of "BitcoinABC" and "BitcoinUnlimited".

Are they just two different command line interfaces for Bitcoin Cash like Geth and Parity when installing Ethereum?

OR

Are they just two different ways to install Bitcoin Cash? Are they synchronizing the same blocks from bitcoin network?

I have been searching and trying to clarify things that I don't understand.

More I search, more I feel confused.

Does any know about this? I will be appreciated if you clarify things that you feel what I don't know about.

I agree with you, that from a marketing standpoint, the different names used by the various implementations of the Bitcoin Cash fork are confusing.

First, let's understand what a fork is. The rules about what constitutes a valid block, to be added to a blockchain, are set in the program code which miners follow. They compete to be the next to validate a transaction block and add it to the blockchain.     A fork occurs when these rules are changed by some, in a way which is incompatible with the old rules. A subset of miners starts following the new rules, and the rest of the miners keep following the old rules.  The result is that each group of miners starts building distinct chains which fork from a common ancestor chain.     So, if someone holds coins the original common ancestor chain, those coins are now valid on both forks, and can be spent once in each fork. This is because as far as one chain is concerned, spends on the other chain are not visible - they don't exist.

The main difference between original Bitcoin and Bitcoin Cash is that the Bitcoin Cash chain allows transaction blocks to be up to 8 MiB in size, instead of being limited to 1 MiB.

To install the Bitcoin Cash fork, one way is with Bitcoin ABC, "a full node implementation of the Bitcoin Cash protocol". In other words, Bitcoin ABC follows the rules of the Bitcoin Cash fork. In the Ubuntu 16 "Xenial Xerus" command line:

# git clone https://github.com/Bitcoin-ABC/bitcoin-abc.git

This clones the official Bitcoin-ABC repository into your machine. Instructions for installing all the pre-requisite pacakges needed to compile the programs will be in ~/bitcoin-abc/doc/build-unix.md; read this file and make sure your machine is ready for compilation:

# ./autogen.sh
# ./configure
# make

Note: on a mult-core CPU machine, you may use 1.5x the number of cores to speed up compilation. For example, on a 4-core machine:

# make -j 6

Now, in the ~/bitcoin-abc/src directory, after compilation, you will have the server binary: bitcoind, the client: bitcoin-cli and another binary to create, parse, or modify transactions: bitcoin-xt. For convenience, you can copy these to a folder visible to all users, such as /usr/local/bin

sudo cp ~/bitcoin-abc/src/bitcoind /usr/local/bin
sudo cp ~/bitcoin-abc/src/bitcoin-cli /usr/local/bin
sudo cp ~/bitcoin-abc/src/bitcoin-tx /usr/local/bin

Then, as a regular user, create the .bitcoin folder

mkdir ~/.bitcoin

and create a bitcoin.conf file

vim ~/.bitcoin/bitcoin.conf

#------------------------------
server=1
daemon=1
listen=1
maxconnections=16

rpcuser=bitcoin.rpc
rpcpassword=<some-secret-password>
rpcport=12345
keypool=256
#-------------------------------

Then you can run the bitcoind binary.

#bitcoind

and start using it via the command line client

#bitcoin-cli getinfo

{
  "version": 160200,
  "protocolversion": 70015,
  "walletversion": 60000,
  "balance": 1.61803398,
  "blocks": 504043,
  "timeoffset": 0,
  "connections": 8,
  "proxy": "",
  "difficulty": 136961411965.4142,
  "testnet": false,
  "keypoololdest": 1376702008,
  "keypoolsize": 4096,
  "unlocked_until": 0,
  "paytxfee": 0.00000000,
  "relayfee": 0.00001000,
  "errors": ""
}


Why is a GPU a better tool for bitcoin mining than a CPU and is an FPGA better than both? I was looking into the best tools for bitcoin mining and found out that GPUs are a better tool for bitcoin mining than CPU's. What is the reason for this?

furthermore, I found dedicated chips that can only be used for bitcoin mining. How come that these relative small chips are far superior to the best intel/amd/Nvidia chips?

Bitcoin mining is essentially just the repeated calculation of sha256 checksums. Given that sha256 is a fairly simple algorithm that uses only basic integer calculations absolutely any processor core should be capable of churning out sha256 checksums very quickly and any added complexity beyond the basic instructions required for sha256 is wasted. To that end the ideal candidate for mining hardware should have the least complex cores necessary for sha256 but the largest possible number of cores.

Your CPU has probably between 2 and 8 cores, each of them insanely complex. Your GPU has comparatively simple cores, but probably has over a thousand of them. Still, even GPU cores are more complex than they need to be for sha256, which is where FPGAs and ASICs come in.

An ASIC is a custom chip, designed to do only one thing - in this case it's designed to perform two rounds of sha256. It has only the necessary components for its one and only purpose. An FPGA is a device commonly used to prototype ASICs, it's basically a chip whose components can be rearranged to mimic another kind of chip. Because they retain this multi-purpose capability FPGAs are significantly less efficient than ASICs.

The only (temporary) benefit we saw from FPGAs is the cost curve. FPGAs are pre-manufactured consumer devices, you can buy just one of them and they usually don't cost a huge amount of money. An ASIC is something you have manufactured, and the minimum order size is usually absurd, requiring a huge up-front investment to get your chips made.


What would happen if one person mined all unmined bitcoins? Let's say that, hypothetically speaking, someone had the mining power to mine all unmined bitcoin(I believe around 6 million bitcoin, correct me if I'm incorrect). Would they confiscate it off of them? Would there be some kind of software barrier? which would mean that even if you had such great mining power, you wouldn't be able to mine so many bitcoins.

Then all those bitcoins would belong to that person.  There's nothing in the current Bitcoin protocol that prevents this.

I don't know what you mean by "would 'they' confiscate it".  From the point of view of the Bitcoin protocol, nobody has the authority to confiscate bitcoins.

Of course, if this happened, it would mean that miner would be able to unilaterally decide which transactions would be confirmed, and they could also reverse past transactions by re-mining part of the chain.  They would be able to allow people to double-spend.  This might well cause other people to lose interest in using Bitcoin, since its security would be undermined, and this could cause the currency's value to fall, perhaps to zero.


Can I change wallet without shifting funds I have some fund in Multibit, a wallet that has now become almost unusable. I do not want to risk transferring all my bitcoins to another non-Multibit wallet because my last transaction is still stuck in "sending" mode weeks after I sent some bitcoin.

So I am wondering if it is possible to sign up with another wallet provider and somehow recover my Multibit funds directly from the blockchain.

Yes you can, depending on what version of multibit you have, you can do the following :

Multibit HD: You should have the backup seed words. You can directly use those seed words / master public key to create a new wallet like mycelium/electrum
Multibit Classic: Export out all the private keys https://multibit.org/help/v0.5/help_exportingPrivateKeys.html. You can import these private keys into the new wallet


Private key exported from Electrum, unable to recreate Address with Python I have created a new Electrum wallet, and here is an address:

1JkZLnmFfpVFLT2ZMtKzc6BuXMdmY41EHA

By right-clicking on it, I choose "Private key" which gives:

Kzuucz58MiTbbedeVuqBaPYwG1TQrV3n2NYU2dJRZ7HEHnHsUXWx

Now I want to be able (to learn how it works) to go from this private key to the address, via elliptic curve multiplication.

Here is what I tried:

import bitcoin #pybitcointools
import base58
import binascii

pvt = 'Kzuucz58MiTbbedeVuqBaPYwG1TQrV3n2NYU2dJRZ7HEHnHsUXWx'
pvtdecoded = base58.b58decode(pvt)
pvthex = binascii.hexlify(pvtdecoded)[2:-8]     # remove the first initial byte for version and 4 final bytes for checksum
pvt2 = bitcoin.decode_privkey(pvthex, 'hex')    # decode as a decimal

# generate pubkey from pvtkey with elliptic curve multiplication
public_key = bitcoin.fast_multiply(bitcoin.G, pvt2)
addr = bitcoin.pubkey_to_address(public_key)
print addr

which gives: 1LNSuE4NKHTyHygeKwnU1equ7MjPMhayxB which is not the original address.

What's wrong? How to recover the original address (1JkZLnmFfpVFLT2ZMtKzc6BuXMdmY41EHA) from the Private key by using elliptic curve multiplication?

Edit: As Kz....Wx private key looks like a WIF-compressed one, I tried to replace:

pvt2 = bitcoin.decode_privkey(pvthex, 'hex')    # decode as a decimal

by

pvt2 = bitcoin.decode_privkey('Kzuucz58MiTbbedeVuqBaPYwG1TQrV3n2NYU2dJRZ7HEHnHsUXWx', 'wif')

but then after elliptic curve multiplication, it gives another address, which is still not the good one! (18dFF3EQoPxR44TygdGxHPMe3LSLFeQe4U)

In both cases, you are not generating the address that corresponds to the compressed public key.

In the first case, you are creating what looks to be an invalid address. At the very least, the private key it is using is incorrect because it has the compression byte. This will change the value that you get for the private key when it is decoded. In order to get the same outcome as the second case, you would need to drop an additional byte from the decoded WIF key as that byte specifies compression. The key you are using there is 33 bytes rather than the 32 bytes for actual private keys.

In the second case, you are not creating the compressed public key to generate the address. It is still using the uncompressed public key. Instead of using fast_multiply and creating the public key yourself, you should be using privkey_to_pubkey. fast_multiply is a mathematical operation, it has no concept of compressed public keys. However privkey_to_pubkey does so it will create the proper public key. Then you can use that public key to generate the address.

Instead of doing

public_key = bitcoin.fast_multiply(bitcoin.G, pvt2)

you should be doing

public_key = bitcoin.privkey_to_pubkey(pvt)


What is the largest golden nonce found? With all the stats and metrics out there I was surprised I could not find this out. Has anyone ever determined the highest nonce in a block?

Through block 512961, the highest (little-endian) nonce value to date is 4294956079 (0xffffd42f), in block 219742.

The lowest is 1082 (0x0000043a), in block 67071.

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


What does the US government do with seized coins? It was reported today that the US government shut down the web site Silk Road, where people bought and sold things (allegedly including illegal drugs) using Bitcoins.  The operator was arrested, and BTC 26000 was seized.  (Source: New York Times).

A few months ago, it was also reported  that the US Drug Enforcement Agency seized BTC 11.02 from a person suspected of buying or selling illegal drugs.

Is anything known about what the US government (or any other government) does with seized coins?

Some possibilities:

Sell them on an exchange for USD, and turn the proceeds over to the Treasury
Sell them at public auction, as is commonly done with other seized property
Use them in future sting operations
Do not return them to circulation, but hold them indefinitely
Destroy them by transferring them to an address with no private key

Property seized is held until a conviction, then sold at auction.   If there is no conviction, property may or may not be returned to the rightful owner.


Does BTC-E have an API for alternate currencies? BTC-E appears to have an API available at https://btc-e.com/api/1/ticker but this only lists the BTC/USD pair data. They also offer pairs of BTC against alternate currencies like Ixcoin and Tenebrix. I've tried the obvious stuff a la https://btc-e.com/api/2/ticker but no dice.

I'll take an API from any other multi-currency exchange as well, really I just need a way to grab price easily from code without having to scrape HTML and deal with regex.

The URL to the api's for other currencies are:

https://btc-e.com/api/2/1/ticker - BTC/USD
https://btc-e.com/api/2/2/ticker - IXC/BTC
https://btc-e.com/api/2/4/ticker - I0C/BTC
https://btc-e.com/api/2/5/ticker - SC/BTC
https://btc-e.com/api/2/6/ticker - SC/USD
https://btc-e.com/api/2/7/ticker - GG/BTC
https://btc-e.com/api/2/8/ticker - TBX/BTC
https://btc-e.com/api/2/9/ticker - FBX/BTC
https://btc-e.com/api/2/10/ticker - LTC/BTC
https://btc-e.com/api/2/11/ticker - RUC/BTC
https://btc-e.com/api/2/12/ticker - RUC/USD
https://btc-e.com/api/2/13/ticker - NMC/BTC
https://btc-e.com/api/2/14/ticker - LTC/USD
https://btc-e.com/api/2/15/ticker - CLC/BTC
https://btc-e.com/api/2/16/ticker - DVC/BTC

In the links below change the 1 to a number anywhere between 1-16 to match the category above.

Api for trades: https://btc-e.com/api/1/trades

Api for depth: https://btc-e.com/api/2/1/depth

Api for ticker: https://btc-e.com/api/2/1/ticker

By: dodoking


How much hashpower would I require to surely mine one block per day? How much hashpower would I require to surely mine one block per day?

Divide this number by the number of seconds in a day (86400) to get the required number of hashes per second to solve one block per day on average. You might get more than one block on some days and no blocks on others. It's random.

Currently, you'd need about 931 TH/s, which is a ridiculous amount of mining power.


How much bandwidth needed for bitcoin bigger blocks If the Bitcoin blockchain would support 2000 transactions per second, how big would the blocks need to be (with segwit at 100% lets say), and most importantly, how much bandwidth would be necessary for a miner to propagate the blocks to 8 peers?

If you consider that Bitcoin currently does 2000 transactions each 10 minutes, you'll need blocks 600 times bigger, or more-or-less 1.2 GB each. Now you need bandwidth sufficient for that peer to transmit 9.6 GB each 10 minutes (1.2 GB * 8 peers -- I have no idea of what you meant by "necessary" bandwidth).

That's doable if you only have one miner in the entire network.


What Does "Activation" Actually Mean In Bitcoin? During the multiple issues with Bitcoin this year with soft and hard forks, and Segwit, I have read as much as I can about how all these changes are "deployed", eg BIP9, BIP91, BIP148, BIP's 141-146.

However I am still not clear about some of the terminology, such as "locking in", "signalling", "activation", "deployment".

I understand Segwit was implemented in v0.13.1 (and above) of Bitcoin Core which was released on 27/10/2016.

So all the Segwit changes have been in the Bitcoin Core software since that date ?

So when "activation" of Segwit occurred - did that mean a flag within the Bitcoin client, say "ACTIVATION_FLAG", became true and then the Segwit functionality thus started to run - because it is contained inside an "if" block :-

if (ACTIVATION_FLAG) {
    do Segwit stuff
}

However Segwit is a complex upgrade to Bitcoin so there must be many places where changes are made to Bitcoin for Segwit - so how many such "if" blocks are there ?

Can someone give me some links to where these "if" blocks are located in the Bitcoin source code?

However Segwit is a complex upgrade to Bitcoin so there must be many places where changes are made to Bitcoin for Segwit - so how many such "if" blocks are there ?

As of writing, there are 23 to 34 places where behavior changes based on whether segwit is active, depending on how you count. (e.g. if you pass a boolean to a function, and that function contains an if, and the function return value is passed to another if, is that 1 or 2 if statements?)

If you have a copy of the repository you can find them with the following commands:

grep -RI "SEGWIT" * | grep THRESHOLD_ACTIVE
grep -RI "fPreSegWit" *
grep -RI "IsWitnessEnabled" *
grep -RI "fWitnessEnabled" *
grep -RI "witnessEnabled" *


Why does decoded block data not match coinbase transaction input? I am looking at the specific block at height 680175.
Via bitcoin-cli getblock 00000000000000000004dbd66fa71fdcd62658bf8c8e2e153521257ad5858c71 0 I obtained the serialized, hex-encoded block data. According to the section Serialized Blocks the txn_count starts at Byte #81. Following the description of CompactSize Unsigned Integers I get:
In [115]: int.from_bytes(byte_arr[80:81], "little", signed=False)
Out[115]: 253

In [116]: tnx_count = byte_arr[81:83]
     ...: tnx_count = int.from_bytes(tnx_count, "little", signed=False)

In [117]: tnx_count
Out[117]: 1702

There are indeed 1702 transactions which can be verified via ./bitcoin-cli getblock 00000000000000000004dbd66fa71fdcd62658bf8c8e2e153521257ad5858c71 2 in the attribute nTx.
Now I know that the rest of the block data is the transactions' part. According to the section Raw Transaction Format the first 4 bytes are the version:
In [118]: tnx_part = byte_arr[83:]

In [119]: version = tnx_part[:4]

In [120]: int.from_bytes(version, "little", signed=False)
Out[120]: 1

This seems to be correct, too. So, the next bytes determine the number of tx_in count, but there I get 0 which is false. And the input of the coinbase transaction does not start with a 32-byte null:
In [121]: int.from_bytes(data[4:5], "little", signed=False)
Out[121]: 0

In [122]: data[4:10]
Out[122]: bytearray(b'\x00\x01\x01\x00\x00\x00')

Am I missing something? The input of the coinbase transaction seems not to match the description.

Segwit changed the transaction format. This new format is specified in BIP 144. This new format is actually a modification to the original transaction format. The changes are just additions to it.
Specifically, what you are missing is that the field immediately following the version number is a single 0 byte (referred to as the marker byte), instead of the input count. This was done specifically to make a transaction appear as if it has no inputs to a legacy transaction parser. Following this marker byte is a flag byte, which currently is a single 1 byte. Then you have the input count, inputs, output count, and outputs as was previously. The last change is that following the outputs, instead of the lock time, there are multiple arrays containing the witness data for inputs. Lastly the locktime ends the transaction as previously.


How to Verify P2SH Signature I am trying to debug an issue where i believe i might have a bad signature but i am trying to figure out how to approach it.

What is this a signature of. Private key + what (redeem script? entire raw hex?)
How can i verify that this is a correct partial signature (N 2 of 3) P2SH transaction.

I have 3 signatures. I want to test each signature separately to see which are bad or good. How would one approach that? I have read through many posts here but i have not found any solutions.

To answer your first question:

A P2SH transaction activates a special rule in Bitcoin nodes. When a Script_Publick_Key comes with this pattern:
OP_HASH_160, <HASH>, <OP_EQUAL>
 then the node runs the information in a different way.

First, it runs as it usually does. It puts the ScriptSig on top of the Script_Public_Key. The ScriptSig must follow this form:

OP_0
<Signature 1>
<Signature 2>
...
<Signature (m)>
<SerializedRedeemScript>

Due to Script rules of evaluation, the first item to be evaluated is going to be the <SerializedRedeemScript>. If the hash160 of this serialized script matches the hash in the Script_Publick_Key then the first round is valid and older nodes would stop here. However, BIP0016-compliant nodes will later interpret the serialized version of the redeem script (<SerializedRedeemScript>) as actual Script commands, and the process will repeat this time with the redeem_script commands and the ScriptSig but without the <SerializedRedeemScript> since it was already consumed during the first round of validation. So, let's talk about this redeem_script.

The redeem script must specify how many private keys can sign a transaction (n), how many signatures are necessary to legitimately sign a transaction (m), and all the public keys that corresponds to the private keys that can sign the transaction. The form of the redeem script is as follows:

<OP_m>
<PublicKey 1>
<PublicKey 2>
...
< PublicKey (n)>
<OP_n>
<OP_CHECKMULTISIG>

Since we have only consumed the <SerializedRedeemScript> in the first round of validation, then we still have our OP_0 and signatures left, and the final stack of commands, which is a combination of the redeem script and what is left from the ScripSig, will look like this:

OP_0
<Signature 1>
<Signature 2>
...
<Signature (m)>
<OP_m>
<PublicKey 1>
<PublicKey 2>
...
< PublicKey (n)>
<OP_n>
<OP_CHECKMULTISIG>

The first OP_0 is necessary although it has no meaning at all. It is necessary because of a bug called Off-By-One bug. This was done by accident by Satoshi Nakamoto.

The signatures and public keys will be evaluated by the <OP_CHECKMULTISIG>.

How can i verify that this is a correct partial signature (N 2 of 3) P2SH transaction.

If you want to check signature by signature, then you can try to do this by first calculating the transaction hash (z) and then checking your single signature with each one of the public keys from the redeem script through OP_CHECKSIG instead of the OP_CHECKMULTISIG. If your signature is valid for a specific public key then your signature is valid. If your signature is not valid for any of the public keys then it is not valid.


Litecoin privacy techniques What are the privacy techniques that used with Litecoin? and what are the differences between Bitcoin and Litecoin in privacy techniques?

There is no substantial technical difference between Litecoin and Bitcoin transactions.

Litecoin does not offer any additional "privacy techniques". The only differences are:

address scheme: Litecoin addresses start with an L, Bitcoin standard addresses start wtih a 1.
Volume: Bitcoin volume is much higher, so it might be easier to obscure a payment among the other transactions.
Attention: Bitcoin might have more attention of law enforcement.

Note: The last two points are based on speculation.


What large and well known companies directly sell BTC? At one point TangibleCryptography offered direct sales of Bitcoins in exchange to USD wire transfer, at competitive rates.

Is there a list of active trusted companies that offer this service?

We have a long history in bitcoin...

bitinstant.com

We offer many options and transaction types.  :)


How does a full node benefit from receiving a block with a version number in its header? Block headers are special because they're synced by SPV wallets. They're also part of the mining algorithm used by miners, which can enable controversial things like ASIC boost.

However, in the case of Segwit, the block version number was chosen to indicate the Segwit softfork. What was the advantage of including this value in the block header's version number field as opposed to in the coinbase transaction?

To be specific, does the Segwit soft fork affect the work done by SPV wallets or by ASICs, other than preventing ASICBoost in the latter case?

If the Segwit soft fork was put in the version number because "thats what version numbers are for" and "ASIC boost is bad", I'm okay with that being the reason. I even consider that a technical reason -- there may be a future soft fork that affects SPV wallets that those verison numbers are needed for, and putting the Segwit value in the block header helps protects those values (as opposed to sacrificing them to ASICboost). I'm just trying to understand what kind of soft forks might affect SPV wallets, or if I'm missing anything else.

I thought Segwit was about transaction ordering in the actual block, which could indicate the Merkle Root part of the header should be processed differently by full nodes. But if the full block is being received anyway, with the coinbase, why couldn't the segwit indicator just be put in the coinbase? (Aside from protecting those values)

I would just like to know whether I'm missing anything here. Other than protecting those values for future forks, does Segwit require any special consideration by SPV wallets / miners?  Is there any reason why the coinbase transaction couldn't be used for this particular soft fork other than future technical developments?

The block version number has traditionally been the way for miners to signal their readiness to enforce a soft fork. The version number was likely used because of its historical use for soft fork signalling. Also, the version number does not indicate that a particular set of rules are active for a block. In fact, the version bit used by Segwit is no longer set by miners (besides those using ASICBOOST) since Segwit has activated.

Additionally, the version number helps SPV wallets know when segwit is active so that they can use it. Otherwise SPV wallets would have to download entire blocks in order to examine the Coinbase transaction in order to do so, which would largely defeat their primary benefit.

Full nodes don't really benefit from the version number being used as the signal. However when deploying any kind of fork, consideration must be made for everyone in the ecosystem. Using the version number does not hurt full nodes, has some extra benefits of not taking up block space for transactions themselves, and lest SPV wallets know when the fork activates.

  I thought Segwit was about transaction ordering in the actual block

No. Segwit does not effect transaction ordering at all. It changes the format of transactions and how certain output scripts are validated.

  Other than protecting those values for future forks, does Segwit require any special consideration by SPV wallets / miners?

Yes. SPV wallets need to know when Segwit activated so that they know when they can make and accept transactions containing Segwit inputs and outputs.


How long does it take to recieve bit coins? I sent bitcoin almost 30 mins ago and still haven't received them yet how long does it take

The amount of time it takes for your transaction to be processed all depends on the rate at which blocks are being mined.

When you spend your bitcoins, they go into the mempool, a place where all incoming transactions wait to be picked up by miners and put into a block. Sometimes, your transaction can get verified immediately, just because a miner is lucky and finds the golden nonce extremely fast. Other times, it can take miners tens of minutes to find the nonce.

While this probably does not apply to your case, if you are spending a large quantity of bitcoins to purchase an item from a vendor, the vendor will often wait till your transaction is 6 blocks deep in the chain to make sure it does not get orphaned or someone attempted to create a fraudulent chain.


How is Ethash a 'memory hard' algorithm if it utilizes peak GPU memory bandwidth? According to the Ethash algorithm described here, the computation for each nonce requires a loop of 64 iterations, where each iteration reads a chunk of 128 bytes from a pseudo-random location in memory.

Reported hash rates for the NVIDIA GTX 1070 are around 30MH/s, which means that every second this GPU is reading 30.000.000 nonces x 64 iterations x 128 bytes from memory. That is 245.76 GB/s.

I was unable to find the peak memory bandwidth that the 1070 is capable of, but this thread suggests it should be 197.76 GB/s, and Ethash is achieving even more than that. Howcome?!

Also, I would expect that reading from many different memory locations (as opposed to sequential reads) would result in a very inefficient use of memory, but it seems it doesn't really matter?

I'd appreciate if someone could clear this up, thank you!

"Memory hard" means the algorithm is designed to use a lot of memory; its purpose is to prevent an ASIC being developed that would overwhelm the existing CPU/GPU-based mining.

This site indicates the memory bandwidth for a GTX-1070 is in fact 256GB/sec, which fits your calculation.


What is a block withholding attack? How can a block withholding attack be performed, what would be its purpose and who is it a danger to?

Edit: when I posted this I was thinking about withholding a block you mined in a pool. But withholding blocks can form the basis for many different attacks. I think this is still useful as a broad question. It is a central concept in bitcoin security.

The simplest form of it called Finney attack, named for Hal Finney who first described it. The attack is variation of a double-spend attack involving accepting 0-confirmation transactions.

An attacker would generate a valid block but will not broadcast it, and then broadcast transaction A as a payment for a good or service. A merchant will see transaction A with nothing conflicting with it and accept the 0-confirmation transaction. Right after that the attacker would broadcast the generated block with transaction B which will conflict with transaction A, the Bitcoin network will accept his block and invalidate transaction A.

The attack is quite costly because there is a time gap between generation of the block by the attacker and completing transaction A, during which someone else on the network could generate a valid block and broadcast it, thus invalidating the valid block generated by attacker. Therefore it is practical only if the merchant sells the product online and it could be release immediately, e.g. a key for a software product.

A general form of this attack was described by Satoshi Nakamoto: White Paper, section 11. In theory, an attacker could pre-generate any number of blocks, e.g. if a merchant requires 1 confirmation before releasing a product an attacker would pre-generate 2 blocks ahead of the network and only then broadcast transaction A to double spend. But with each block the cost increases exponentially, and the practice of accepting 6 confirmations before releasing the purchase makes this attack possible only in case where the attacker has close to 50% of network hash rate or more.


CoPay Limits per day Does anyone know if there are limits to the amount of BTC that can be moved in and out of a Copay Multi sig wallet please either on a daily basis or in total or both ?

There are no limits set by the wallet itself. As long as the co-signers agree you can do what you like.


What is the maximum number of output addresses I can send to with one bitcoin transaction? I'm looking to make a faucet website, but was wondering what is the maximum number of output addresses one can send to with one bitcoin transaction?

Today the modern Bitcoin-qt client does not relay transactions with more than 200 outputs. But this is not protocol restriction. You can create transactions up to 100k size, which gives you 2500-3000 outputs (try to count the exact number yourself).

For example, tx https://blockchain.info/tx/0313e6552a5337de92c475c0dbbb0e351a1525b0f202beb9d4c75b3a5b114bf3 has 2501 outputs and was successfuly mined 3 days ago


To be blunt bought bitcoin in 2009 at 25 cents have not touched it I am hoping you can help
I read through a few of you answers to other inquiries and as per my research you are very well versersed.
I acquired Bitcoin back when it first came out of trading at 0.0008 I cant remember the catalyst that popped it out bu was running equities trading desk at the time and was thinking it is stupid not to.
Peer pressure said no but still bought $25 at 8 cents it was in june 2009.  Our tech fellow got it done for me and asked if I wanted a wallet and my limited understanding said I wanted it to stay on the block chain.  Perhaps he did out in the Qt wallet at the time.
I have left it alone for so long but now worth a bunch so wanting to access it with prudence, if I can and it is still there.
I was smart enough to call my mom and have here put the codes in a family address book my sister happened to be there so it ain't no dream.
I will look back for a response and lets hope for a great end to the story.
Excuse the brevity and spelling errors
Regards,
Rainbow Dash

Spending Bitcoins requires the knowledge of the private key corresponding to the address holding the funds. These keys are managed by each user individually. Without the key, the coins are rendered unspendable.
Given the lack of details, I assume that you no longer hold a copy of the wallet that held the private keys. If that is the case, your funds are lost. If my understanding is incorrect, please edit your question to add more details.


what's the difference of the two trading engines? Hi was reading through the wiki about exchanges,

https://en.bitcoin.it/wiki/Trading_bitcoins

it looks there are two kinds of them, what's the difference?

The price in real-time trading exchanges is determined dynamically based on supply and demand. People sell and buy which influences/determines the price fluctuations.

The price in fixed rate trading exchanges is whatever the seller chooses to; e.g. selling 1btc for $450 each. That price is usually determined by consulting real-time exchanges and the seller will update the price accordingly.


Bitcoin fork BTC and BCH BTC holders received 1 BCH for each BTC during the fork in August. How will be the case in November? Will BTC holders and BCH holders receive 0.5 new coin for each BTC and BCH?

The potential fork in November does not affect the BCH-chain at all.
Since the new coin does not have a name yet, I will just call it BFC for now.

If you have 1 BTC now you will have 1 BTC and 1 BFC in November.
If you have 1 BCH now you will have 1 BCH and 0 BFC in November.
If you have 1 BTC and 1 BCH now you will have 1 BTC, 1 BCH and 1 BFC in November.

Nobody knows if the new BFC coin will stay like BCH or if nobody supports it (= nobody mines it, it's worth nothing, not listed in any exchanges, ...).