Who maintains list of bitcoin nodes and aren't they a weak link in the security of the system?

First of all, there isn't really an "official" list of DNS seeds.  You're probably thinking of the list used by Bitcoin Core.  But other clients are free to choose a different list, or to discover peers in an entirely different way.  Users of Bitcoin Core are also free to reconfigure their software to use a different list.  So this list is merely the default for one particular client.

This list is chosen by the Bitcoin Core developers, just like everything else in the Bitcoin Core source code.  You can read here about the criteria they (claim to) use when selecting nodes for this list.

It's true that if the Bitcoin Core developers decided to be evil, they could modify this list to only have DNS seeds that will only return addresses for malicious nodes controlled by them.  That would allow them to mount a Sibyl attack on any user of Bitcoin Core.

But if you think about it, if the Bitcoin Core developers decided to be evil, they could do things that were much worse, much more easily.  They could just put in some code that would immediately send all coins in the wallet straight to them, as soon as the software is run.  Why bother messing around with DNS seeds and all that?

And if you think some more, this same sort of risk exists with every piece of software you ever use: you are trusting that  the software doesn't contain something evil.

So what's our protection against this?  Bitcoin Core is open source.  You, and everyone else, can see all the changes that have been made up till now, and you can judge for yourself whether any of those changes have been evil.  You, and everyone else, can test the DNS seeds provided in the list, and see whether they appear to be returning well-behaved nodes.  If they didn't, there's a good chance that you'd find warnings about it elsewhere on the Internet, just like you probably would if the Bitcoin Core developers had made any other evil change.

If all the currently listed DNS seed operators suddenly decide to conspire to be evil, the situation is similar: people will probably notice rather fast, and you'll hear about it.  But the Bitcoin Core developers choose seeds that, as far as they can tell, are operated by independent people who seem to be individually honest and have no particular reason to conspire.

If, on the other hand, an individual DNS seed operator decided to turn evil, without the cooperation of the Bitcoin Core developers, the risks are much lower.    As long as at least honest seed remains, you'll likely connect to some honest nodes in addition to the dishonest ones.  And if you successfully connect to at least one honest node, a Sibyl attack doesn't work: the honest node will send you the proper blockchain, and you'll know from its higher difficulty that it is the right one and the others are fake.

In general, you want to be careful throwing around terms like "trustless and secure".  These terms are never absolutes.  You always have to trust somebody for something, and there are always ways for security to be violated.  The best you can do is to try to understand exactly who you are trusting, what you are trusting them to do, and what evidence you can use to decide whether they are worthy of that trust.


Is it possible to run a miner to confirm transactions for a target address?

Yes, there are a few ways you can do this.

First, you could solo mine using GBT from Bitcoin-Qt, and prioritise your own transactions. But unless you find a block, this does no good.

Second, and perhaps easier, you could use a pool like Eligius which offers prioritisation as a perk to its miners.


The mempool of all nodes is different, but this isn't an issue. There will always be some inconsistency due to latency, network conditions, and differing configurations. This doesn't measurably impact your income and won't effect the validity of blocks you produce.


How can one full node know whether other full nodes added certain block to their blockchain?

There is no guarantee that when a full node adds a block to its main chain that other full nodes have done so. However there is no need for a node to know that in order to add a block to its main chain; it simply has to validate the block according to its consensus rules before adding it to its main chain. If everyone follows the same consensus rules, then all nodes will converge to the same blockchain. The blocks in a blockchain are defined by the consensus rules.

Additionally, it is generally safe to assume that the peer that sent a node a block also added that block to its main chain. However that does not necessarily mean that a node should also add the same block; it must still verify the block because that peer could be following different consensus rules.


What's the point of the "clean jobs" parameter in Stratum's "mining.notify" protocol?

My question is what logical reason would a pool give to a miner to do this?

To queue jobs to the miner. The server could tell the miner "here's work for you to do when you finish what you're currently working on". Since jobs are stateless and individualized (i.e. each job is only being worked on by that one user/worker), a server could queue jobs for the miner before it finishes its current job in order to avoid down time. So long as a new block hasn't been found, this is faster than the worker asking for another job when it finishes its current one.

  I'm assuming if new work comes in it means someone on the network has hashed the block and therefore there's no more potential for rewards.

That's a bad assumption to make. For a given block, there can be lots of new work. New transactions could be generated, ExtraNonce1 can be incremented to provide new work, etc.

  So why have a worker waste his time continuing with a job that someone else has already completed?

IIRC jobs are individualized, so a miner is not doing work that a different miner is doing.


Unable to transfer bitcoin from Multibit - need Satoshi

You will need to include a transaction fee as well, so you can't send the entire balance in your wallet. Decrease the amount you are trying to send by the amount it suggests and try again.


Can an invalid Omni transaction be confirmed by bitcoin miners?

Yes, Bitcoin miners don't perform any validation beyond the Bitcoin validity rules. Omni transactions rely on OP_RETURN values, which don't matter to the Bitcoin miners.

As long as a tx is a valid Bitcoin tx, miners are free to include it in their blocks.

When an omni node sees such an invalid transaction, it will simply ignore any asset movements the tx claims to perform.


Will lightning network efficiently support a single payment of 25 cents?

First off, yes, the lightning network will not require 1000 on-chain transactions added to the blockchain.  The lightning network aggregates off-chain transactions into single on-chain settlements.

Like the Bitcoin network, the lightning network will also operate on a model of market-driven transaction fees.  However, these are not the same fees paid to miners on the Bitcoin blockchain.

The lightning network will be a hub and spoke network of bi-directional payment channels.  Channels are connections between two nodes on the network, and a single transaction may travel through several channels.  Nodes will charge you to use their channels, so you end up paying fees to multiple nodes.

However, these fees are likely going to be very small.  Unlike mining, there is no large hardware investment to run a lightning node.  Even a cheap computer will be able to do so.  The real cost of running a node is that an amount of bitcoin must be tied up in each payment channel that node has open.  This also limits the amount of total bitcoin that a channel can transfer in one direction.  Because of this, channels will adjust their fees to incentize transactions in different directions.

When a channel has had too much bitcoin travel in one direction, it will either have to close and re-open, or will have to get people to transfer in the opposite direction.  The cost of closing and re-opening is an overhead that will be worth avoiding, since that is when on-chain fees will have to be paid.  This means that there will always be channels trying to get you to use them...even if it means negative fees (see this answer).

Wallets should be smart enough to route your payment through a series of channels that will minimize your fee.  On some channels you will pay higher, some lower, and with negative fees, some may even pay you!  Due to the relatively low barrier of entry for running a node, this will likely drive down overall fees.  Some have even speculated that fees will be effectively zero.

In short, unlike Bitcoin, the lightning network is poised to be a true micro-payment network.


BIP32 recommends a 256 bit seed. Why do most Bitcoin wallets only use a 128 bit seed?

The reasons for the 3 numbers:

Bitcoin uses 256-bit ECDSA signatures. These require in the order of 2128 steps to find a private key from the public key is known. This is Bitcoin's security level: we aim to always require an attacker to perform 2128 steps. If the seed has less than 128 bits of entropy, this inevitably leads to a faster algorithm, where an attacker can simply iterate through all possible seeds in less than 2128 steps. Because of that, BIP32 requires at least 128 bits of entropy.
When the seed has less than 256 bits of entropy (but more than 128), the resulting keys will also have less than 256 bits of entropy. As elliptic curve cryptography uses keys with a full 256 bits (despite there being a faster attacker than breaks it in 2128 steps), BIP32 also recommends 256 bits of entropy.
The combination of private key and chaincode (the "extended private key") in BIP32 are 512 bits in size. Because of that, using a seed with more entropy than 512 bits cannot possibly increase security more - it's just information that gets thrown away. Because of that BIP32 limits the seed to at most 512 bits of entropy.


Is bitcoin-qt as PPA really secure? How to proof?

You can instead directly install from the source code. It is available on the project site along with release signatures.


bitcoin-cli could not locate RPC credentials

You are using bitcoin-cli incorrectly.

The command line arguments come before the RPC command. Anything that comes after the RPC command will be interpreted as arguments for the RPC, not arguments to bitcoin-cli

So what you should actually be doing is

src/bitcoin-cli -rpcuser={...} -rpcpassword={...} getblockchaininfo


You have to use a Bitcoin exchange. The most popular one is MtGox

There are other ways but I think this is the safest one and easiest.


How security is managed in Cryptocurrencies with no mining possibility

when you talk about mining and miner you insinuate by that POW (proof of work) consensus mechanism (a solution to the "Byzantine fault tolerance" problem). Other cryptos use for the same reason (reaching the consensus ) other mechanisms such as proof of stake (currently used in peercoin and Ethereum will switch to it soon) ,Proof of Activity, Proof of Burn, Proof of Capacity etc.

So every consensus algorithm or mechanism has it's own security model to secure the network and prevent double spending problem. POW depends on resolving a puzzle (mining: performing a certain amount of computational work) and an incentive the others has different procedure. Rather than that a proof of stake system requires the prover to show ownership of a certain amount of money.

For example in POS (proof f stake) the participants or the "provers" stake some of their coins so if they cheat they will lose their money (punish the cheater), to enforce the decentrlized consensus. In PoS cryptocurrencies the schema change: the blocks are usually said to be forged, or minted, rather than mined and there is no miner and no block's reward (only the transaction fees).

I suggest you to read more about POS, HERE.

the other consensus mechanism like Proof of Stake are not as safe as pure Proof of Work at an extent but every project is trying to provide a secure implementation.


What is a millisatoshi? I thought satoshi is the smallest unit?

It's not a mistake, it's literally a thousandth of a satoshi. A satoshi is the smallest unit for bitcoin, but lightning can transact with even smaller units while channels are open. The amount is rounded down to the nearest satoshi when the channel is closed and broadcast to the blockchain to adhere to bitcoins limit.


How Long Does Miner Wait To Receive Commission From Transaction Fee?

Transaction fees are part of the block reward, so miners will be able to spend those transaction fees at the same time that the block reward matures. The network does not distinguish between the block subsidy and the transaction fees when miners receive their reward for a block.


If Bitcoin addresses are truely random, then why are some more difficult to generate than others?

The 160-bit hash that is encoded in addresses is uniformly distributed ("truely random" as you call it), but the base58 encoded form is not. Some characters are more likely to occur at the start, for example.

To illustrate, consided the set of all integers between 0 and 1999. Even though each of those numbers is equally likely to be chosen, this is not true for its decimal representation. There, half of the numbers start with a 1!


I'm not an expert, but as far as I understand it, Moore's Law applies to ASICs just like other chips. So, every two years you get newer ASICs which can hash more, even though the chip design is not all the different from the previous ASICs, the number of transistors that chip has on it is doubled.  So, there is always going to be a cost of keeping up with the latest chips. This is part of what prevents a 51% attack, since there are literally not enough ASICs is the world for one big bank or something, or one scammer, to buy them all up to mine with.  World BitCoin Network on YouTube goes into this in more detail in the 51% attack video.

Moore's Law isn't going to hit a limit in the near term, since when we get so small we are on the scale of just a couple of atoms, we will just start stacking chips on top of each other.  Itel is already researching liquid cooling between chip stacks.  So, for the forseeable future, Bitcoin mining is not just going to be a function of cheap energy, or optimized chips, but the financial treadmill of buying new ASICs every two years.


What exactly happens to leaves when forming nodes?

Concatenation means the joining of the second sequence at the end of the first sequence. For example, with strings, the concatenation of "hello, " and "world" produces the string "hello, world".
For TXIDs, they are taken as a 32-byte array. The concatenation of the two TXIDs produces an array of 64 bytes, which then becomes the input for another round of double SHA256. The resulting hash becomes the parent hash of the two TXIDs in the Merkle tree.
Each pair of transactions is hashed in such way, and if the number of transactions is odd, the last TXID in the sequence is duplicated (concatenated with itself). The parent hashes are then recursively treated in the same way, concatenated pairwise, until a single hash remains, which is the Merkle root.


When/How did Eligius "indirectly cost MTGOX many thousands of bitcoins"?

It refers to an occurrence in October 2011 when someone sent a lot of bitcoins to an incorrect public address: someone fucked up and lost ALOT of money . Casascius stated that he thinks it was done by Luke-Jr's Eligius mining pool: Re: someone fucked up and lost ALOT of money

  The way I understand it, these transactions were nonstandard enough
  that normal miners and clients would already refuse to relay or
  process them (but will accept them in a mined block). And that the
  only way these got into a block was that he teamed up with Luke-Jr's
  Eligius mining pool which has been modified to explicitly allow these
  nonstandard transactions for a fee (or other negotiated arrangement).

Earlier from the same thread, Re: someone fucked up and lost ALOT of money:

  Maybe this helps. It seems MtGox made a mistake somewhere.

    MagicalTux: that's a problem, but not the worst problem we ever faced

    MagicalTux: all the broken withdraws have been re-issued

    MagicalTux: just spent one week of BTC-only income


Can the transaction log history size scale?

No, this isn't a likely problem for Bitcoin. Or, to be more specific, it is a problem that there known ways to solve.

First of all, there is a concept called a selfish client. Which means a client that can create and receive transactions, but doesn't maintain the blockchain. It's considered "selfish" because it isn't performing the work expected of a true node on the system: it only maintains the information needed for it's own transactions. These types of clients are already common in the mobile world today, where 8GB is already too much to handle.

But if we got to a scenario where the blockchain was too unwieldy for the typical client, we would also probably be in a scenario where the network already had a sufficient number of server nodes to handle the "network".

Second, Bitcoin already has the concept of discarding transactions once they are spent. (It is made possible by the way that transactions are stored in the block: via the Merkle tree.) It is essentially not implemented yet, but the concept is there for when it is needed.

It's not inconceivable that we might end up with three tiers of clients: selfish clients on our mobile devices, master nodes that have all of the transactions and can trace any transaction ever made, and hybrid nodes that do support the entire Bitcoin protocol but only keep a trimmed version of the blockchain that prunes transactions that have already been spent. See this question for some details about pruning : Is pruning transaction history implemented in Satoshi's bitcoin client? .


You would be using blockchain.info's wallet. If they were to stop providing their wallet service, you may not be able to access your Bitcoin at all (depends on your backup situation) although the Bitcoin is still present on the blockchain.

If you have proper backups of your blockchain.info wallet (you have the mnemonic for your wallet), then you can restore it to another wallet software and be able to access your Bitcoin from there.


I will try to respond to what I've understood about your question. Correct me if I miss your point.

1

Transactions are stored inside blocks in the blockchain. The blockchain is a distributed database, stored on thousands of computers around the world. This means that corrupted memory on a node won't affect the net, because the same information is on every other "sane" machine. It is true though that the size of such database is ever increasing and less people want to become full nodes for the size of it. Memory is not limited and is not hard to get (in this case). The current dimension of the blockchain is of about 140 GB and almost anyone can affort a 1 TB Hard Disk. Your camera (your bitcoin's) won't be useless if you fill up every tiny byte of memory in your machine because the same data will be in every node in the network

2

When you want to send bitcoins you create a transaction.

A group of transaction is put together to form a block.

Therefore you can't spend blocks, because they are just a data structure.

So bitcoins are just numbers sent and received by people. Blocks are the structures that contain the information about the excange if bitcoins between people.

3/4

A transaction's priority is based on its fee and the time elapsed from the moment it was sent to the network. The older a transaction is, the more priority it has.
So if you send a transaction with a low fee then you should be prepared to wait a long time (days) until it will get confirmed. If the fee is extremely low, it may occurr that the transaction won't get through for years!.

A fee of 0.0003 is a bit low. I understand that you had 0.0033 BTC and sent 0.003 and paid another 0.0003 as a fee.

5

It was born as super decentralized and now it's becoming less decentralized because of the difficulties bounded with running a full node and mine. We will se what the future holds for us.

Note
I suggest you read some basic article about Bitcoin (you can find a lot of them just looking at the first results of a google search) to understand the basics

read this

FROM THE START

I'll try to explain you in a simple way how Bitcoin works.

Bitcoins is a peer to peer network that organizes the excange of data between people using a chain of blocks. This chain is protected by cryptography and every node shares the same chain. That chain of blocks is just a bunch of data files. Whenever two people want to send bitcoin between themselves in the blockchain they create a transaction, which then is included in a block by a miner. The miner gets a reward for creating the block (which costs computing power) and the fees attached to the transactions. The block he creates is just a simple plain old file, it is not some sort of magical and costly paper. Every block can at most be 1MB in size so it isn't storage demanding either.

As for the price of bitcoins it only depends on how much people are willing to pay them. If everyone wants a bitcoin then the price goes up. If no one wants a bitcoin the price goes down (to put it in an exaggeratly simple way).


UNOMP is no longer maintained and development of it stopped before the introduction of Asicboost into stratum. Thus it does not support using Asicboost.

CKPool is a mining pool software that that does support Asicboost.


Disclaimer: I hold STORJ. (Not that it would have any impact on the answer)

What you're looking at here is an ERC20 token. So your question revolves around the Ethereum blockchain.

When a new block is mined, it is transmitted to the nodes on the network. This is accomplished by the miner transmitting to his node, and his node transmits to other nodes, so forth and so on.

The idea of "end points" you are asking a node, lets say your node, or a 3rd party providers node for information. In an ideal world all nodes have the same exact information. In the real world they can be different but the node software resolves these differences using "longest chain wins". That's why we wait for confirmations. Ethereum works a bit differently as it uses a "confirmed" flag instead of number of times it's seen since the original block it was first found but this is the Bitcoin forum.

With Bitcoin you can ask any node for "a block" but i think you mean "a transaction". You simply don't consider a "transaction" or "block" to be valid until there are 6 blocks after it. By then it's statistically impossible for it not to "Exist" on the full chain.

In your final example: Storj doesn't really "land" (or any token/coin on any chain). A transaction is submitted to mempool which is then broadcast to other nodes. A miner sees the transaction, mines it, and adds it to a block. That block is then rebroadcast. There is no way for you to "spend" anything because someone else has to confirm that the transaction is valid and add it for it to show up on the actual chain.

Note: Apologies for any confusion. The question was a bit awkward but did my best to answer the various points in it. I highly suggest investigating how blockchains work and why they work. Bitcoin is a fantastic place to start since this all started with Bitcoin.


Convert BTC to BCC from Bitcoin Core Wallet

You need to transfer all your BTC to the new BTC wallet, after that you import the private keys from old BTC wallet into a BCC wallet and you will have the same amount of BCC. From here on you can decide with how much BCC you want to play with (you cannot clam partial amounts of BCC)


You can find the stats of different transaction types here: http://webbtc.com/stats


The formula for sell_order_Net_total will be:

 sell_order_Net_total = sell_amount * sell_price * (1- sell_ex_txn_fee)

The final profit:

Profit = sell_order_Net_total - buy_order_Net_total

Keep in mind that there are also transaction fees between the two exchanges. If you have traded all your DOGEs for BTC on 1 exchange, and BTC for DOGEs on the other, you'll want to mix both accounts with an equal amount of DOGE/BTC. The transaction fees should also be accounted for if you want to trade between exchanges.


genesis.GetHash("");

This is incorrect. GetHash does not take a parameter, as said in the compiler error. This should just be genesis.GetHash();.

  I have checked the debug.log but i dont see new values for hashGenesis and Merkel root.

The debug.log file is only modified when  you run the program, and because it isn't even compiling, when you run it, you are not running it with any of your changes.


Is there a central repository that states a country's latest policy on bitcoin?

The best I found so far is Wikipedia. It is actually quite up to date.

https://en.wikipedia.org/wiki/Legality_of_bitcoin_by_country


"Vin": [
        {
            "TxId": "ed34d4d2b9953a4ef585a13454a00501783675752b640b8cc68235afe5495498",
            "Vout": "1",
            "ScriptSig": {
                "Asm": "3045022100aa4cfe7482c52e961b617658d8029b524f8fe2a33ae3a4acd1d4f46684e8703f022077db4cd5b21413761b44e5511ddb45a91f2cbff52537677c2703a6f1f2cea6e4[ALL] 02763d72701702a421c464eb3a8dad8bd653d5fc2bddd1b08f1563d14952fda861",
                "Hex": "483045022100aa4cfe7482c52e961b617658d8029b524f8fe2a33ae3a4acd1d4f46684e8703f022077db4cd5b21413761b44e5511ddb45a91f2cbff52537677c2703a6f1f2cea6e4012102763d72701702a421c464eb3a8dad8bd653d5fc2bddd1b08f1563d14952fda861"
            },
            "CoinBase": null,
            "TxInWitness": null,
            "Sequence": "4294967295"
        },

If you go to https://blockstream.info/testnet/tx/ed34d4d2b9953a4ef585a13454a00501783675752b640b8cc68235afe5495498?expand and see the output #1, you'll see that it's an unspendable OP_RETURN output. Remember that TX Outputs are zero indexed, so maybe you're trying to spend "Vout": "0"?

That ScriptSig matches perfectly with output #0. Just change the Vout field of first Vin as I said above. The second input is also okay.

In other words,

   "Vin": [
        {
            "TxId": "ed34d4d2b9953a4ef585a13454a00501783675752b640b8cc68235afe5495498",
            "Vout": "1",
            "ScriptSig": {

should be

   "Vin": [
        {
            "TxId": "ed34d4d2b9953a4ef585a13454a00501783675752b640b8cc68235afe5495498",
            "Vout": "0",
            "ScriptSig": {


How do i retreive my bitcoins that I purchased but never receaved because of the dodgie bitcoin qt years ago?

The information needed for you to recover your coins is in the original bitcoin-qt you used to get the addresses to request the bitcoins. Did you back up its data folder?

The private key for your coins is in that backup. If you didn't back that up, you probably can't recover the coins.


What does the term "Electronic Cash" stand for in computer science lingo?

Digital cash is supposed to be a digital equivalent to our legacy physical cash (coins and banknotes).

Therefor digital cash needs to fulfill certain criteria:

payments can be made without a middleman
the receiver has a means of verifying the transaction and be sure that they have been paid
the transaction cannot be reversed

These criteria are met no matter if I hand you a banknote or send you a Bitcoin transaction. They also create privacy and non-confiscatability as no middlemen carry out the transaction for you or hold your money for you.


Broadly correct.  A few minor details aren't right.
#1. Private keys are simply 256 bit numbers.  They can be created by a random process or, in modern wallets, as part of a Hierarchical Deterministic sequence in which each key is generated in a repeatable way from a seed.  See https://learnmeabitcoin.com/technical/hd-wallets.  Also, the wallet address is not the public key itself - though it is derived from it.  The site linked above explains this too.
#3. A transaction explicitly refers to previous transactions - and it is these which are checked for sufficient funds (not "the whole blockchain").  The new transaction will also deal with any excess funds.


What is the definition of a P2P exchange?

Decentralized peer to peer exchange of digital currencies to/from fiat currencies will always have the following constraints:

Fiat currencies cannot be encrypted and represented digitally by a decentralized entity/organization/system. Therefore, fiat currencies will always need to be transferred between traders through the banking system or physically using cash.

Peer to peer trades of fiat<=>digital currencies will always depend on trust. A peer to peer exchange protocol could easily ensure that one party would always send the Bitcoins. The transaction can be verified. The protocol could safely hold the Bitcoins until the other party sends the dollar (Decentralized escrow). But the protocol can never confirm the dollar transaction. It can never know for sure that the transaction has occurred. This introduces the below:

Who's going to send first?
I sent the money. No he didn't
Who will this person be that I'll receive a transfer from? Is he a criminal? Are the funds stolen?
What if this person tells his bank that I fraudulently received this payment.
I went to the cash exchange and had to confirm the transaction at gun point

Remember that transactions  within the banking system are monitored, they can be reversed and funds can be frozen.
I have studied all projects aiming to accomplish a peer to peer decentralized exchange:

Dark Exchange
BitcoinX
Ripple - which is actually a payment system that will hypothetically allow trades as well.

I haven't seen a solution for the above mentioned constraints. All of these projects will be bound by them.
Ripple protocol proposes to allow dollars to be represented on the network and allow peer to peer transfer of dollars, therefore enabling btc->dollar trades. However, their model depends on Gateways -the entry/exit points of fiat currencies to the network. Users will still need to trust that these Gateways will actually hold and be able to pay the amount of dollars within the network as/when needed. There is no guarantee that these Gateways will not fraud the network or individuals. Neither is there a guarantee that the governments will not shut them down. (Read the first line here: https://ripple.com/wiki/Gateway_List)
My view on the future of fiat=>dollar exchanges:
First and foremost: The significance of exchanges will diminish as the adoption of Bitcoin grows. The less the need to trade your Bitcoins, the less important exchanges are. I truly believe this.
Are you saying that we not need exchanges? Absolutely not. No matter how much the adoption rate grows, there will always be a need to trade Bitcoins -this will be true for at least our  lifetime. So we need better and more exchanges.
So what's it gonna be? A ton of local options for people to buy/sell Bitcoins and lots of big exchanges that local shops can trade with. You need to remember that currency exchange does not always have to be in continuous double auction format. When you go to an exchange office and buy euros with dollar, they are not actually matching that with another order. They put a safe profit margin on the price and we pay it. See: CoinBase
Overall, I truly hope that I'm proven wrong. But I don't think a peer to peer decentralized exchange can be built.
Important last note: All of the above are true only for fiat to Bitcoin exchanges. A digital to digital currency exchange can be made peer to peer and decentralized given that both allow peer to peer public transfers and both are decentralized. (Ex. Litecoin to Bitcoin)


are individual satoshis as secure as an overall bitcoin?

When people "hold Bitcoin", they actually have access to a private key that allows them to sign for one or more unspent transaction outputs (UTXO) of the corresponding Bitcoin sum. The amounts in transaction outputs are in fact specified as a count of satoshis.

All unspent transaction outputs are tracked by each full node on the network, therefore, it is no more likely that a smaller amount is going to be forgotten rather than a greater amount. However, since transaction fees are paid for transaction size and not transacted amount, smaller amounts can have a much higher relative cost to be spent than larger sums.


Generating an address from a private key in Java?

Don't reinvent the wheel, use an existing library. bitcoinj for instance provides the method getPubKeyHash of the class ECKey which does what you are looking for.

Edit: getPubKeyHash does not return the human readable address directly, but can be used to create an instance of the class Address. This (as a subclass of VersionedChecksummedBytes) has in turn the method toString which presents the hash as bitcoin address.


Specifics on "Race Double Spending Attacks"?

You have already answered your question. The basic double spending attack in question is just that: The attacker initiates a Bitcoin transaction and claims a benefit from it. Then the attacker does the same thing again, potentially broadcasting the new, conflicting transaction to a larger number of nodes in the Bitcoin network, in an attempt to have the new transaction confirm instead of the first one. If that succeeds depends on which kind of miner, one having seen the initial or the later transaction first, manages to mine the next new block (with a few extra caveats, like that miner actually choosing to include said transaction in his newly mined block).

Computer scientists call this general phenomenon where the overall outcome from concurrent processes depends on what happens first a race condition. The race condition I just described can continue if nodes continue mining on different subchains where one contains the first transaction and the other subchain contains the other transaction from the double spending attack.

There are also more complicated forms of double spending attacks, but all of them have a race condition to some extent, and hence I would call all of them eligible for the description "Race Double Spend." You may also be interested in one, the Finney Attack, that makes the race condition almost disappear through premining, such that the attacker has an almost unbeatable head start if the recipient (e.g. the merchant) instantly accepts an unconfirmed transaction.


Double signature requirement of Breach Remedy Transaction

If we assume "half-signed" implies that both parties sign the transaction, then the Breach Remedy transaction would also include the spend from the other output in the commitment transaction which would then also require Bob's signature. This logically makes sense (but is not explicitly stated in the paper) as it would reduce transaction fees and consolidate UTXOs. But yes, you are correct, there is no need to have both parties sign the Breach Remedy transaction.

The current protocol design actually does away entirely with the Breach Remedy and Revocable Delivery Transactions by using special scripts which enforce the rules that those transactions would enforce by existing. This script uses a relative lock time (with OP_CHECKSEQUENCEVERIFY) to enforce the Revocable Delivery rule. It also uses a revocation key which can be generated by the party performing the revocation after a commitment transaction has been revoked, thus doing away with the Breach Remedy transaction. The output script construction is described here.


Is Bitcoin Cash the same as Bitcoin classic?

Bitcoin Cash is an altcoin, i.e. a Bitcoin-like protocol and network that originated from hardforking Bitcoin chainstate. Bitcoin Classic was first a hardfork proposal and then an alternative implementation of first the Bitcoin protocol, then the Bitcoin Cash protocol.

Originally, Bitcoin Classic was a hardfork proposal that advocated for a blocksize increase to be activated with 75% hashrate support. To that end, the Bitcoin Classic repository maintained only the set of changes necessary to introduce said blocksize increase, rebasing this on top of the latest changes of the Bitcoin Core repository. When it became obvious that there was too little support for Classic, the Classic repository started to fall behind, work subsequently being discontinued.

Later, the Bitcoin Classic repository was revived by a developer as an alternative implementation of the Bitcoin protocol. They introduced a number of other changes into this repository instead of only maintaining the code for the blocksize increase. For a while, Bitcoin Classic cooperated with Bitcoin Unlimited, e.g. with both implementations rolling out support for thin blocks. Later, Bitcoin Classic maintained an alternative implementation of the Bitcoin Cash protocol. It was recently discontinued altogether.


Difference between Public Bitcoin Address and Hash 160 Address?

What you refer to as 'Hash 160 Address' and which appear in this example under the field 'Hash 160' (e.g. the hex number a6c70c4a88205065c1d33b17c156137fa8c736c1) is a 20 bytes hash of the public key (specifically, it is the ripemd160 hash of the sha256 hash of the public key). These 20 bytes are essentially the same thing as what you call the 'Public Bitcoin address' (e.g. 1GCqcweZTwwe1w2RMWwwQMKSFgQzgFZQUb in our example). This bitcoin address is a 25 bytes number (usually displayed in Base58) which is linked to the hash 160 as follows:

address = [Version Byte (1)][Hash 160 (20)][Checksum (4)]

The version byte is simply 0x00 for the main bitcoin network and the 4 checksum bytes are simply the first 4 bytes of the double sha256 hash of the 21 bytes [Version Byte][Hash 160]

I attach a java snippet to illustrate some of the computations:

import org.bitcoinj.core.Address;
import org.bitcoinj.core.NetworkParameters;
import org.bitcoinj.core.Base58;
import org.bitcoinj.core.Sha256Hash;
import org.bitcoinj.params.MainNetParams;

class Test {
  public static void main(String[] args)
  {
    String  str = "1GCqcweZTwwe1w2RMWwwQMKSFgQzgFZQUb";

    NetworkParameters main = MainNetParams.get();

    // The string address is just a number expressed in base 58
    // Let us parse this string and see the bytes of the underlying number
    // 0:
    // -90:-57:12:74:-120:32:80:101:-63:-45:59:23:-63:86:19:127:-88:-57:54:-63:
    // -86:-114:24:124:
    byte[] full = Base58.decode(str);
    for(int i = 0; i < full.length; ++i){
      System.out.print(full[i]+ ":");
    }

    // Let us compute the hash 160 of the address
    //-90:-57:12:74:-120:32:80:101:-63:-45:59:23:-63:86:19:127:-88:-57:54:-63:
    // These are the same 20 bytes as before
    Address addr = Address.fromBase58(main, str);
    System.out.print("\n");
    byte[] hash = addr.getHash160();
    for(int i = 0; i < hash.length; ++i){
      System.out.print(hash[i]+ ":");
    }

    // Let us see the first 21 bytes of the address
    // 0:-90:-57:12:74:-120:32:80:101:-63:-45:59:23:-63:86:19:127:-88:-57:54:-63:
    byte[] decode = Base58.decodeChecked(str);
    System.out.print("\n");
    for(int i = 0; i < decode.length; ++i){
      System.out.print(decode[i]+ ":");
    }

    // Let us compute the double sha256 hash of the first 21 bytes of the address
    // and display the first 4 bytes: -86:-114:24:124:
    // These first 4 bytes are exactly the last 4 bytes of the address above
    byte[] check = Sha256Hash.hashTwice(decode);
    System.out.print("\n");
    for(int i = 0; i < 4; ++i){
      System.out.print(check[i]+ ":");
    }
  }
}


How to convert Litecoin difficulty of 6 to an expected time per block solved?

I don't know much about Litecoin, but if its difficulty works the same as in Bitcoin, then on average it takes approximately difficulty * 2^32 hashes to solve each block.

Since you're calculating 25000 hashes per second, it should take you around 6 * 2^32 / 25000 seconds to solve a block.  Or about 286 hours.

Does that sound about right?


Will the 3TH KNC Neptune Miner still be profitable in 2014?

The hard part about pre-ordering next generation hardware is to predict a logical expectation of  A) what will be the total network power (hashrate) be by the time your miner comes online which influences directly B) what will be the difficulty value at that time.

If you assume linear growth in the network vs exponential for example you will arrive at different conclusions. That is the real hard part.

At todays difficulty (now 908,350,862) a 2 THps miner at $1000/btc can expect to break-even in 5-6 days.

If looking backwards is any indication, the difficulty has increased by 945% in the past 90 days so if that is the same as the next 90 days and BTC values are fixed at $1000/btc you can expect to break even in 47 days.

IF you think that the next 90 days will grow faster (say 1.5x as fast) as the previous 90 days then you can expect a breakeven in 75 days.

What if your miner comes in 4 months from now instead of 3? What if a whole lot of people are buying one so that when they all come on line simultaneously the difficulty will spike beyond your projections?

And what if the price of BTC falls again from where it is now and stays lower?

A lot of what-ifs but you must know your variables before investing in mining capital.


You need to send a version message (and receiving the correspondant verack) before sending anything else. Here is a quickly patched version of your script which handles the version message:

import hashlib
import random
import socket
import time
import urllib.request

PEER_IP = "127.0.0.1"
PEER_PORT = 8333

nonce = (random.getrandbits(64)).to_bytes(8, byteorder="little", signed=False)

magic_number = bytes.fromhex("f9beb4d9")
command_name = bytes.fromhex("ping".encode("utf-8").hex() + ("00")*8)
payload_size = (int(len(nonce))).to_bytes(4, byteorder="little", signed=False)
checksum = hashlib.sha256(hashlib.sha256(nonce).digest()).digest()[:4]

pong_msg = (
    magic_number
    + command_name
    + payload_size
    + checksum
    + nonce
)

# Magic bytes, as usual
magic = bytes.fromhex('f9beb4d9')
# Version number (PROTOCOL_VERSION in core)
version = int(70015).to_bytes(4, 'little')
# Random services, we don't care
services = int(1).to_bytes(8, 'little')
timestamp = int(time.time()).to_bytes(8, 'little')
myip_str = urllib.request.urlopen('https://api.ipify.org').read().decode()
myip = socket.inet_aton(myip_str)
nodeip = socket.inet_aton(PEER_IP)
# https://en.bitcoin.it/wiki/Protocol_documentation#Network_address
addr_recv = services + b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff'
addr_recv += nodeip + int(8333).to_bytes(2, 'big')
addr_from = services + b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff'
addr_from += myip + int(8333).to_bytes(2, 'big')
nonce = 0x00.to_bytes(8, 'little')
# You can replace this with something more fun
user_agent = 0x00.to_bytes(1, 'big')
# Let's say zero, once again we don't care for this example
start_height = 0x00.to_bytes(4, 'little')
# The message content, which we'll compute the checksum from
payload = version + services + timestamp + addr_recv + addr_from + nonce
payload += user_agent + start_height
checksum = hashlib.sha256(hashlib.sha256(payload).digest()).digest()[:4]
payload_length = len(payload)
# The command type, as NULL padded ascii
version_message = magic + 'version'.encode('ascii') + b'\x00\x00\x00\x00\x00'
version_message += payload_length.to_bytes(4, 'little') + checksum + payload

sock = socket.socket()
sock.connect((PEER_IP, PEER_PORT))
print('Sending version message..',)
sock.send(version_message)
print('Received verack: {}'.format(sock.recv(24)), end='\n\n')
print('Sending ping..')
sock.send(pong_msg)
print('Received pong: {}'.format(sock.recv(1024)))

And here is a sample output of my node:

Sending version message..
Received verack: b'\xf9\xbe\xb4\xd9version\x00\x00\x00\x00\x00h\x00\x00\x00n\x8a\xbe\xc7'

Sending ping..
Received pong: b'\x7f\x11\x01\x00\r\x04\x00\x00\x00\x00\x00\x00\x86\xc5\x08^\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\r\x04\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xe7\xa0vQ\x16V\xb1\xab\x12/Satoshi:0.19.0.1/\x14P\t\x00\x01\xf9\xbe\xb4\xd9verack\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00]\xf6\xe0\xe2'

Here is the protocol documentation, on which you can rely for implementing protocol messages.


setting up and verify a wallet under special circumstances

It seems your friend is attempting to open an account at an online exchange, this is the general instance in which people new to Bitcoin try to make an initial purchase.

It is important to note that the account they are opening at an online exchange, is not just a bitcoin wallet, but also an exchange trading account. Currently the vast majority of online services do not make proper distinctions or delineations between the difference financial services they offer.

To create an account and associated set of keys to accept and transfer Bitcoin funds in the Bitcoin blockchain, one does not need to use a service, and may use any number of wallet software options. There are also free online services which do not require any identification to set up and host a wallet using their service.

I will not try to attempt to answer all the security related issues regarding wallet hosting services. This should be a separate area of inquiry for any new user of Bitcoin.

Any market, exchange, or trading platform where users can trade Bitcoin credits for national currencies, is managing transactions in those currencies, and will generally be attempting to comply with local laws respecting those transactions. It is at this point that these services are requiring identification of users, in order to comply with financial regulations.

The common practice of those looking to trade small amounts of Bitcoin credits for national currency, or vice versa, is to find ways to do so in person, rather than online. This usually done by finding someone to meet using an online service like LocalBitcoins.com or meetup.com and then meeting the person, or using a nearby Bitcoin ATM. In either case, small amounts of funds traded between the people or with the ATM are considered to be within legal limits of a non-reportable transaction. You may want to check your local regulations to see what those limits are.

It's good to keep in mind, for those who are new to Bitcoin, that there are two parts to any currency trade you are making for Bitcoin credits. The national currency transfer, and the Bitcoin funds transfer. The national currency transfer is the one that requires identification of users, generally speaking.


How to choose the transactions for a block?

How do miners choose the transaction(s)?

However they want. Usually by picking the ones with the highest fees, but also sometimes picking ones that have been unconfirmed for the longest, sometimes prioritizing their own transactions, etc.

Does the difficulty vary depending on the number of chosen transactions?

No.

If not, wouldn't it be advisable to include as many transactions as possible when trying to find a new "candidate" block (maybe depending on the reward - just currency units or also (or only) transaction fees for the transactions included in the block)?

Yes, this is the general idea.

If the difficulty varies based on the number of selected transactions, however, wouldn't it be best to just choose one transaction and then "quickly" (i.e. as the first) come up with a valid candidate block to be added to the blockchain?

The difficulty doesn't vary based on the number of selected transactions.

If it makes sense to choose "all open/unconfirmed" transactions and then try to solve the hash puzzle (by, as I've read starting with a Nonce value of 0 and then sequentially increasing it),

You can't include "all unconfirmed transactions" -- there's a size limit to the block. It's in the miner's best interest to include as many will fit in the block though, since the transactions come with transaction fees that are paid to the miner.

wouldn't it simply boil down to the result that the miner with the largest processing power would always win?

I don't understand what you mean by win, but miners who have the most processing power will mine the most blocks.


Is there any reason to invest on GPU based system these days? (March 2013)

As of today (April 6, 2013) mining profitability on GPUs is at the highest levels ever, but that is only because the exchange rate has rocketed up so fast.

http://blockchain.info/charts/miners-operating-profit-margin

At the same time, mining difficulty has been skyrocketing and that pace of growth will likely outpace the increase in the exchange rate.

http://bitcoin.sipa.be/speed-lin-10k.png

But there are probably two or three difficulty adjustment cycles remaining where mining bitcoins using GPUs is still profitable.   Enjoy it while it lasts because in a little over a month it should be all over for GPUs.   The expected rate of difficulty increase was not unexpected so further investment in GPU mining has been discouraged however the rise in the BTC/USD from the low teens to 10X that level has caused that call to be simply premature by a few months.


After understanding what extended/extensible public addresses(xPub) are I found out that I need to generate addresses of an xpub then search the individual addresses tx


Where to find logarithmic graph of Bitcoin over time?

not sure what you mean by logarithmic graph. The time in a logarithmic scale, or the value? On both, there is a "log" button below the graph. And you can export as CSV or JSON:

https://blockchain.info/de/charts/market-price?timespan=all

or alternativly:

https://coinmarketcap.com/currencies/bitcoin/


validation of a block with false transactions

The block validation process involves checking that all the individual transactions in it are all valid according to the consensus rules which are set in the Bitcoin Core C++ implementation.

Block validation is done by Bitcoin full nodes and one would assume by all miners. If a block is not valid then it will be rejected and any miner who attempted to insert an invalid transaction would have wasted all the time and effort to generate the block hash.


I sent bitcoin and put low tx fee (4sat/b). Unconfirmed for 3 days. Can it be forever?

Fee rate used for the transaction: 4sat/vbyte and unconfirmed since 2 days 10 hours. Weird that I couldn't find the transaction using https://blockstream.info and had to use https://btc.bitaps.com

No it won't be unconfirmed forever

It should be confirmed in next couple of days looking at the mempool but you can't be sure. If enough users are willing to use a fee rate higher than 4 sat/vbyte, your transaction will not be prioritized by miners.

If you own one of the below addresses, you can try to spend unconfirmed transaction output and send BTC to one of your other address with a fee rate higher than others for a quick confirmation. Check https://mempool.observer to see fee rate of other unconfirmed transactions. This is called CPFP. Child transaction paying for parent transaction.

3GQdDSwSU5gJst9fvTH9fXz51aqUV3cb5W
1DdjvgaKTgpPXEQj5uhLxrkJqSEz2tk61Z

Use Electrum wallet: https://electrum.org/#download


Is it possible for an unsolvable block to exist?

It depends on what you mean. (Review: https://en.bitcoin.it/wiki/Block_hashing_algorithm)
Is it possible that with today's difficulty target a miner can exhaust the 32-bit nonce space in the block header without "solving" the block? Yes. But then the miner can change bits in the coinbase transaction (including a field unofficially called extraNonce), change a few bits in the version, increment the timestamp and then also like you mentioned, rearrange/add/remove transactions from the body of the block candidate. So depending on how restrictive you want to be with your question, a miner will never really run out of inputs to try.
But what about the output? A block is "solved" when it's hash, interpreted as a 32-byte integer, is less than a target value (also a 32-byte integer). So what we're looking for then is:
SHA256(data) < Target
This means there are many potential solutions for a block at any given time (all the 20-or-so-byte integer values less than the current target value). If it were impossible to find one single solution in this set that would mean that SHA256 is broken and does not have the random, evenly distributed output we think it does.


Yes, downloading and validating the headers first has several advantages

You know in advance that the chain you're downloading blocks for is in fact the most-work chain (= the one you would ultimately end up accepting, assuming it is valid). This means you don't waste time on potential forks that have been resolved.
Since you know what blocks you will be downloading, and which peers have them, you can parallellize the download (spreading the download over multiple peers).

In Bitcoin Core, the block headers are stored in the blocks/index/ directory in the datadir, as a LevelDB database.


From where I can get bip39 ( 2048 words ) 12 words length possible combinations .

There is no such list, because it is simply too large.

From the 2048 words, 12 word mnemonics are 11 words + 1 checksum word. However, the checksum calculation only affects part of the 12th word, so you are still looking at 12 word combinations

This gives you 2048^12, or 5.44451787e39. That is a 40 digit long number. Even if you were able to calculate 1 billion combinations per second, it would take you
1.726*10^24 years to calculate all combinations, or around 1.3 * 10^14 times the current age of the universe.

Of course, adding in the checksum validation would reduce the list size very slightly, but it would still take you several times the age of the universe to generate that list.


How to build Primecoin from source code on a mac?

https://github.com/bitcoin/bitcoin/blob/master/doc/build-osx.md should work for you as Joe White commented, note you'll have to install Xcode first of all, and in Xcode open preferences - downloads and install the command line tools. I recommend homebrew over macports as it's better maintained and a little more user friendly.

the only difference is that as you're downloading from sourceforge rather than github, you skip the git clone and just find makefile.osx in /src/src/ of the downloaded folder.

you then (assuming you installed homebrew as standard) open makefile.osx in textedit or xcode and change

DEPSDIR=/opt/local

to

DEPSDIR=/usr/local

and you'll probably have to change

 $(DEPSDIR)/lib/db48/libdb_cxx-4.8.a \
 $(DEPSDIR)/lib/libboost_system-mt.a \
 $(DEPSDIR)/lib/libboost_filesystem-mt.a \
 $(DEPSDIR)/lib/libboost_program_options-mt.a \
 $(DEPSDIR)/lib/libboost_thread-mt.a \
 $(DEPSDIR)/lib/libboost_chrono-mt.a \
 $(DEPSDIR)/lib/libssl.a \
 $(DEPSDIR)/lib/libcrypto.a \

to paths more like

 $(DEPSDIR)/Cellar/openssl/1.0.1e/lib/libssl.a \
 $(DEPSDIR)/Cellar/openssl/1.0.1e/lib/libcrypto.a \

Check in /usr/local for the Cellar folder and the libs folder, you could alternately alias each referenced file in /usr/local/libs


If SHA256 and/or RIPEMD-160 were broken, would all bitcoin addresses be compromised?

Bitcoin uses SHA256 followed by RIPEMD-160, which I'll collectively call HASH160.

Good hashes have 4 properties:

it is easy to compute the hash value for any given message
it is infeasible to generate a message that has a given hash
it is infeasible to modify a message without changing the hash
it is infeasible to find two different messages with the same hash

Source: Wikipedia

We care about properties 1, 2, and 3. We know for a fact that property 1 is true about HASH160 - we can benchmark it. If properties 2 or 3 were false, then you could steal bitcoins. Not good.

It's a good thing that the scripting language is so flexible, and would allow people to switch to a different address type without forcing everyone to upgrade.

This is a current bitcoin transaction script:

 OP_DUP OP_HASH160 09432ab39083b5098b6f09432ab39083b5098b6f OP_EQUALVERIFY OP_CHECKSIG

Here's how that might change if HASH160 were broken:

OP_DUP OP_HASH256 09432ab39083b5098b6f09432ab39083b5098b6f09432ab39083b5098b6f826496 OP_EQUALVERIFY OP_CHECKSIG

Note that we've swapped HASH160 for HASH256. Or, assuming both were broken:

<pubKey> OP_CHECKSIG

Now we're forgoing hash functions entirely and putting in the ECDSA key explicitly. However, this would make bitcoin addresses about a hundred characters long.


As Andrew Chow suggested, the solution was simply putting quotes around the directory path. Windows SMH. Thank you.


A wallet is merely a collection of pairs of private/public keys. Every normal Bitcoin address is just a hash of a public key. The corresponding private key is needed to sign transactions that spend coins from the address.

So wallet security really is all about protecting your private keys - making sure you have access to them, and nobody else does. There are several ways to do this. A basic client software manages a wallet file for you and uses the keys within to sign transactions.

There are more advanced address that correspond to multisig or other scripts.

Re mining - almost true, instead of the miner finding the most complex block winning, every miner finding a sufficiently difficult block is rewarded. What is considered "sufficiently difficult" changes periodically.


what happens to low-fee or forgotten transactions

Likely the transaction will be kicked out of the pool - purging it from the node's "memory". Its hard to imagine that there would be a transaction that would qualify for that treatment with one node, but not for others.
But anything is possible.
If that were the case, then that transaction would just remain hanging in the mempool for that particular node that decided to keep it (for whatever reason). For this portion of the protocol though, its more important to take into consideration which action the network would take overall.
How That Specific Node May Handle Things

There's a chance you may attempt to send a duplicate transaction (from the perspective of that node), unwittingly.

Unless you had the RBF flagged ticked for your TX (which there's a good chance that you may have since this is default Electrum behavior along with many other wallets), the node will reject that new transaction attempt since its likely coming a million years after you sent the initial one

Assuming most of the network purged that TX though (they probably did), however that node decides to handle your re-broadcasted TX (if you do that), is neither here nor there


How to create a blockchain snapshot for a hardfork?

Hard forks are simply extensions of a blockchain where the new blocks follow different consensus rules that are not compatible with the original blockchain. There is no actual snapshotting in a true hard fork. The hard fork software simply syncs up to a certain point with the original blockchain, and after that point, a new consensus rule is enforced which conflicts with the original chain and thus causes a blockchain fork. This is simply governed by an if statement in the block validation code.

The fork is simply activated by a miner who mines a block after a certain block or point in time that follows different consensus rules from the original chain.

For example, with Bitcoin Cash, their software enforced that the first block created after August 1st at 12:00 UTC must be larger than 1 MB and also follows the Bitcoin Cash consensus rules (larger block size, new signature hashing algorithm, etc.). This is encoded as an if statement in the block validation logic which checked the time of a block before executing different consensus rule checks. There is no actual snapshot that is taken; their blockchain up until that forking block is exactly identical to Bitcoin's and can be synced off a Bitcoin node.


Bitcoind information about the input and output


Can I recover my Bitcoins bought in 2009?

I had downloaded the wallet(been told it was a Bitcoin qt wallet)to my desktop back then but no longer have the computer now.

If you do not have the computer, you will need the wallet file or a backup of it.
As Pieter mentioned in a comment above, the software would have originally just been called 'Bitcoin' at that time.

I do not remember the 12 word phrase,

Mnemonic seed phrase backups for bitcoin keys did not exist in 2009

but I do remember the email address and the password.

The bitcoin software does not have anywhere that you would register an email address. Perhaps you were using a bitcoin wallet service of some sort? (though none existed in 2009, the earliest examples would likely be in 2010-11)

Would the transactions be recorded in present day Blockchain?

Yes, all transactions are stored in the chain for all time. If you owned coins and did not spend them, then they will still reside at the address you last sent them to. The only way to move them from there is to sign a valid transaction with the private key for that address.

Or are there many different Bitcoin Blockchains at present or just one Bitcoin Blockchain?

There is only one Bitcoin (BTC).

Can I recover the Wallet ID just by knowing the email address and password?

If it was a self-hosted wallet, then no. If you used a wallet service that is still around, then you will need to contact them to hopefully recover your account.

Are my Bitcoins lost forever?

If you cannot recover the wallet (private keys), then yes. They will unfortunately remain forever locked.
Your best bet is to very carefully check over any hard drives / old storage mediums you may have, as well as email addresses, or any other places online you may have stored your data. You could also look for physical backups of your keys ("paper wallets"), which would likely just be a printed sheet of paper with private and public keys listed for said address.
Best of luck!


Is it possible to limit bitcoin wallet balance?

No that's not possible.

Therefor a transaction must be declinable if the limit is reached, but:

You can not decline a transaction to your address (even if you are a miner and you decline it, someone else could mine it). If one of your friends creates a transaction, if it's a valid transaction and if a miner includes it into a valid block, it's done.


"We can represent any bitcoin account with MaxBTC 251."

It appears that MaxBTC is used here as a strict upper bound to refer to maximum number of bitcoins that will ever exist.

There will always be fewer than 21m bitcoins. All of Bitcoin's protocol logic actually is defined in terms of satoshis. There are 100 million satoshis per bitcoin. Altogether, this means that there will be fewer than 2,100,000,000,000,000 or 2.1×1015 satoshis.

Therefore, 251, which is about 2.25×1015, is larger than the total satoshis that will ever exist in the Bitcoin protocol and thus big enough to express any single amount of bitcoin that will ever need to be referenced.


Just realized right now how an ICO scam can be run... without transparency■■

What you're describing is something I understand to be a well established practice in the land of ICOs and premined altcoins. I've seen it called "salting the tip jar".  It doesn't take much effort to go find high profile "cryptocurrencies" that premined and presold 72 million tokens than as soon as their presale ended their "CEO" paid himself out a million dollars to repay "loans" and exited stage left...

I have no idea if this kind of conduct is generally unlawful, but it doesn't matter because the people creating premined alts and ICOs don't care and don't seem to suffer any negative consequences for their unethical behavior.

I think its yet another reason why people should stay far far clear of any ICO or anything like an ICO.


bitcoind not using correct directory inspite of datadir argument

That tutorial sucks.

Better seek generic instructions on how to mount external HDD to user's home directory.

Say you're Joe, you'd use sudo to add a user called bitcoin.

Then mount /dev/hda1 (or whatever it is) to /home/bitcoin, configure /etc/fstab, reboot, log in as Joe and make sure it works (df).

Then login as bitcoin user, make sure you're in /home/bitcoin (where you should be), download (or just install) Bitcoin Core, and start it. You don't need any config files (but you can add rpcusername and rpcpassword), as by default everything will be stored under /home/bitcoin/.bitcoin/.

Joe now can use a wallet that connects to Bitcoin Core (executed by bitcoin user).


First off, only trust highly-reputable software to generate private keys, especially if they're web-based. It seems like this software has only 16 stars on GitHub and only 2 contributors: https://github.com/mikewoods/OfflineAddress.com

To answer your question, the only way to verify that a private key corresponds to the public key is to actually run the algorithm on a computer. My best advice here is to use a computer that is offline and that boots a highly-reputable open source operating system.


Attention: Ambiguity!

Note that the term (or abbreviation) "PoB" can be used differently. For example, some cryptocurrencies allow users to get some of their coins for provably burning money in Bitcoin, essentially deriving their values from Bitcoin's value by deriving their scarcities from Bitcoin's scarcity.

Yeah, but what about my question?

The idea behind these consensus strategies should be pretty obvious: Find something that:

is hard to do.
is easy to verify.
enforces a linear history.

PoW is trivial, you know it of course: Find a hash that's smaller than a given value.

PoB can be done in such a way that you send out a transaction which burns some of your money. If you burn the most (possibly combined with other criteria, a lot of proposals factor age of the coins in; not necessarily much of your money), you win. Others will mine (I use the word "mine" because "burn" could lead to confusion.) on top of your block. You, yourself, can take transactions of other miners burning their coins and add them to your block, meaning that you burn their coins if you win. Of course, you need a way of others telling you your transactions. Sounds hard at first, I mean why would they give you transactions to put into your block, burning their money. However, it's pretty obvious why they would to this: It's necessary to tell others about the transactions burning their money in order to propagate their block. So you receive blocks burning other miner's money, try to burn your own money on top of that block's parent, burning that other miner's money, too. If your block burns the most money, you win and get the block reward.

PoS, on the other hand, tries a lottery approach. There is a certain amount of money at stake and the bigger your share of that money is, the higher your chances of winning. It's like lining the coins of everyone up, say, there are n coins in total, all numbered from 1 to n. Then, a random number r ∈ [1, n] is drawn. The owner of coin r wins and gets the block reward and possibly the money the others risked (or it's burned, or something else).

PoS can use PoW to draw that random number. For example, whoever gets the lowest hash h of the previous block + a nonce until a certain point in time gets a minor reward. Then, r := (h mod n) + 1.

Of course, these are just the basic concepts + examples. There are a lot of variations and everyone has an idea which according to them is better than the previous ones. The above should, however, make the differences clear. If it didn't work out to do this in so little text, feel free to ask or read it up in the Bitcoin wiki:

https://en.bitcoin.it/wiki/Proof_of_work
https://en.bitcoin.it/wiki/Proof_of_burn
https://en.bitcoin.it/wiki/Proof_of_Stake


Where can I learn more about BIP30; namely the exploit and the background discussion?

The problem was that in case a duplicate transaction was created in a side branch that is afterwards reverted, and is only seen by a certain portion of the network, a fork risk exists. The nodes A that have seen the duplicate transactions and its reversal, will consider the original transaction unspendable (as it was overwritten and subsequently removed from their transaction database in the reorganisation), while nodes B that did not see the duplicate would consider the original spendable. When the original transaction is spent afterwards, and a majority of the network is in B, the network will split, as the A nodes will consider the chain created by B as invalid.

The third solution presented is implemented by BIP30 - this was a stopgap solution to prevent the worst from happening. A more complete solution (the first one) being deployed as BIP 34


Bitcoin is a currency, one which has a payment method build in. Euro is a currency, too. It has a payment method build in, too: If you give someone a Euro banknote, you're using it. But that's it in regards to built-in payment methods. The one payment method fiat currencies have built in are completely useless, online.

However, as you have noted, there are credit card companies who allow you to use the Euro (or the Dollar or whatever fiat currency) without using its built-in payment method. Similarly, additional payment methods can be developed for Bitcoin, too.

With fiat currencies, you are obligated to use an intermediary (e.g. a credit card company) if you pay someone who's not physically right in front of you. With Bitcoin, you don't have to. You may still choose to use one.

Such intermediaries have in fact been created and banks are really happy about it.

For merchants, using intermediaries is particularly interesting because it means that they can accept payments in Bitcoin easily by delegating the handling of payments to a payment processor. There already are quite a few of these.

Similarly, Bitcoin credit card companies can be created. However, using one of course reduces privacy because no one will give you a credit it you don't identify yourself. This means you lose your pseudonymity when using such a service.

However, using direct debit doesn't have to come at such cost. A payment provider can accept anonymous deposits to an account. This account can then be charged by webstores.

There really is a lot to be improved about direct debit. Banks used it for years without implementing improvements and I really hope we will see some with Bitcoin payment processors.

For example, I think you should be able to activate merchant's access to your account via direct debit. Currently, if you give someone your name, name of your bank, and your account number, they can get money from you. In most countries, you have a short period to notice an unauthorized withdrawal and can get your money back but if you don't notice it fast enough, you lost that money.

If you'd see a notice that some new merchant wants to retrieve 141 mBTC from your account and have 24 hours to accept that merchant only once or add it to your list of permanently trusted merchants or to decline it instantly (which would happen after those 24 hours, anyways), that'd be much better than it currently is with banks where basically everyone is a trusted merchant, no matter whether you ever even bought something from them.

Furthermore, you probably only use one bank account and give every merchant the same bank information to withdraw money from that account via direct debit. Any one of them can give your bank information to someone who withdraws money from it without your consent and you have no way of finding out which merchant you ever bought something from via direct debit is the culprit. You can't create a lot of different account numbers for the same account. However, if an ID different from the account number was used and you only ever use one ID per merchant, it'd be really easy to find the culprit. You would see in your payment processor's web interface that you gave the ID coinbase.com:Rd3pG82U to that weird shop you found 3 month ago and bought something from. Btw.: The ID Rd3pG82U is only 8 characters long, far shorter than account number + name of the account holder + bank code. In fact, it's shorter than any one of them. If IBAN + BIC it's used, it doesn't exactly look better for banks. But those 8 characters are base 58, enough for 128'063'081'718'016 IDs. Or 17'075 ID for every single of the 7.5 billion people currently alive, at a single payment processor alone. With 2 characters being used for redundancy so typing errors are caught, 38'068'692'544 IDs fit into the remaining 6 characters. And if those run out for a single payment processor, a digit can be added and you got 59 times as many IDs as before. Btw.: The 2 check digits are far better than what IBAN has and BIC doesn't have any.


Namecoins are a separate implementation of the bitcoin protocol.

It is designed around the ability to use a blockchain to store information about namespaces for domains so once configured, a DNS could route traffic to a specific server.

The extension for these domains are currently .bit but this can be expanded at a later date.

Namecoin uses merged mining. No extra effort is required (the hash is checked against both chains).

More information can be found out at http://namecoin.info

Questions about the protocol are welcome here also.


What is special about a private blockchain based on proof of stake?

I have not read the paper, but here are some thoughts.

Private blockchains make little sense (to me). But of course maybe a clever person will figure out a killer app for/on private blockchains. To me they are analogous to corporate intranets of the mid/late 90s. Those were hyped up as well. IMO a public blockchain is the way to go, perhaps with encrypted transactions, or perhaps using Zero Knowledge Proofs (ala Zcash) if privacy is important.

To comment on your questions:

Chaining blocks together provides a little more security as you could not just change one transaction in block X you would have to recalculate the hashes for each block forward and get others to agree to that change. In a DDB one could just delete/alter/change an entry.
This would really depend on how the private blockchain is set up. Do we need others to accept each block? Would others recognize our new rebuilt blockchain? What consensus algo are we using here?
Blockchains offer a lot (in the right user case). In the case of banks transactions can be encrypted and only the parties involved have the keys to decrypt. Why have a blockchain to store competitors data? Well, what if the blockchain is used only for inter-bank transactions, and not for internal ones. Then there is a immutable (hopefully) record of transactions between banks.

Keep in mind that private blockchains are in their experimental stages. Banks like to make announcements for publicity, this does not mean that they have a working model or using the technology commercially. More often than not it is simply an intent to explore the possibilities that the technology can provide.


Because the parent hash is already based on the previous parent hash, and so on, it effectively does include all of them. A merkle tree is a commitment to all of them, this does the same thing. It would just make generating the block header harder before the miner can even start mining, so there would be no benefit.


HD Wallets Difference between a CKDpub and CKDpriv from the path notation

What's the difference between CKDpub and CKDpriv from the path notation

1.

CKDpub (public key child key derivation)

Derives a child pubkey with given extended pubkey (pubkey & chaincode) and child index. Only works for non-hardened derivation.

CKDpriv (private key child key derivation)

Derives a child private key with given extended privatekey (privkey & chaincode) and child index.

The keypath does not distinguish between private- and public-keys, so on that level there is no difference between CKDpub/CKDpriv.

Although, as you mentioned, to derive a hardened key – even if you only want to derive the public key – you need the corresponding extended private key.

Examples:

you can derive the extended pubkey at m/1 if you have the  extended pubkey m
You can't derive the pubkey at m/1' with the extended pubkey m
You can derive the pubkey (and the privkey) at m/1' with the extended privatekey m

  From this Ethereum standard derivation node /m/44'/60'/0'/0/0 ,how can someone get the extended public key and derive other public from that extended public key respecting those conventions.

You need the xpriv (extended private key) to derive /m/44'/60'/0', but further public child keys (like /m/44'/60'/0'/0 and /m/44'/60'/0'/0/0) can be derived with the xpub (extended public key at /m/44'/60'/0').

  f(parentExtendedPubKey, index ) = childPubKey --> address. How is this achieved and how can a private key that stayed in the HD wallet can later be used to unlock or spend those funds sent to that address generated through the parent public key ?

Deriving a child public key – regardless if you have use the xpub or xpriv – result in the same public key. Just be aware that only the xpriv can derive hardened childkeys.

Assume you have derived the pubkey at m/10 with the xpub at m, you can later derive the according priv-key at m/10 with the xpriv at m.

Further thoughts

BIP44 was designed for hardware wallets and or cold storage.
Ideally you should not mix non hardened key derivation (CKDpub) with the possibility to export child private keys. If you leak a xpub and a single child private key, you reveal all your keys.


Bitcoin transaction with dust output stuck

In case you are interested as to the cause of this problem, I believe this is due to a 'bug' (of sorts) in the wallet you were using, in which the wallet software doesn't check to make sure it's not generating dust outputs.

Let's say you have a single 1.0 BTC UTXO (unspent transaction output) which is available for spending, and you want to send 0.99989999 BTC (slightly less than 1.0 BTC - default fee 0.0001 BTC). Then in this case, if that is the only UTXO that you have, then you cannot actually send the exact amount you requested and expect it to get confirmed in time.

      0.99989999  (Amount sent)
    /
1.0 - 0.00000001  (Change)
    \
      0.0001      (Miner fee)

You should be able to do this, since you have enough to fund the amount and pay for the fee, but the problem is that the transaction will also usually make a dust output (an output of less than 5460 satoshis). One solution is to just automatically give the extra dust to the person you are sending to. Another is to give it to the miners (by not claiming it in any of the outputs). A better solution is to use another UTXO that you own and be able to make a refund UTXO which is not dust, but this is not always possible.

In all of these solutions, no dust outputs are created. But if the wallet software just makes the transaction the usual way and give the leftover change back to yourself without checking to make sure that it's not dust, then what you saw happens and your transaction is not mined and then is eventually thrown out when it becomes old enough.

It's pretty unlikely that this bug would even be apparent in a particular transaction (about a 1 in 18,315 chance), but obviously not impossible, since you had this problem! Probably blockchain.info will apply the fix if enough people complain about it.


Bitcoin API - createmultisig - what is redeemScript?

To really understand this, you would need to read the protocol specs.  But I'll describe it briefly.

Each transaction contains a script.  In order to claim the bitcoins from a transaction (e.g.: you want to spend them in a new transaction) you have to provide whatever proof is described by the script.

Normally, the script is pretty much the same: the intended recipient has to provide a digital signature that proves they own the destination address.  But you can requires a lot of different kinds of proof: require more signatories, no proof at all, or require the claimant to solve a puzzle.


You can create a directory junction (as i did to move the BitCoin data folder), or you can specify a different data folder location:

BitCoin-qt.exe -datadir=d:\BitCoinData

Which will be the long-term solution.


Howto scale thousands of bitcoin accounts properly with bitcoind deamon?

Several options:

Don't use bitcoind
Use bitcoind to interface the p2p network but ignore accounts and other abstractions
Hack bitcoind to use by-account indices


Is there a way to access transactions that happen inside exchanges?

There are no blockchain transactions within an exchange.

Let me explain: (Y = you, B = someone else, C = someone else, E = exchange, assume that all people have 0 BTC, but C has 1 BTC so far)

  You send 1 BTC as a blockchain transaction to the adress of E.
  => E makes a database entry "Y have 1 BTC".

-

  B buys 1 BTC from C
  => E makes a database entry "B has 1 BTC" and "C has 0 BTC" (no blockchain transaction).

-

  B sell his 1 BTC to C
  => E makes a database entry "B has 0 BTC" and "C has 1 BTC" (no blockchain transaction).

-

  You transfer your BTC to your own adress as a blockchain transaction
  => E makes a blockchain-transaction and an entry "Y have 0 BTC".

They don't need to make blockchain-transaction within their service. They do just edit their database which tells them who has how many BTC. And as you don't have access to their database, you can't see those edits.


Does anyone know which country has the most bitcoins?

Finding out which country has the most Bitcoin's is not something that you can easily calculate it is very difficult as it involves geolocating the IP addresses. But with the way they get transferred it could be very different the next day. Also a lot of Bitcoin users are concerned about privacy and security and it may be difficult to acquire the actual geolocation data.

On the other hand.I can give you the numbers for Top five countries for Bitcoin downloads as of Today
1.US (1,207,661)
2.China (505,904)
3.Germany (270,043)
4.UK (236,523)
5.Russia (226,680)

Hope this helps


how long does it take for an mining machine to exhaust 2^32 in minutes and what is the actual speed of mining machines?

According to the Bitcoin wiki, it refers to:

  Hash per second is an SI derived unit representing the number of double SHA-256 computations performed in one second, referred to as hash rate. It is usually symbolized as h/s (with an appropriate SI prefix).

You are correct in noting that the nonce space is quickly exhausted with modern miners.

This is solved by updating the so-called "extraNonce" in the coinbase transaction. This has the effect of changing the hash of the coinbase transaction, which in turn changes the merkle root included in the block header. This essentially provides an additional 32 bytes of nonce space, since the coinbase tx can be modified as many times as required.

Additionally, but not nearly as relevant with today's hashrate, the timestamp field of the block updates every second and allows for all nonces to be recalculated with the new timestamp as well.


There will be 32 more if the precision doesn't increase. If Bitcoin lasts this long (very unlikely), precision probably will be increased.


Use bitcoins at bitstamp to buy something online

If you want to buy something with bitcoin, you either need to find a seller who accepts bitcoin as payment, or you need to convert your bitcoin into a currency that seller will accept.

Assuming that the seller in question accepts bitcoin, you will need to send that seller bitcoin in whatever way the seller has set up for you to do so.  Usually this means clicking a link, scanning a QR code, or copying a Bitcoin address into your wallet software.  From there, the seller will see your transaction in the mempool, probably wait for at least a single confirmation, and then process your order.

If the seller does not accept bitcoin, you will need to convert your bitcoin into a currency that is accepted.  This can be done at an exchange (such as bitstamp), using whatever process and rules that exchange has in place.  Usually, this means tying your account with them to a traditional bank account, so that the exchange can deposit your fiat currency into that bank account.  From there, simply pay the seller in whatever means your bank provides.


Where is the nonce incremented in Bitcoin source code?

Line 132 in src/mining.cpp in the generateBlocks method.

while (nMaxTries > 0 && pblock->nNonce < nInnerLoopCount && !CheckProofOfWork(pblock->GetHash(), pblock->nBits, Params().GetConsensus())) {
    ++pblock->nNonce;
    --nMaxTries;
}

Update: Given @MeshCollider's answer I guess this is now only relevant on the regtest network.


Sweeping a bitcoin private key using PHP

No MVP PHP code, but some bits that could help.

  verify the private key

Assuming you want a private key to be in the secp256k1 ECDSA range. You could check if the key is any number between 0x1 and  0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140. Take a look in the bitcoin wiki entry to private keys about the key range.

  Get the public address using that private key

The library BitcoinECDSA.php could help you out here. Especially

$bitcoinECDSA->setPrivateKey($privateKey);
$bitcoinECDSA->getAddress();

  3 + 4.Check the balance using an external api and sweep if balance > 0

This step can be easily combined. If you want to rely on a third party you could use the Block.io PHP API and Libary. They have an example PHP code for sweeping.


How many computers are connected to the "Ledger" or the Blockchain of Bitcoin?

Somebody asked me about Bitcoin and I explained to him many many computers are connected to the Blockchain to keep records of all the accounts (or to keep addresses of the bitcoin and owner?).

The blockchain is the data structure they collectively maintain. It is not an "entity" that can be connected to. The nodes are just connected to each other, and tell each other about updates they learn about.
It's hard to count how many nodes there actually are. There are sites like https://bitnodes.io that keep track of reachable nodes. However, there are many nodes on the network that only connect out to others but can't be connected to; probably in the 100000s.
A further complication is that not all of these nodes are equally relevant. It's easy to spin up a few hundred nodes on AWS, that nobody uses for anything, but do make it look like there are lots of independent users. Worse, there are also a lot of spy nodes on the network that don't do any work, except trying to monitor which nodes are the origin of particular transactions.
In the end, if you run a node yourself, it doesn't matter. It validates everything the network tells it, so if you do that, the part that matters is: 1 node, your own.


Current simple ways to participate with a Lightning Node?

As for the first part: Technically you currently still need a full bitcoin node in order to have your own lightning node. Also you should have your lightning node online most of the time. As in terms of financials no special hardware is needed. People are able to run a lightning node on hardware next to their router with little costs of hardware and little cost of electricity. For example with the DIY RaspiBlitz.

Concerning the second part: You can try https://github.com/lightning-power-users/node-launcher/releases or https://zap.jackmallers.com/ if you want to use your own hardware. Also there is a commercial counterpart to the before mentioned open source RaspiBlitz which is called the casa hodl node. As for mobile wallets there are currently no fully functioning mobile wallets available. The closest that you can get is Eclair for testnet. They announced that the mainnet release is supposed to come soon. A mainnet release which does not have the ability to receive funds is already available.

It seems like there is a trend for mobile custodial solutions like bluewallet or wallet of satoshi. I should also mention the bitcoin lightning wallet. There is also a clear trend for so called remote controls. These are apps that give you a nice interface for your lightning full node which stands at home or in a server center. For c-lightning there exists spark wallet and for lnd there seems to be bluewallet also available as a remote control. Also I should mention that electrum is working on a lightning wallet which was supposed to be released in the beginning of this year.


How do I get hash to verify transaction?

Here is how things can be done backwards.  Unfortunately, the bitcoin-explorer (bx) verify mechanism works a little differently but somewhat similar to what you were expecting.  Step 4 below might provide details that might be useful for what you are doing. Step 5 below completes the validation offline.

1. Here is the easy way to compute transaction IDs from the raw hexadecimal transactions.

% echo 01000000018a8a9f938c251be60da2711c6bf168c66213fae8e26251fcec47f9a41d0e71e3020000006b483045022100ad775acd2d0b14904771c28754e0e510ecd8af842732c5c15a0899d1e28ed42902204efb34805a958174f6a6273444cde7f97cf38cec0d96d17c7921490f58e6379d012103c0f217eb4428c61d47d8aa084a28c3d3d26f43b6569283f08fec5451a5fc8c98ffffffff0200803801000000001976a914d2c6b9c7f146ea4039e6ae67904eb94d479b7ed688ac06d79e460e0000001976a914b85f8cde95fe9b30872e49d5b961a4af5d07518688ac00000000 | bx bitcoin256

9b4912711de5e258a74a529227f43647bc3b2304212fb508c5f8e910d5986270

2. Here are two means (1st is offline, 2nd is online) to extract the Endorsement/Signature and associated Public Key used for the TX_ID 9b4912711de5e258a74a529227f43647bc3b2304212fb508c5f8e910d5986270 input:

% echo 01000000018a8a9f938c251be60da2711c6bf168c66213fae8e26251fcec47f9a41d0e71e3020000006b483045022100ad775acd2d0b14904771c28754e0e510ecd8af842732c5c15a0899d1e28ed42902204efb34805a958174f6a6273444cde7f97cf38cec0d96d17c7921490f58e6379d012103c0f217eb4428c61d47d8aa084a28c3d3d26f43b6569283f08fec5451a5fc8c98ffffffff0200803801000000001976a914d2c6b9c7f146ea4039e6ae67904eb94d479b7ed688ac06d79e460e0000001976a914b85f8cde95fe9b30872e49d5b961a4af5d07518688ac00000000 | bx tx-decode

or

% bx fetch-tx -c ~/bitcoin-explorer/bx-mainnet-remote.cfg 9b4912711de5e258a74a529227f43647bc3b2304212fb508c5f8e910d5986270

that both yield:

transaction
{
    hash 9b4912711de5e258a74a529227f43647bc3b2304212fb508c5f8e910d5986270
    inputs
    {
        input
        {
            address_hash a0d48c129cfde8f124a16f4d69bc47fd7fb5780d
            previous_output
            {
                hash e3710e1da4f947ecfc5162e2e8fa1362c668f16b1c71a20de61b258c939f8a8a
                index 2
            }
            script "[3045022100ad775acd2d0b14904771c28754e0e510ecd8af842732c5c15a0899d1e28ed42902204efb34805a958174f6a6273444cde7f97cf38cec0d96d17c7921490f58e6379d01] [03c0f217eb4428c61d47d8aa084a28c3d3d26f43b6569283f08fec5451a5fc8c98]"
            sequence 4294967295
        }
    }
    lock_time 0
    outputs
    {
        output
        {
            address_hash d2c6b9c7f146ea4039e6ae67904eb94d479b7ed6
            script "dup hash160 [d2c6b9c7f146ea4039e6ae67904eb94d479b7ed6] equalverify checksig"
            value 20480000
        }
        output
        {
            address_hash b85f8cde95fe9b30872e49d5b961a4af5d075186
            script "dup hash160 [b85f8cde95fe9b30872e49d5b961a4af5d075186] equalverify checksig"
            value 61314356998
        }
    }
    version 1
}

Distinguished Encoding Rules (DER) formatted Signature = 3045022100ad775acd2d0b14904771c28754e0e510ecd8af842732c5c15a0899d1e28ed42902204efb34805a958174f6a6273444cde7f97cf38cec0d96d17c7921490f58e6379d01

R =

% echo 3045022100ad775acd2d0b14904771c28754e0e510ecd8af842732c5c15a0899d1e28ed42902204efb34805a958174f6a6273444cde7f97cf38cec0d96d17c7921490f58e6379d01 | cut -c 9-74
00ad775acd2d0b14904771c28754e0e510ecd8af842732c5c15a0899d1e28ed429

S =

% echo 3045022100ad775acd2d0b14904771c28754e0e510ecd8af842732c5c15a0899d1e28ed42902204efb34805a958174f6a6273444cde7f97cf38cec0d96d17c7921490f58e6379d01 | cut -c 79-142
4efb34805a958174f6a6273444cde7f97cf38cec0d96d17c7921490f58e6379d

Pubkey = 03c0f217eb4428c61d47d8aa084a28c3d3d26f43b6569283f08fec5451a5fc8c98

3. The 3rd output of TXID e3710e1da4f947ecfc5162e2e8fa1362c668f16b1c71a20de61b258c939f8a8a contains the original input script that was signed, requires an additional online query:

% bx fetch-tx -c ~/bitcoin-explorer/bx-mainnet-remote.cfg e3710e1da4f947ecfc5162e2e8fa1362c668f16b1c71a20de61b258c939f8a8a

transaction
{
    hash e3710e1da4f947ecfc5162e2e8fa1362c668f16b1c71a20de61b258c939f8a8a
    inputs
    {
        input
        {
            address_hash 3480cd7a92d09974aacc473512ca80a686249498
            previous_output
            {
                hash 4b7b945088ad38de258490d02bdca724548818e1ad184d0e00a2d4d1e82229c8
                index 0
            }
            script "[3046022100da2122351174582ca4f8b9cfc2567bd2c95c3f30be13ce0f20422ba6c2d55806022100af211740671144cc8cbce04e8028e60eb1028af661a8eba77430e4a8615925da01] [02416953ece00bbc3a1ebca108c8961abae0bcc613ecf838bb0e5799202fbe7ae4]"
            sequence 4294967295
        }
    }
    lock_time 0
    outputs
    {
        output
        {
            address_hash ead65b0c5d7abc0af467ae2f34ed1b84a6662fda
            script "dup hash160 [ead65b0c5d7abc0af467ae2f34ed1b84a6662fda] equalverify checksig"
            value 12557630
        }
        output
        {
            address_hash 59cca2f8c91a9784c6c38da5a10f00644238b527
            script "dup hash160 [59cca2f8c91a9784c6c38da5a10f00644238b527] equalverify checksig"
            value 10100000
        }
        output
        {
            address_hash a0d48c129cfde8f124a16f4d69bc47fd7fb5780d
            script "dup hash160 [a0d48c129cfde8f124a16f4d69bc47fd7fb5780d] equalverify checksig"
            value 61334886998
        }
    }
    version 1
}

ASCII encoded script = "dup hash160 [a0d48c129cfde8f124a16f4d69bc47fd7fb5780d] equalverify checksig"

and computing the corresponding P2PKH address:

% echo a0d48c129cfde8f124a16f4d69bc47fd7fb5780d | bx address-encode -v 0

1FfPjjFG1uoA62yiTsje8biYYvEhf8puQP

4. For self awareness, compute Hex encoded script and associated sha256 value:

% echo "dup hash160 [a0d48c129cfde8f124a16f4d69bc47fd7fb5780d] equalverify checksig" | bx script-encode

76a914a0d48c129cfde8f124a16f4d69bc47fd7fb5780d88ac

% echo 76a914a0d48c129cfde8f124a16f4d69bc47fd7fb5780d88ac | bx sha256
0d9288118ccdc74e6ce85ced746aa48afbd30eb70f58e4ce009a78dd96faf33d

5. Confirm signature is valid using an offline command:

% echo 01000000018a8a9f938c251be60da2711c6bf168c66213fae8e26251fcec47f9a41d0e71e3020000006b483045022100ad775acd2d0b14904771c28754e0e510ecd8af842732c5c15a0899d1e28ed42902204efb34805a958174f6a6273444cde7f97cf38cec0d96d17c7921490f58e6379d012103c0f217eb4428c61d47d8aa084a28c3d3d26f43b6569283f08fec5451a5fc8c98ffffffff0200803801000000001976a914d2c6b9c7f146ea4039e6ae67904eb94d479b7ed688ac06d79e460e0000001976a914b85f8cde95fe9b30872e49d5b961a4af5d07518688ac00000000 | bx input-validate -i 0 03c0f217eb4428c61d47d8aa084a28c3d3d26f43b6569283f08fec5451a5fc8c98 "dup hash160 [a0d48c129cfde8f124a16f4d69bc47fd7fb5780d] equalverify checksig" 3045022100ad775acd2d0b14904771c28754e0e510ecd8af842732c5c15a0899d1e28ed42902204efb34805a958174f6a6273444cde7f97cf38cec0d96d17c7921490f58e6379d01

The endorsement is valid.


How should one try verifying to whom a given Bitcoin address belongs?

The v0.5 client (still experimental as of time of writing) supports a function where you can sign a text message with a private key.

So you could:
a) have a "register" button next to the address.
b) provide the user a message to sign which includes some identifying information (account name, email address, etc) and the address.
c) user will run bitcoind signmessage  ""
d) this will sign the message with user's private key.

Only a user which has access to the private key that corresponds to the address in question will be able to generate the correct signature.  Think of it as similar to a Bitcoin transaction but it isn't published to Bitcoin network and involves any text message.

Eligius uses this method to link NMC payment addresses to BTC payment addresses for his pool.

http://eligius.st/

Obviously this will have more value once Bitcoind v0.05 is publicly released.


Why transaction is signed with locking script from the input transaction?

There is no definitive answer here, and you'd need to ask the system's creator to be sure.

My guess is that it was due to interaction with a feature that we're now calling 'delegation': the ability for someone to presign a transaction, and add a new unlocking script- effectively delegating the right to sign to someone else under certain circumstances.

Elements of the script language that point in this direction include the existence of OP_CODESEPARATOR, and the original execution model of running scriptSig + scriptPubKey in one go, rather than separately as is done now.


About a change in 0.8.6 - free transactions with less than 0.01 outputs

Initially, "dust" transactions were made nonstandard in commit 8de9bb53:

  Define dust transaction outputs, and make them non-standard


CLI: Generate a new private key, unrelated to any existing wallet

Maybe do:

1.) Move to current wallet.dat to a different location (will result in creating a fresh wallet)

2.) Start bitcoind/qt with -keypool=1 (if you want to avoid keypools)

3.) Call getnewaddress

You might also consider using a hardware wallet.