Proving to a title agency a bitcoin transaction occurred?

Things to prove:

Ownership

Address A belongs to Person 1

Person 1 controls the private key allowing spending from Address A

Address B belongs to Person 2

Person 2 controls the private key allowing spending from Address B

Transaction T transferring an amount from Address A to Address B

occurred

was transmitted
was accepted
was confirmed
was included in a block

the block is a part of the longest chain, the blockchain.

Proving ownership of an address

Ownership is significantly easier to prove, provided that judge (to whom all this is proven), accepts either: economic activity or digital signature as proof of control of a private key.

Economic activity

Unfortunately, there is time and/or value cost to proving economic activity.

The judge could

ask each prover to reproduce the transaction at a given time, but at a negligible amount: 1 satoshi plus a sufficient transaction fee. That the original transaction could be reproduced with only the amount changing, and a reverse of the transaction executed as well, should suffice to demonstrate that each Person controls the private key sufficiently to engage in economic activity.
ask each prover to send 2 satoshi plus double the sufficient transaction fee to the same address: an address supplied by the judge, who then returns half of what was sent to demonstrate their own control of the address to which the 2 satoshi transaction was sent. This demonstrates that Person 1, Person 2, and the judge all control the addresses they say they do sufficient to engage in economic activity.

The costs of either of these are obvious, but generally sufficiently negligible as not to be a significant burden on any party involved. The transaction fees could be omitted, provided the transferred amount is sufficiently large to be both processed without transaction fee and trusted to be returned by the recipient.

The trust of these transactions could be increased by the judge assigning a random two-digit amount of satoshis to each transaction, or basing that random amount on an agreed-upon, yet-to-happen event with an expected time period within which the proving transactions must be transmitted to the judge. An example of a yet-to-happen event would be a newspaper headline or simply the leftmost two numbers in the 10th oldest block at a certain date and time.

Another, more convoluted yet more humanly trustworthy way would be for the judge to provide a private key to each prover. The prover then transmits an amount to an address controllable by that private key, then immediately returns that same amount using the provided private key. The judge has temporary control, though, so trust in the judge is necessary.

This method is infeasible if the parties are unable to broadcast the transactions to the network or the time necessary for transaction confirmation is too long.

Digital signatures

If the judge is familiar with how digital signatures work, or can be convinced of their validity, then this is an option. Some effort might be worth it, as this option is without economic expenditure and does not require the time necessary for the proving transactions described above to be confirmed by the network.

The judge provides a unique text to each prover. This phrase can be something sensible or randomly generated. Random is probably better, largely because it would take less time to generate. Alternatively, basing that text on an agreed-upon, yet-to-happen event with an expected time period within which the signature must be transmitted to the judge. An example of a yet-to-happen event would be a newspaper headline or simply the leftmost two numbers in the 10th oldest block at a certain date and time.

The signatures should be sent among all parties, so that all adversarial parties can verify the signature.

Remember that the point of this exercise is to demonstrate control of the private key. A downside of this is that not all wallet softwares support signing data, most commonly because the private keys backing the wallet are not exposed to the user in anyway except for the purposes of signing transactions. If a prover claims that their software does not have this functionality, this method is infeasible. The prover could be convinced to use another software, but that could compromise their position if they could be tricked into using malicious software, if a false positive proof of control is undesirable.

A combination of the two

Each of these methods has strengths and weaknesses, so a combination of the two would likely provide the most confidence proving control of a private key, and thus control of an address.

Proving that a transaction occurred

The easiest way for a judge to verify that any given transaction occurred is to use a trusted blockchain explorer program, since few wallet programs expose functionality enabling the user to search the blockchain by address, transaction, or block.

The judge can use the explorer verify the activity of each address in question, as well as the transaction itself. It is up to the judge to verify that the transaction has been a part of the longest chain for a permissible number of blocks. One block depth is sufficiently secure against most attacks that would cancel the transaction, but each additional block depth further solidifies the transaction.

This does not necessarily require network connectivity if the transaction occurred sufficiently far in the past that the judge's own copy of the blockchain can be explored.

If the judge does not have access to a copy of the blockchain, the desired proof cannot be surely obtained. Given the raw transaction, the judge can use the digital signature method to verify that Person 1 has control of Address A, as the raw transaction will contain a verifiable signature. However, the raw transaction itself contains nothing that would enable to the judge to verify Person 2's control of Address B.


How to get the Z value aka Hash of the outputs to be signed

0) read How to redeem a basic Tx?

1) take your transaction as array of bytes

2) replace all input scrips to empty scrips

3) replace one input script to original "OP_DUP OP_HASH160..."

4) append "hash code type" SIGHASH_ALL

5) take sha256 ( sha256 ( data ) )

that's all

Have a look on my code

const MyKey32 Transaction::getRawHash ( const int n, const QByteArray& scr ) const
{
  MyByteArray ret;                                    // create empty array
  Stream stream ( s );
  ret.putInt32 ( stream.readU32 ( ) );                // version
  ret.putVarInt ( stream.readVar ( ) );               // input count
  for ( int i ( 0 ); i < inputs; i++ )                // copy all inputs
  {
    ret.append ( stream.readHash ( ) );
    ret.putInt32 ( stream.readU32 ( ) );
    stream.skipVarData ( );                            // skip original script
    ret.putPrefixed ( i == n ? scr : QByteArray ( ) ); // !!! script replacement
    ret.putInt32 ( stream.readU32 ( ) );
  }
  ret.putVarInt ( stream.readVar ( ) );                // output count
  for ( int i ( 0 ); i < outputs; i++ )                // copy all outputs byte-by-byte
  {
    ret.putInt64 ( stream.readU64 ( ) );
    ret.putPrefixed ( stream.readVarData ( ) );
  }
  ret.putInt32 ( stream.readU32 ( ) );                 // lock
  ret.putInt32 ( SIGHASH_ALL );                        // !!! append hashcode
  return MyKey32 ( ret.constData ( ), ret.size ( ) );  // create hash256 of array
}


reconstruct block template from stratum mining.notify

If there is only one output address, we can guess here that the reward is the 8 bytes before the 1976,

No, you cannot. the 1976 is the start of the output script and can/will be different depending on the output script (i.e. address) that the pool wants to use.

The stratum protocol says that the hex for the coinbase transaction is coinb1 + hex(extranonce2) + coinb2. extranonce2 is produced by the miner and is of a size specified by the mining pool as the Extranonce2_size from the response to mining.subscribe.

So you can just create bogus extranonce2 of the correct size and concatenate the strings together as described earlier. Then put the result into a raw transaction decoder. Without the full transaction with everything (or placeholder data) in place, you cannot really properly decode the transaction reliably.


What dependencies are needed to build the dogecoin client?

somehow or another, I got this to compile.  it was some combination of:

install libboost1.48-all-dev libdb++-dev

then install without version number

then compile, compile fails

blocked packages

start over

install without version number

compile works

I don't remember, but it seemed random.

Much frustrating.

If I knew for a fact the correct dependencies, I would say so.  but, the dependencies for the client and the digger (minerd) are, or might be different, and I was compiling both.

All I'm certain of is that the documentation wasn't correct.

Ubuntu 12.04LTS  (probably didn't help, old version)


Your code stores only the results of the getblock call. This returns the block headers and the tx hashes of the block, but NOT the actual tx's themselves.

Each transaction hash is only 8 bytes, an actual transaction is roughly 500 bytes, so you're missing about 500 bytes per tx in each block.

There have been about 116 million transactions in the history of bitcoin, so 500 * 116 million ~ 60 billion bytes or about 60 GB that you're missing.


Coin selection algorithm in Python to optimally select UTXO

I'm currently compiling a master thesis on the topic of coin selection and I'm not aware of a Python implementation of Bitcoin Core's coin selection algorithm.


Using CLTV can I freeze some funds from a wallet, and make them available, in a single transaction?

When you lock coins in CLTV you still have to provide an address in the output. In that field, you can just include the address that your wallet controls. When you spend those coins, all you need to do is include the nlocktime which is higher than that specified when locking using the CLTV opcode. You need not do a second stage transaction to send the bitcoins to an address controlled by your wallet.


Witness data storage localisation in the blockchain

If the client is SegWit enabled, the full transaction including witness data can be stored in the same format as the transaction is received over the wire. There is no need for separate storage - it can all be included in the block.

If the client is not SegWit enabled, SegWit transactions are stripped of their witness and the witness marker/flag before sending/receiving, so these clients will not receive witness data, and therefore will not store it at all and will only use the legacy format.

This means the block storage between the two clients is different, but they are still sharing the same blockchain and transaction history.

Compatibility is made possible because even when SegWit is used and the witness is present, the SegWit client will calculate a txid by stripping the transaction back to its legacy format (removing the witness parts) before hashing. The txid is common between the SegWit and non-SegWit clients as a means to identify which transaction is being referred to. SegWit clients can identify data by a wtxid too, which is the hash of the serialized transaction with witness format - but this wtxid is not used as part of a txOutPoint to refer to a previous transaction - the txid is always used.

SegWit transactions are forward compatible with non-supporting software clients because the transaction with its witness data stripped from it appears as though it is an ANYONECANSPEND transaction - the stack is left with a non-zero value on top after evaluating the scriptPubKey, which is indicates successful evaluation.


Where can the Coinbase referral link be found?

In your profile settings you can get your referral link to invite your friends.
I think both of you will get $10 when your friend spends $100 in buys.


two block are broadcast almost at same time, which will be accepted?

Currently the Satoshi client will simply pick the one it sees first. Since most mining pools use the Satoshi client as their connection to the Bitcoin network they will build on top of the first block that is propagated to their node. The block that is propagated the furthest is therefore most likely to be the winner, i.e., the block that is part of the longest blockchain.

As you probably may have guessed there are also other strategies to pick the block to build on top. For example it might be the case that a block with more transactions offers more transaction fees to be claimed, hence a purely selfish miner may replace an earlier block with a new block that offers a higher reward. By that time however the miner has already spent some time trying to build a new block on top of the block with fewer fees, and it might have found a successor already.

So in the end, miners always work on the block they saw first (mining on top of an old block is rarely advantageous), and if they are selfish they may chose to replace their current base for a newer block if it offers more fees. Such a higher value block might however not be propagated to all miners, but that's another story.


Which ASIC Bitcoin Miner gets you best bang for you buck as of today?

ASICminer and Avalon are already deploying, and they will hit over 100Th/s before too long.   Butterfly Labs has 75,000 chips on their way, each at 7.5Gh/s, this will account for another 560Th/s.  Avalon has sold out batch 1 and 2.   ASICminer is in the process of deploying their farm.   BFL has 19500+ orders.   Many of those orders are for multiple units.

Basically, many people have pre-ordered based on the idea that they are going to get rich quick, so they have overbought.   This was part of why BFL has delayed so long I believe, to generate more orders than they would if people knew how far up the difficulty was going to go.   Go ahead and order if you want, but realize that ROI could be much longer than you anticipate.   Safe bet would be to wait a couple months to order, then you will have a much better idea.   Honestly at this point, there are so many orders in front of you, it will only make a few days difference whether you order now or later.


What is the true number of confirmations before a LTC mined block moves out of the immature state?

100. You could argue 120 too. It's the same as Bitcoin.

static const int COINBASE_MATURITY = 100;

Source

Now, this is the amount of time before other nodes will let you spend your mining income. However, the client will wait 120 blocks before telling you that the generation has matured.

int CMerkleTx::GetBlocksToMaturity() const
{
    if (!IsCoinBase())
        return 0;
    return max(0, (COINBASE_MATURITY+20) - GetDepthInMainChain());
}

Source


Does a wallet containing multiple addresses have a single private key?

There are three main types of wallets:

non-deterministic (random) wallets
sequential deterministic wallets
hierarchical deterministic wallets

With a non-deterministic (random) wallet, all the private/public keypairs are generated randomly. The wallet may generate 100 random private keys as soon as it is initialized, for example.

With a sequential deterministic wallet, a passphrase or sequence of characters is randomly generated to act as a seed. It is then repeatedly incremented and hashed to generate new private keys.

With a hierarchical deterministic wallet, a single keypair is created initially and is known as the master keypair. This master keypair is used to generate child keypairs (remarkably, new bitcoin addresses can be generated using just the public key).

Here's a more in-depth explanation: What is a deterministic wallet?

Also, here's my python implementation of a sequential deterministic wallet. And here's a good example of a hierarchical deterministic wallet.


How many addresses does my wallet.dat contain? Do I need to make a new backup every time I make a transaction?

By default, Bitcoin Core creates 100 addresses the first time it starts, and tries to keep 100 not-yet-used keys in wallet.dat 'keypool' (when you unlock the wallet to make a payment it will generate more).

So you do not need to backup continuously. The 'getinfo' RPC command will tell you the time when the oldest not-yet-used key was generated ('keypoololdest').

Any wallet backup created after the keypoololdest time will be good enough to recover all of the bitcoins sent to your wallet, but I'd suggest you figure out about how long it will take you to send and receive 100 transactions (e.g. two per day would be 50 days) and then backup about twice as often as that (maybe once a month if you're making 2 transactions per day).

Be sure your backups are encrypted with a strong passphrase, and make sure you store them someplace off-site that is safe.

And for long-term storage of more than one or two bitcoins, use a hardware or paper wallet.


How can you buy XRP with BTC if you don't have any XRP?

You can buy some Ripple (XRP) from Bitstamp. At the time of writing, they were selling 50 XRP / 1 USD.


In stratum mining pools, are most miners working on the same set of transactions?

The stratum pool managing software I'm familiar with is https://github.com/zone117x/node-stratum-pool, so I can tell you what they do. Stratum is a protocol, though, so multiple pieces of software could implement it differently.

This parameter is controlled by the blockRefreshInterval in the config. Every blockRefreshInterval milliseconds, the stratum server checks the bitcoin core node, via RPC, for new blocks using getblocktemplate. If there hasn't been a new block since the last time getblocktemplate was called, then it sets the current job, which is returned to all new requests for work.

The polling interval suggested in the config is every 1 second. Miners may request work at very different rates as well, so some may be working on older work. As long as it's work for the next block, it's considered valid though. The pool does use the same node and mempool data to build blocks, though. So, given all these variables, miners most likely won't be working on the exact same transaction set.

Relevant bits of code:

https://github.com/zone117x/node-stratum-pool/blob/02e78da1ab53a2409bbb8721f9771346c373482b/lib/pool.js#L555-L562
https://github.com/zone117x/node-stratum-pool/blob/02e78da1ab53a2409bbb8721f9771346c373482b/lib/jobManager.js#L138
https://github.com/zone117x/node-stratum-pool/blob/02e78da1ab53a2409bbb8721f9771346c373482b/lib/pool.js#L492


What is needed for Bitcoin to become the reserve currency of the world?

You would be hit twice by the currency exchange anyway if you were to buy Bitcoins for your local currency, and then buy the foreign currency with Bitcoins. If you would perform those transactions at exchanges ran by large companies, there is little difference from a traditional model. If instead you would use exchanges like Mt.Gox, the spread would go back to the people, rather than a company. The spread might be smaller or bigger, it all depends on the market.
Banks and companies like Visa often allow you to withdraw foreign money at a local ATM in the foreign country, sometimes even not charging you anything for the operation asides the money conversion spread. You perform only one conversion for the bulk of your money, and whatever is left over you can sell back at the money exchange. So by bypassing Bitcoins, you can save money (if the banks operated at a comparable margin as the Bitcoin exchanges, be they owned by a single company or not).
Most Bitcoin exchanges offer you money withdrawal to a bank local to the currency. If you were a tourist, this would not be convenient for you, as you wouldn't have an account in any bank like that. An alternative would be a service like OKPAY, but as it is to handle both Bitcoins and other currencies, there is no need for other exchanges.

So all in all, your proposed idea does not seem to be plausible at the moment. Main advantage of using Bitcoins for such a task is lowering the spread, which could also be accomplished without Bitcoins (say, an online community currency exchange). The proposed idea would however be more plausible if a whole country would adopt Bitcoins as its official currency, which is very unlikely to happen in the nearest foreseeable future (governments seem to move away from currencies tied to a limited resource, like gold or silver, to fiat currencies to enable easier growth).


Keep getting non base-58 character error when trying to recover my old wallet. Any ideas on how to troubleshoot this?

There are a bunch of +'s and /'s.

That strongly suggests it is data in Base64 encoding. Note that, in this case encoding does not mean encryption, just a specific printable representation of binary data.

Does anyone have any idea what I could try to see if this is it?

It seems several different wallets might use Base64 encoding, including:

Blockchain.info backup using AES encrypted JSON

Bitcoin Wallet for Android (Schildbach wallet)

Print wallet.dat with base64

Of those, I'd guess the first is most likely. But that's just a guess. There are probably numerous other possibilities.
I think I'd try the Blockchain.info recovery process first then, if that didn't work, try decoding the file from Base64 into binary and using a hex editor to look for patterns that might give some clues to the software that produced it. If the file is encrypted using a wallet password this probably would not be fruitful.


I understand that in selfish mining a malicious node can "send its entire hidden chain". Exactly how is this done? I know that usually a single block is broadcast-ed right after it is mined, but how does it relay an entire chain?

Forks appear naturally, when two miners produce competing blocks approximately simultaneously. Such forks may have arbitrary length (thankfully, with exponentially decreasing probability under reasonable assumptions), which may need to be resolved. Doing so involves having a mechanism of synchronizing chains where the receiver is missing multiple blocks. So there isn't anything special here, it's just the normal protocol for relaying blocks that is used.
What that protocol is depends on the software used.

The basic approach involves sending an inv for the new tip. The receiver will then fetch the block using getdata, notice it is missing its parent, and ask for that parent using another getdata and so forth, until it reaches a parent that the receiver already has.

Since Bitcoin Core 0.10, nodes will respond to an inv with a getheaders, to retrieve all block headers between a point the receiver already has and the announced tip. The request contains a list of recent block hashes the receiver has to avoid duplicating things. Only when the receiver has all the headers, and has validated them, it will start asking for the full blocks that are missing along the way. This permits fetching blocks from multiple peers in parallel.

Since the adding support for BIP130 ("sendheaders") in Bitcoin Core 0.12, announcements of new blocks themselves are done by immediately sending the headers, avoiding an inv + getheaders step.

Since adding support for BIP152 ("compact blocks") in Bitcoin Core 0.13, blocks can also be announced (in negotiated cases) without any inv or headers message at all, instead sending a compact block directly (which uses an encoding that avoids transactions the receiver is assumed to already have). In case there are missing transactions, or parent blocks, those are requested using the normal means (getdata or getheaders).

Note that all mechanisms are still available for all nodes on the network. The more modern ones are generally superior, but older or simpler software implementations can still use the inv/getdata approach if desired.


Are Bech32 addresses safe for mainnet usage?

Yes, they are. Bech32 addresses allow for native Segwit outputs, which offer higher efficiency and security than the legacy P2SH nested Segwit outputs. https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Reference_implementations has reference implementations in C, C++, JS, Go, Python, Haskell, Ruby, and Rust along with tests courteous of Pieter Wuille


The most commons, and which you need to understand best are those 3:

Legacy (P2PKH),  Pay-to-Pubkey Hash. begin with the number 1. Old addresses, fees are higher. Compatible with every software. Able to sign messages and get verified in every wallet.

Compatible (P2SH) begin with number 3. Segwit address, fees are intermediate. Widely supported and compatible with old software. "transitional" addresses until native segwit is fully adopted. Not able to get its messages verified in every soft.

Native Segwit (Bech32) begin with bc1. Lower fees. Not fully compatible with old software, like blockchain.com. Can't get messages verified in every software.

read more here: https://en.bitcoin.it/wiki/Address


Will bitcoind save all wallet transactions in prune mode?

As long as the wallet is in place before bitcoin core has a chance to
  prune anything, it will work properly
  Reference Link

Let me explain. Basically here is a simplified version of how bitcoind stores wallet transactions:

wallet.dat contains Private Keys | Synced upto Block | Wallet transactions
When new block arrives, bitcoind looks for wallet transactions in the block and adds the ones found into  wallet.dat and also updates Synced upto Block field
In prune mode, older block data is removed, nothing happens to wallet.dat

So if you activate prune mode on a running node, or boot up an old bitcoin node everything should work.
However, if you import an older wallet.dat into already running pruned node, it has to rescan everything from Synced upto Block to find the transactions. This may not be possible due to missing block data


Can a transfer be done over postal mail?

A1B1: Assuming you've prepared in advance, there are some nice offline wallet options.
A1B2: This one's tricky. I'm going to assume that you have access to a computer before running off into the woods, or what have you. I'm also going to assume that you know exactly the amount and address in advance.

Generate the transaction and sign it, but don't broadcast it (can be done with Bitcoin Armory)
Print out the transaction
When you want to make the transaction, mail the transaction to your agent.

A2B?: Easiest one. Just write down your private key and describe the transaction.
A3B?: Well, you're screwed, because the agent could just never make the transaction.


What RPCs can I use to transform an address to a paying script?

Try validateaddress, note the scriptPubKey in the output of these examples:
$ bitcoin-cli validateaddress bc1q7ckr2hlws6ku4mlaggvmfqwgs42zjm4qf3s7hy
{
  "isvalid": true,
  "address": "bc1q7ckr2hlws6ku4mlaggvmfqwgs42zjm4qf3s7hy",
  "scriptPubKey": "0014f62c355fee86adcaeffd4219b481c88554296ea0",
  "isscript": false,
  "iswitness": true,
  "witness_version": 0,
  "witness_program": "f62c355fee86adcaeffd4219b481c88554296ea0"
}

$ bitcoin-cli validateaddress 1MWrgo4rm1aoPYFjCCMXgr1e564xVyHCqM
{
  "isvalid": true,
  "address": "1MWrgo4rm1aoPYFjCCMXgr1e564xVyHCqM",
  "scriptPubKey": "76a914e1080defe0aa086f1d5f698faf614e8f67af6e3b88ac",
  "isscript": false,
  "iswitness": false
}

Update: RPC getaddressinfo will also return the matching output script.


In the simplest way possible, describe how the 21 Million limitation is enforced to a non techie

The simple answer is that there is a constraint on the total number of coins that will be generated.

In economy the fact that the supply of newly minted coins is either constraint by a constant rate at which they enter the market or, like in Bitcoin's case, even that the total number that will ever be in circulation be limited.

Due to how the amount of newly issued coins in the Bitcoin network is reduced over time the total number of coins ever issued will converge to 21million. Every 210'000 blocks (or 3.993 Years in expectation) the number of new bitcoins that are issued in the network is halved. The result is that we have a sum of a geometric series, with each step being multiplied by 1/2.

Hence in the first step 50 * 210'000 = 10'500'000 coins were issued, in the current step half of that will be issued: 25 * 210'000 = 5'250'000 coins and so on. The sum of a geometric series that halves at each step is exactly twice the first step, hence 2* 50 * 210'000 = 21'000'000. This was also discovered by Euclid, hence the name.

Notice that this is an infinite sum that converges to an upper limit. Due to rounding involved in the protocol the sum will eventually end and no new coins will be generated.

These numbers were chosen by Satoshi in his original proof-of-concept client and have not changed since. At some point the values would have had to be chosen anyway and his approach of choosing easy to remember numbers are just as good as any (210'000 ~= 4 years, 50 bitcoins / block initially so in total it would be 100 * 4 years => 21'000'000 bitcoins).

That is not to say that nobody ever criticized the numbers and constraints. Several early ideas were put out there and sometimes even implemented that changed key parts of what parameters are chosen, be it Litecoin that uses inter-block timings of 2.5 minutes instead of 10 minutes, or some schemes that instead of relying on a limited total number of coins ever generated preferred to constrain the rate at which coins are generated. Fact is that the Bitcoin network still is the biggest of them, and only future will show whether the choices are right.

As for the enforcement of the constraint that's a bit more complex. You see when you join the Bitcoin network you implicitly accept the underlying rules the Network works with. This includes among other things the parameters Satoshi chose. So if you misbehave, e.g., by creating a block that gives you a larger amount of coins than is agreed on, the rest of the network will not accept that and ignore your claim. In a certain way all users in the Bitcoin network reached a consensus about what is and what is not valid. Any change to the inner workings of the network would require a majority of the stakeholders to reach a new consensus about whether to accept the change. If you do not follow the decision of the majority you will create a fork and live on that. If more people agree with you they might join your network, and some alternative chains might even be able to survive for some time. So the constraint is basically enforced by the majority of the users (or their computational power share in the network).


This article from coindesk may answer some of your questions although it is almost a year old now http://www.coindesk.com/year-multisig-so-far/

There's no information attached in multisig transactions to tell us what it is being used for so you can only guess. There are not any exchanges that uses multisig for any customer facing applications. There are however many online wallets, such as the one offered by Coinbase or Greenaddress , that uses multisig for better security.


Transactions can have multiple outputs. What you show are two outputs created by the same transaction.

The output positions are enumerated with the vout field. As the first one is vout = 0, the two that you show are the third and fourth output.


How can I recover bitcoins sent to derived addresses in Electrum?

Electrum and Mycelium Gear both use BIP32 for address derivation from a master seed, but Electrum is not BIP39 compatible. Thus you need to take the master seed (BIP32 Extended Key, iirc) and restore it in a new Electrum wallet, and that should work.

Alternatively, if you want to get individual address private keys you can use http://bip32.org - my suggestion is to use the "Download ZIP" function at the bottom right of the page, and work with the keys offline, otherwise there is a chance that compromised code could expose your private keys.


What's needed to host a competitive game site

How do current betting sites handle the deposits/withdrawals of bitcoins, and how do they keep a comission out of it?

Just like any other payment: you track the blockchain and keep balances in your server database.

You can charge the commission on deposit (e.g. 0.5% fee, when depositing 10BTC just credit 9.95BTC)
You can charge per game (e.g. when each player bets 5BTC in a 2 player game = 10BTC, only pay the winner 4.95 from their rival) and keep 0.05 (0.5%).
In betting games you can also schew the long-term statistics against you so the house has an edge (just like casino roulettes have 0, and some even 00).

  Any small site could rely on trust and do this in a manual fashion, but I'd assume any professional site does not handle this manually. So, is there an existing library (I'll use Node.js, in case it matters) or third-party service for this? And should the bitcoins be stored in a conventional offline wallet(s)?

This would work just like any other business, just browse this site. You can rely on external businesses to do this for you, or create the system yourself (leveraging libraries or not, you must listen to the blockchain events and act accordingly).

  And last, is there a way to "prove" that the games are fair in order to establish trust?

If games are deterministic (like chess) the issue boils down to trust between users (is this guy going to cheat me using a chess engine?) since you couldn't influence the outcome anyways.

If games are based on chance, either the users must have faith in you or you have to provide a way for the user to verify you're not cheating him. How such a scheme could be implemented depends on the detailed mechanics of the game (you could even leverage Bitcoin's blockchain for this).

  Are there any legal requirements regarding to this?

Dealing with the legal system is the hard part here. Just like any other legal matter... it depends on your jurisdiction! In my country you have to be audited before running a betting business.


I assume that James is using "sat/kw", to refer to "satoshi per kiloweightunit" as a means to express the fee rate of a transaction. "Weight" here refers to what replaced "blocksize" as a blockspace limit in the protocol rules with the segwit softfork.

I'm seeing "sat/kw" for the first time in this context. I've seen wu used before to refer to weightunits instead of w, and "virtual bytes vB" seem to be more common generally.

I've explained the relationship of blocksize, virtual size and weight in depth here: Is there a difference between bytes and virtual bytes (vbytes)?


Is there any reason for an alternative Bitcoin implementation to use Berkeley DB?

Backwards compatibility is a massive priority for Core and it is generally very conservative in its technology choices. I don't think it would consider a new (database) technology until it had been proven over many years on other projects. It is providing a consensus engine and infrastructure and doesn't have the same tolerance as startups or bigger corporations for cycling through different options and experimentation if it is going to endanger backwards compatibility or require many developer hours to revamp shortly afterwards.


This happens with many Ubuntu Apps. The simplest solution is to tap Alt any type the name of the menu item you wish to find.

Alternatively, hit Ctrl-Alt-F2, log in, type DISPLAY=:0.0 unity --replace hit Enter, and then do Ctrl-Alt-F7. The menu bars and the windowing system will reload.


The wallet.dat file contains your private keys, public keys, scripts (which correspond to addresses), key metadata (e.g. labels), and the transactions related to your wallet. If you have an HD wallet, it also includes the HD seed and and the derivation paths for each private key.


Is this a problem that a pool found 6 consecutive blocks?

It would be a statistical anomaly if this did not happen from time to time.

With pools having over 20% or so, they're bound to find 6+ consecutive blocks every now and then.

It's not a problem. They can't really abuse or corrupt the system like this, especially since they can't plan for this sort of thing to happen on purpose. Even if they'd have 30%, it's still a rare phenomenon (like less than once in a thousand tries).


How do nodes behave in light of a doublespend?

is it possible that two transactions are in same block. to my knowledge, each node will validate the transaction before it place in memory pool. so next time the same transaction appears, doesn't it invalidate the second transaction????

Yes, it is possible. The transactions that a node accepts to its mempool is completely up to the node and is not governed by consensus rules. The sane thing to do is to ensure that a transaction follows the consensus rules and some other local node policy rules before accepting it to the mempool, but that is not required. Thus if a miner is running custom software that accepts all transactions, they could produce a block which contains conflicting transactions.
Also, if a block contains conflicting transactions, then the block will be rejected, not the transactions. The block is then invalid, the transactions are still valid. If the transactions were first seen in the block, I think then both will be rejected.

2)if two transactions entered the network simultaneously, but at different endpoint, by the time the next block is mined it's likely that they would have made it into the same block and thus be simultaneously rejected.
isn't it the same case as above???

I believe the first scenario may be referring to two conflicting transactions which the miner includes in a block, not that the transactions were broadcast to the network. However both scenarios operate in the same manner.


What type of hedging might CoinLab be employing?

Bitcoins are easy to hedge against delivery by pre-selling, provided your working capital calculations are properly sorted, and you understand timing constraints throughout the systems you're dealing with.

We will sometimes be delivering digital goods through an intermediate currency as well, and we will use existing financial markets to sort/hedge that leg.

Shorting on Bitcoinica is another possibility, although it doesn't remove the need to manage your working capital (or credit lines)


Is it possible to track stolen Bitcoin after exchange

There were several transfers from your wallet to the thiefs wallet(s). This would be the chance to catch the scammer:

All involved bitcoin addresses needs to be analysed to see if there are more addresses belonging with a high liklihood to the same scammer.
All outgoing transactions from each of the addresses of 1) needs to be traced if they end up in one of the millions of known exchange addresses
If there are evidences then the police should ask the exchange directly (or via help of their peers in the exchanges country) for any information about the scammer which is likely their client. This can be the id, bank account, a bitcoin withdrawal address or an altcoin withdrawal address. In the first two cases you can claim back the lost funds. In the last two cases this is the starting point for a new analysis/tracing

If someone moves bitcoin to an exchange then the follow on activities aren't visible in the blockchain anymore, then the exchanges support is needed.
To be more specific I'd need to see the bitcoin address(es) where the coins went to after leaving your wallet.


As a small hotel accepting bitcoins, do I show only one payment address?

Creating a new address for every transaction (not just every single client) will allow you to maximize your payment tracking capabilities.

In case you have a single address for all of your payments it's really hard to track who sent you what. This will start changing from 0.9 on, but for now we have to stick to what is already implemented.

Having one address per customer will allow you to track payments although it's a bit of a challenge to get a customer's equity for a given period of time, as you will have to take into account your outgoing transactions as well, if any. In this case, of course, a customer must have a user account in your online booking system and you must then persist the user account model in a way that its unique identifier (be it the user's email address or account id) will have a 1-to-1 relationship in your DB.


With Miniscript why is it not possible to invert conditions with something like not()?

This answer was provided by Pieter Wuille (@pwuille) on Twitter.

Conceptually it doesn't make sense, because script conditions are monotonic. What would and(pk(A),not(pk(B))) mean? "B does not sign" is trivially satisfied; B would just never bother signing.

Similarly, not(older(N)) would not mean younger(N). There (intentionally) does not exist a way in script to express a younger-than condition (because it would mean a tx that invalidates itself). "not(older(N))" would just be "do not prove time is past N", also trivial.

For example, Miniscript l:older(N) translates to IF 0 ELSE <N> CHECKSEQUENCEVERIFY.

CSV and CLTV don't actually observe the time; they observe the nLocktime/nSequence field in the transaction. There wouldn't be any problems with having an ability in Script to make arbitrary (including less than, negation, ...) statements about them.

However, it would likely be pointless. The nSequence and nLocktime fields themselves do observe time, and can only express larger-than constraints. Bitcoin transaction validity should be monotonic: once valid, absent double-spend, they remain valid.

The alternative would be a logistical nightmare. All mempool transactions would need to be reevaluated every block. Reasoning about validity of unconfirmed transactions would be a pain (e.g. what if you're paid using a tx spending the output of a soon-to-be expired tx?)


Blockchain: How do nodes know what Data is correct from Consensus process?

Consensus

My understanding of this word, in the context of cryptocurrencies, is as follows:

In a finite network of nodes with independent data-storage, consensus exists if all, or at least a majority of, nodes hold a set of data that is identical to, or at least not inconsistent with, the data sets held by other nodes.

That is, consensus is a state, independent of the rules or mechanisms used to achieve it.

  How do nodes know what data is correct from consensus?

They don't necessarily. Consensus is sometimes really an emergent behavior, albeit a planned one. In some systems, nodes don't explicitly seek consensus - that is they don't confer about consensus as a subject - only about what blocks other nodes know of and have already validated.

In these types of system consensus emerges simply because nodes follow the same rules, for example that the chain with the most proof-of-work (or equivalent) is accepted and any alternatives are discarded.

  What about if two nodes execute two different consensus with 2 different Valid blocks with the same height at the same time, can that happen?

That can and does happen for a short while in at least some systems. For example, eventually one of those blocks will have more blocks built on top of it than the other. This block will be then accepted in place of the other by the node(s) that had previously accepted the other. The other block and all blocks built on it will then be discarded. Or there may be other ways in which rules resolve the Byzantine Generals problem.

In this specific example system, transactions in those discarded blocks are also then lost unless they have already been included in the rival block or in blocks built on the rival block. If not they may still exist in memory pools and be later incorporated into the blockchain. This is probably one reason why a significant number of confirmations are needed in this specific system.

Other sources:

Consensus in Blockchain Systems. In Short — Chris Hammerschmidt  — 2017


How to connect bitcoind mainnet node on AWS EC2 by using rpcjson?

Most likely, you'll have to open that port on your EC2 instance.


What is the difference between adjusted and reported volume for exchanges?

According to some research, reported volume is inflated by up to 95%. The figures in adjusted volume usually either remove exchanges whose reports are unreliable or attempt to determine the actual volume in some fashion. One source of highly increased volumes is that some exchange take fees for deposits and withdrawals but no fees on trades. Many sites remove trades without fees in their adjusted volume metric.

Liquidity pertains to the volume of the order books of an exchange.


How do I list all of my addresses in namecoind?

namecoind listreceivedbyaddress 0 true

0 means to include even transactions with no confirmations, true means to show even "empty" addresses


You will need a lot of experience and knowledge in many areas including cryptography, networking, programming, economics, and a lot of research into cryptocurrencies themselves before you'll be able to make one yourself.

Values are not assigned by the developers, just by the market, it is supply and demand which raises and lowers the price.


Routing for Lightning network: was Flare implemented?

As far as I know flare was never implemented for lightning nodes and is not being used. I think current implementations use sind pathfinding algorithms like BfS or  Dijkstra. The pathfinding itself is not part of the BOLTs anyway. A node could do whatever it wants with the information provided from the gossip store / gossip protocol. (BOLT 07). People could in particular decide to go for the approach given by flare.


i have lost 83$ worth bitcoin from my blockchain wallet can any one help me to recover it?

Bitcoin transactions are generally not reversible.  If this transaction has been confirmed, your coins are gone.

If you think the transaction was erroneous, you can contact customer support for your wallet provider.  If they discover that it was due to a bug in their system, they might reimburse your money.

Unfortunately, a common cause of such loss is that someone compromised your account, e.g. by guessing your passwords, or by hacking a computer that you used to log in to that account.  If this is the case, it's unlikely that you will be reimbursed, and all you can do is plan to improve your security in the future.

In either case, it would be unwise to use this wallet ever again.  If there are still funds there, transfer them immediately to a different wallet; ideally, one created using a freshly installed operating system on a secure computer.


When I buy a Bitcoin with dollars, where does the money go to?

You give the money to someone who has bitcoins available to sell to you.

This might happen via an exchange such as bitstamp.net which matches buyers and sellers.


lightning to lightning non custodial swaps

An HTLC always "freezes" funds. It is a smart contract that says "here is the balance and a hash. If you give me the preimage of that hash within time T, the balance is yours. Otherwise I can take it back.".

You can then use this functionality to achieve an atomic swap by going through a service node that is active in both networks and offers to swap currencies. Just route a payment from yourself to yourself via the swap service node, starting with currency X and ending with currency Y, switching currencies at the service node using the offered exchange rate.

Like every LN payment, this is trustless because it is atomic: Either all transfers take place or none. However, note that there is a free american option given to the service node here: For the time T, it can stall and observe the spot market and only do the trade if the exchange rate moves favorably for him, or otherwise just let it time out. This is why using LN for currency exchange might not be economically wise.


There's no free lunch.  You can spend all the UTXOs in one transaction to spread the output bytes across many inputs, but each input still needs a certain number of bytes.  To my knowledge, there isn't any more efficient way of spending them than the standard transaction types.  (If there were, it would be the standard.)

You can of course attach a fee below the current prevailing rate, and hope that the transaction gets picked up during some period of low transaction demand (when fees drop), or wait until such a time to broadcast your transaction.  Certain times of day or days of the week may be somewhat better; you could look back at historical transaction fees to get a sense.  But there's no guarantee that such a low-fee transaction will get confirmed.


Are ripple validation nodes appointed by central authority?

No. Nobody has any particular right to tell anyone what validators to use or listen to.

  If not, what prevents 51% attack through validator nodes?

It depends what you mean by a 51% attack. If you mean a case where validators refuse to agree, then a 51% attack would cause the attacked node to fail to make forward progress. In that case, one would hope the operate of that node would stop listening to the validators that are causing the problem. Validators sign every statement they make, so this is not difficult to detect.

A 51% attack on the XRP Ledger is extremely unlikely because it doesn't allow a double spend. It just stops forward progress. So some group would have to convince people to listen to their validators only to lose any credibility they had gained the first time they attempt such an effort.

We would expect users to choose validators based specifically on how unlikely they are to collude to DoS the network. So you would have to have someone go to all the effort to convince people they're not likely to do the very thing they intend on doing, and all they get out of it is perhaps a short term denial of service on the network and then they lose everything they worked to build. It's extremely unlikely such a thing would ever happen, simply because it's so much work to do and you have so little to show for it.

  Why ripple.txt file contains validation nodes list?

If users just want the system to work and don't particularly care how two valid but conflicting  transactions received at about the same time are resolved, they can just use the default list. If it stops working, then they can change it.

  Who maintains this list?

Whoever publishes that file. Anyone who wants to can publish such files.

  What is incentive for users to run validator nodes?

Roughly the same as running a bitcoin full node. If you're running an XRP Ledger node anyway, the additional cost to run a validator is effectively zero. It doesn't get you any special powers, just as running a bitcoin full node doesn't, but it does help to keep the network stable and resistant to DoS attacks. People who want the network to be stable and resist DoS attacks will have an incentive to run a validator.


Why do we need block hashes in blockchain?

on functionality:

from Andreas book "Mastering Bitcoin", Chapter 7:

  The primary identifier of a block is its cryptographic hash, a digital
  fingerprint, made by hashing the block header twice through the SHA256
  algorithm. The resulting 32-byte hash is called the block hash but is
  more accurately the block header hash, because only the block header
  is used to compute it...

This block hash is a reference to a previous block hash, which connects this block to the previous block in the blockchain.

  Is it only there for reference ??

no, it's a pointer to the previous block, so the chain can be established. As in the linked article:

  one can not simply create a block "isolated" from the blockchain
  and then just "insert" it in the blockchain to win the reward
  it's necessary that a previous block is known before a new valid one is created.

  using block height?

again from Andreas book:
A block’s block hash always identifies a single block uniquely. A block also always has a specific block height. However, it is not always the case that a specific block height can identify a single block. Rather, two or more blocks might compete for a single position in the blockchain.

Further down, he mentions, that this comes into play when discussing forks.


PSBT (BIP-174, Partially Signed Bitcoin Transaction) Ordering of keys

There is no mandatory ordering. If you assume your parser is correct, then it is fine to compare the objects themselves. However, to be sure everything is correct, I would suggest that you compare the serialized PSBTs themselves.


How do I delete the blockchain after uninstalling Bitcion Core?

You need to delete your data directory.

See the question Where is the data folder for Bitcoin-Qt? for where it should be installed by default on your system.

Make sure you backup wallet.dat first, if you've ever used any of the addresses in your wallet.


Lightning: How would I make a monthly payment to a utility company, etc

when reading your question - for the third time now :-) - I always come to the conclusion, that payment channels (with locktime, or nowadays with CLTV/CSV) would be the solution. They are used for quite some time, and they are uni-directional. The typical publisher model. You order a newspaper, send money, and get the newspaper for the next year. But two things against it: one would also have to do a deposit, and you are asking especially for Lightning...

  what's up with the common 'Alice and Bob both add 1/2 BTC to a
  channel' example?

the real world model might not be the one that you expect for a retail user, but gives a clue: Andreas describes in his book "Mastering Bitcoin" a scenario, where two exchanges manage funds, one in India, the other in USA. Both have users that transact somehow buying funds in different countries. So they want to transfer certain amounts cross border, and one exchange is Alice, the other Bob. Another business example I have is in my own environment: I am having a partner in Africa, and I am based in Europe. There are many people coming from Africa to buy goods in Europe, sell it in Africa, convert the money back to Euros, and restart the business travel. With more and more exchanges in Africa I am hoping that we can get rid of the FIAT exchanges (ten years down the road...) It is too expensive, even latest bitcoin fees in December were cheaper.
Anyhow, at the same time there are many people from Africa working in Europe, sending money "home". So these funds cross each other: business from Africa to Europe, and money for the families from Europe to Africa (and the FIAT world earns fees twice). The payment channel is supporting this in an optimal way.

  I'm looking for an answer that explains how I'd go about sending a
  payment to a hypothetical (mythical?) cutting edge utility company:

Well, as this is all too new, maybe it still needs some time. But in bitcointalk there are some "utility" discussions:

opening one side channel in Lightning:

a long discussion of use cases (car dealer and salary):

and some more (grocery and landlord).

  It seems that the expectation is that there will be an intermediary
  that I keep a large amount of funds with, and I would then use that
  central channel as a hub... true?

At the current point in time, from what I have read and understood (with my little bit of imagination), yes.


I have write this sample code, hope this helps

public class Main {
    private static NetworkParameters params = NetworkParameters.testNet3();
    public static void main(String...args) {
        String mnemonic = "brisk wood symptom party betray ozone dad super beyond sea memory power pig business extra";
        DeterministicSeed seed = null;
        try {
            seed = new DeterministicSeed(mnemonic, null, "", new Date().getTime());
        } catch (UnreadableWalletException e) {
            e.printStackTrace();
        }
        Wallet wallet = Wallet.fromSeed(params, seed);
        System.out.println(wallet);
        DeterministicKeyChain keyChain = DeterministicKeyChain.builder().seed(seed).build();

        // Derive 100 children, default lookahead is 100
        keyChain.maybeLookAhead();

        // Get M/0H/0/5 key, drive address along with other info for specific path
        DeterministicKey key5 = keyChain.getKeyByPath(ImmutableList.of(ChildNumber.ZERO_HARDENED, ChildNumber.ZERO, new ChildNumber(5)), false);

        System.out.println(key5.toAddress(params).toString());

        // derive 100 addresses along with private key
        System.out.println("_________________________");
        int i = 0;
        while (i < 100) {
            System.out.println(wallet.freshReceiveKey().getPrivateKeyAsHex());
            System.out.println(wallet.freshReceiveAddress());
            i++;
        }

    }
}


Is possible especify the keys rather how many in multisignature wallets?

You are right, multisig as implemented in Bitcoin right now requires M participants out of N to sign. However, the use case you want is doable with more complex scripting.

For example, K1 + (K2 or K3 or K4) could be done with something like:

<pk1> CHECKSIGVERIFY 1 <pk2> <pk3> <pk4> 3 CHECKMULTISIG

That script can be redeemed with the signature of K1 and a signature of one of K2, K3 or K4.


Follow this example: https://github.com/OutCast3k/coinbin/
This app does everything you need


Can I use Blockchain API to get number of transactions at BTC address?

You sure can!

Send a GET request to this address:

http://blockchain.info/address/$bitcoin_address?format=json

You'll get back something like this:

{
    "hash160":"660d4ef3a743e3e696ad990364e555c271ad504b",
    "address":"1AJbsFZ64EpEfS5UAjAfcUG8pH8Jn3rn1F",
    "n_tx":17,
    "n_unredeemed":2,
    "total_received":1031350000,
    "total_sent":931250000,
    "final_balance":100100000,
    "txs":[--Array of Transactions--]
}

The n_tx field will tell you how many transactions deposit or withdraw from that address.

Source.


There are 2 workarounds possible:

It takes few minutes for most of the transactions to be included in a block. So, you can prepare all the steps in advance and perform within couple of minutes before this transaction is confirmed.

Broadcast transactions with fee rate below 1 sat/vByte

Change Min Transaction Relay Fee in bitcoin.conf with minrelaytxfee=0.00000001
Either run multiple nodes on testnet with same configuration and add them using addnode or ignore this step.
Create a transaction with createrawtransaction, Enable RBF and specify fee rate below 1 sat/vByte with arguments "replaceable" : true and "fee_rate" : 0.5 in fundrawtransaction
Sign the transaction with signrawtransactionwithwallet
Broadcast the transaction with sendrawtransaction
Check the transaction details using https://chain.so/testnet/btc

Bump fee: bumpfee 42bb96fa5f5812cfd53695f679b69bccaf37fb4d49b78a650e05e0109d92f223
{
  "txid": "bac13170082c79033d37767e9180d676b05044acf90e41b1a992f76eda97f14e",
  "origfee": 0.00000526,
  "fee": 0.00005616,
  "errors": [
  ]
}


What is the significance of version byte and address checksum in version 1 Bitcoin address

How could they give the same result? You do RIPEMD160(SHA256(pubkey)). Then you add zero byte 0x0 to this and perform double SHA256. You take the first four bytes and use them as s checksum which means they are control digits which help the wallet determine you didn't misstype the address.

Now you take this whole thing zero-byte+RIPEMD160(SHA256(pubkey))+checksum and you convert it to base58check. Note: zero byte will make the address always start with '1'.

When sender gets a bitcoin address, their wallet converts it from base58check to hex, checks the checksum and removes both the zero-byte and checksum to get RIPEMD160(SHA256(pubkey)). Then it proceeds with scriptPubKey verification.

That's why it is called Pay-to-public-key-hash. Bitcoin address is just a way of encoding a public key hash.


How to change donation address of p2pool

It is a multisignature 2-of-2 address.

I have annotated the script:

scriptPubKey length: 51
Push the following 33 bytes onto the stack: 21
Compressed public key: 0241b8aba0994f320a8b438c627dbf31fbdd7dc722dd8418d829d67a9c6e4fd690
Push the following 33 bytes onto the stack: 21
Compressed public key: 036fbd9d0a34a569f10b0431c8aeecf74ad796b99838b7272ef35ded130a794f9b
OP_2: 52
OP_CHECKMULTISIG: ae

If you change DONATION_SCRIPT[2:35] to your own compressed public key, and DONATION_SCRIPT[36:69] to another compressed public key, that should work.


How does a Bitcoin client efficiently change forks?

The UXTO set certainly isn't reconstructed from scratch, that would be an incredible DoS vector if it did. Even on fast machines a complete reconstruction takes hours, days on slower disks and processors.

From a look at the source on github, we can see that your assumption is correct. The UXTO set is reconstructed backwards to the point where the chain is forked, and then continues on down it as normal.

The client seems to assume that large (100+) reorganisations of the blocks are improbable, which is why coins need to "mature" to avoid the situation where there's transactions spending coins that no longer exist in the chain.


Sending Bitcoins through Tor versus sending them through VPN

Well, if you are interested being as anonymous as possible, Tor is far more interesting. The VPN provider may not know who you are but it does know your IP address and the website you are visiting, which is almost the same if it comes in the hands of those you probably want to avoid knowing it.

With Tor on the other hand, node know each other's IP address. As you make a network request with Tor, it will pass through a number of nodes, usually 5 I thought. Of these 5 nodes, only the first one knows your IP address and only the last one can see the request you send. Supposing you use SSL as much as possible, the last node only knows the IP address your request is send to.

All intermediate nodes know nothing about you. So you are in fact the most vulnerable for the first node, because he knows your IP address. But he has no clue what website you are visiting, so no single computer in the Tor network will be able to see what you are doing.

Besides, sending a transaction with Tor does not have to be slow. That's just a small packet. You probably mean that syncing with the network and downloading all blocks is slow. Well, there is not much of a point for doing that via Tor. None of your addresses are sent along with block requests, so you can safely sync blocks over VPN or regular internet. The most information the outside world will get to know is that you are downloading Bitcoin data. But using a VPN that accepts Bitcoin, I doubt if they would be eager to share that information with others.


It's not about size, it's about fee. If you can have a high enough fee to make a massively sized transaction be incentived to miners, your good. See transaction priority for what I mean.


What happens when NameCoins stop being generated?

The Namecoin block reward is to be halved every 4 years, similar to Bitcoins. The fee to register a domain in Namecoin is set to decrease by the factor of 2 every two months, and later by a factor of 4.

As the price of registering a domain go down way faster than the block reward, there won't be a shortage of opportunities for registering domains. On the contrary, soon the price of a domain might be so cheap as to make them almost free. As Namecoins are destroyed though, eventually in the far future one might expect to run out of Namecoins, but with the price/reward ratio decreasing so fast, the project can become obsolete by then.

This seems to create a lack of balance of the Namecoin protocol that can be addressed in the future.


Are no orphaned blocks mined in the Bitcoin network?

probably the chart at https://blockchain.info/ja/charts/n-orphaned-blocks is broken. here you can see some new orphans blocks: https://blockchain.info/en/orphaned-blocks


Where to find old versions of bitcoin-qt from 2011-2012

You can find the first release of bitcoin on this old bitcointalk thread offered by Hal Finney himself https://bitcointalk.org/index.php?topic=68121.0
For the more recent version, circa 2009 you can dig the official github repo releases https://github.com/bitcoin/bitcoin/releases


How do I know that my Ledger HW Wallet is using receive addresses for my wallet and not another remote wallet?

Keep in mind that the ledger itself, if compromised could leak the pk in other ways. These methods I outlined will only confirm to you that a given address belongs to the set of private keys you hold, not that you're the only person holding these pks

like you said: one way you can cheaply verify that is to simply take the address and send a little bit of money to it. That does not answer if your key is compromised but it does tell you if the address belongs to your seed or not.

Another way would be to manually derivate the address from the private key using the BIP39 tool here until you reach the address that ledger gave you.

This second one doesn't require you to send any money but it is more risky as you need to trust the code in the page I sent you and you're literally inserting your pk in a form in the web, which is never a good idea.

The third thing you could do is generate Private Keys with a method you trust (i.e. using Samourai wallet or something) and then use that mnemonic in the ledger as a seed. This way you know that only you have that private key.


Programming for/modding bitcoin-qt on Windows

Qt is a multiplattform library, so is its IDE (qtcreator). You can compile bitcoin-qt on Windows pretty much the same that yo do on Linux.


Why hardended xpub key cannot generate child public key?

Non-hardened parents effectively use the public key to derive their children, where hardened parents derive their children from the private key.

The derivation of a child private key from a non-hardened parent private key k uses the following hash function:

HMAC-SHA512(chainCode, point(k) || i)

We know that K = point(k), where K is the parent public key. Thus, if we only know K and not necessarily k, we are still able to derive the child key by replacing point(k) with K, and follow the regular process.

With hardened private keys, the hashing is done differently:

HMAC-SHA512(chainCode, 0x00 || k || i)

Here you can see that there is no possible way that you could compute this hmac without knowing k. Just knowing the public key K will not help.

It looks as though you need to use the deriveHardened function in bitcoinjs rather than plain derive.


Why are broadcast checkpoints considered bad?

Centralized checkpoints is a mechanism whereby nodes trust a certain hardcoded key to make new checkpoints. This means that in case of a fork, the key owner can make the network choose any branch he wants, even the one which is shorter. If this key is compromised, an attacker can use it to mount an equivalent to 51% attack with any hash rate. This, together with that the developer should constantly do something (produce checkpoints) to keep the network secure, goes totally against the idea of decentralization. Without decentralization, a cryptocurrency has little advantage over traditional banking system.


Are there any Bitcoin miners that run from a web page and use the GPU?

The rather new WebCL technology enables this, unfortunately WebCL is not directly supported by browsers yet.

See http://www.coined.com/ and http://webcl.nokiaresearch.com/jsoclbm/ for examples of such miners. I expect more will follow in the coming months.


How are altcoins on crypto-exchanges based off BTC, ETH, and others

The "price" is usually based on the most recent trade in the specified exchange pair (e.g. LTC BTC). The most recent trade is simply two other participants on the exchange, the seller and the buyer. The seller (also called a "maker") offered to sell a particular coin at a particular price in a particular currency (e.g. to sell some amount of LTC for a specific price in BTC). The buyer (also called a "taker") offered to buy a particular coin at a particular price in a particular currency. The trade happens by the exchange when a buyer and seller's orders are matched.

Can you make money in these price differences between multiple currencies? It is possible, this is called an arbitrage. However, don't forget that the transfers usually take a bit of time and the arbitrage opportunity may have passed by the time you've made some trades, because rest assured others are looking for these arbitrage opportunities as well. Additionally, there are usually fees for each trade that eat into any earnings you might be making.

Also, this isn't that different from Forex Arbitrage trading in fiat currency markets so it is a well studied discipline and we can certainly learn from the practices established there.


Can a Bitcoin address be traceable to a crypto exchange?

Possibly in it's activity, exchanges have quite unique transaction footprints and this can be used to make an inference. It's not an easy process however and there is nothing in the bitcoin address itself that indicates which exchange etc. was used to create it.


What are the advantages of using Secp256k1?

I believe Satoshi was once asked this question, and answered that it was just some curve that existed and was presumed to be efficiently implemented.

I'll try to find a reference.


Proof of work: How are target, difficultly and number of leading zeros related to each other

The target is a number which the hash of a block header must be less than or equal to in order for that block to be considered valid. This target number, when represented as a 256 bit number, has several leading zeros. The actual number of leading zeros is irrelevant and doesn't matter to anything, but us humans talk about the number of leading zeros as a way to understand what mining is doing with the target. It is easier for people to understand that a hash must have some number of leading zeros which is specified by the target than it is for people to understand that the hash is a very large number, and the target is a very large number, and that the hash must be less than the target. Otherwise, the number of leading zeros is irrelevant. The number of leading zeros is based on the target.

The difficulty is also kind of irrelevant. It is just something for us humans to understand how much work is being done to mine blocks. The difficulty is an alternative representation of the target and is just the highest target value possible divided by the current target value.

Of these three things, only the target actually matters. That is what is used to determine if a hash is valid and that is what is changed every 2016 blocks. The number of leading zeros and the difficulty are just different representations of the target to make it easier for people to understand.


Cgminer not working with AMD APP SDK 2.8

Assuming you are using windows:

uninstall all AMD drivers

Do not install (uninstall) APP SDK.

download 3.11 beta version of catalyst drivers
http://www.guru3d.com/files_get/amd_catalyst_13_11_beta_9_2_(13_250_18_november_7)_download,1.html

Make sure you're cgminer settings are modeset and try again. If you are never on modest cgminer settings, you may never know if your software/driver config will work.


What does it mean to buy XRP as an individual OTHER THAN speculation?

You can also use it as a means of payment and as a means of exchange for other assets on the network.

  (If investing in XRP could mean something other than speculation) How can we "use" XRP to do something other than speculation as an individual?

You can pay it to other people to settle obligations. You can exchange it for other assets on the XRP Ledger. You can use it to fund transactions on the XRP Ledger to issue, redeem, transfer, or hold other assets.

  How is it possible that the Ripple protocol can operate even when there are many people buying XRP and therefore "holding" it, making it "unavailable" to the rest of the network. (I would imagine there are constant supply of XRP, which is enough to keep up with the "hoarded" XRP)

XRP that is held is effectively out of circulation. Taking XRP out of circulation increases the value of the XRP remaining in circulation by reducing the effective supply. This makes it possible to use the remaining XRP for higher-valued transactions because its value is higher.

But even more importantly, speculation creates demand and trade volume. Because there are speculators who buy and sell XRP for US dollars, there is a robust trade between XRP and US dollars. This helps to establish and stability XRP's value and to assure that there are easy ways into and out of XRP for people who use XRP as a vehicle currency.

On one day recently, speculators traded about $1 billion worth of XRP. This helps to provide a reliable and stable measure of XRP's value without which it could not be used as an intermediary asset.


Difficulty in obtaining vanity Bitcoin addresses

The probabilities are detailed here:

https://en.bitcoin.it/wiki/Vanitygen#Difficulty_of_finding_a_vanity

"The difficult of finding a vanity address depends on its exact structure (leading letters and numbers) and how likely such an output is given the algorithms involved, which can consist of several pivots where the difficulty suddenly changes."

Difficulty can be quite easy or quite hard depending on the structure and length of the vanity portion of your address


How to get private key from dogecoin wallet android app

You'd need to name the wallet specifically. https://play.google.com/store/apps/details?id=org.dogecoin.production.blabla doesn't exist.
Assuming you were using a fork of the schildbach wallet, the general procedure based on the most likely fork is:
https://github.com/langerhans/dogecoin-wallet-new/blob/1ee32cc/wallet/README.recover.md
Your trouble will arrive when you try to use bitcoinj to decode your protobuf.  You will want to find a fork that supports dogecoin.


Is the minimum amount of money required to purchase >50% hash power equal to max worth of all existing bitcoins?

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

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

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


http://wiki.mastercoin.org/index.php/FAQ#What_is_Mastercoin_and_why_is_it_needed.3F

Mastercoin is both a new type of currency (MSC) and a platform. It is a new protocol layer running on top of bitcoin like HTTP runs on top of TCP/IP. Its purpose is to build upon the core Bitcoin protocol and add new advanced features, with a focus on a straight-forward and easy to understand implementation which allows for analysis and its rapid development.

The primary features of the Mastercoin layer are different ways for user to create their own custom currencies straight from the client. The new user currencies include a variety of different usecase, including Smart Property, Pegged currencies (e.g. pegged to the value of the stable US Dollar or Gold), and Decentralized Applications where tokens include not just a financial aspect, but also decision making power.
For more info, please see mastercoin.org.

See also this presentation (video + slides).


How confirm my own doublespend transaction got confirmed

The answer is actually that you will receive a negative confirmation count in this case. (The bitcoin documentation is just terrible..)

See the bitcoin core release notes of 0.12.0 - section "Wallet: Negative confirmations and conflict detection"

https://bitcoin.org/en/release/v0.12.0

update note: In case of a negative confirmation (conflict detected) be sure to fetch all parent tx of that tx and see if that one got confirmed


How do you derive the lambda and beta values for endomorphism on the secp256k1 curve?

With a bit of reverse engineering, I think I was able to see how Hal was able to get to these results.

First, it's a pretty well known result of Fermat's little theorem that if p is a prime number and g is a generator for the field Z/pZ, then:

g ^ (p - 1) = 1

Note, don't confuse this abstract generator g with the generator for the secp256k1 group G. Now, given the above equation, it's not a big leap to see that:

(g ^ ((p - 1)/3)^3 = g ^ (p - 1) = 1

Thus, we can find λ and β by first finding generators for Z/NZ and Z/PZ (N and P being the parameters given in the original question), and then raising them to the (N-1)/3 and (P-1)/3 powers, respectively. You can check that both N-1 and P-1 are divisible by 3.

The generator that it seems Hal used for λ is 3, and for β is 2. I'm not sure why he picked those, there are plenty of other good generators to choose from. It was probably on a trial and error basis.

Using sage mathematics notebook, I was able to produce the same values for λ and β.


Why do nodes trust other nodes to approve their transactions?

I know that the blockchain technologie works so well, because
  everybody has basically a copy of the last ledger.

Yes, every full bitcoin node has a copy of the blockchain (aka ledger).

  Therefore, if a transaction happens, everybody inside the network has
  to "approve" the transaction to do it.

Correct, every transaction is propagated to all bitcoin nodes and it is validated by each one of them. Some of those nodes also do mining and they will include this transaction to a block. If they mine the block successfully (before any others mine their blocks successfully) they propagate their block to all the other bitcoin nodes which validate the block and all the transactions within. Thus, transactions are validated a second time.

  These other participants are then seen as trusted sources.

  However, what makes them to trusted sources. Let`s say there are only
  three participants, two make a transaction and one has to decide if
  the transaction is ok or not(does the clearing). What makes him a
  trusted source?

No one is considered a trusted source. Bitcoin enables trustless transactions. If we have 1000 bitcoin nodes in the network and user A makes a transaction that sends some coins to user B all 1000 bitcoin nodes will validate the transaction. Then, when the mined block is propagated all 1000 nodes will validate it again. Note, that users A and B may or may not run a full bitcoin node themselves.

Hopefully, that clarifies things a bit.


Checking whether lightning node is online/visible

For your node to appear in one of the explorers you have to have at least one open channel and once the channel is open you have to wait a little bit since the information that your node exist has to propagate through the gossip protocol. The gossip protocol requires an active channel to prevent spam and denial of service attacks.

To check if your node is online you can however peer to any node. (in clightning with the command lightning-cli connect) if that command is successful your node is online.


Developers, programmers new to bitcoin engineering ecosystem

Any sites, forums dedicated to developers new to bitcoin

https://bitcoin.stackexchange.com
And if you your question is closed here then, https://reddit.com/r/bitcoin
IRC: #bitcoin-core-pr-reviews IRC channel on freenode
Slack: https://bitcoincore.slack.com, https://lightningdevkit.slack.com, https://lightningcommunity.slack.com and https://suredbits.slack.com
Follow bitcoin devs on Twitter
Sometimes you find or discuss interesting things on different GitHub repositories as well like https://github.com/bitcoin/bitcoin

Any recommended git repo, site that shows how to interact with a node, do .i.e. p2sh,p2pkh on testnet.

https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line


Solving a Block with more than one miner connected to same daemon

Miners connect to a mining pool, which in turn connect to one or more bitcoin nodes. The miners get separate work from the pool and work in parallel.

Working in serial is not possible. There is no progress in mining. Your hash (lottery ticket) is either a winning ticket or not. Then you go on to the next hash. Mining is brute force. You go through billions of lottery tickets per second.

So two miners cannot find the winning ticket "together". They could both do the same work and find the same block, but that would be an awful waste. It is very important that the mining pool does not give out the same work twice. Two miners should never be checking the same lottery tickets (hashes).

Connecting miners directly to a bitcoin node is not possible. It used to work in the olden days when the ancient getwork protocol was used. bitcoind didn't have long polling in those days, though, so it really only worked in theory. These days miners speak stratum and bitcoin nodes speak getblocktemplate. The two protocols are not compatible, so there must be something in between, usually a mining pool.


What are the risks of direct Bitcoin fraud, such as counterfeitting?

There are a lot of scammers but counterfeit bitcoin cannot exist. Scammers can try to trick inexperienced users with watch-only wallets, or fake software etc, but they can't actually counterfeit coins.
Since the bitcoin ledger is public anyone can check to confirm if a bitcoin address has funds on it. In most cases you just need a single private key to spend the funds associated with a bitcoin address, so simply verifying that you have that private key and the address associated with that key has funds you can be sure those funds are really there.
Never accept a wallet file or a private key in exchange from someone trying to sell you bitcoin, instead simply provide them an address you already know you control and have them send funds to you over the bitcoin network.
The "splitting the blockchain" reference you mention is related to what is called forking. As bitcoin is open source anyone can create and run network similar to bitcoin with the same or possibly different rules than bitcoin. There are also instances where developers will take the bitcoin blockchain and copy it to start a new coin, but uses the existing balances of all bitcoin addresses (Unspent Outputs). This is a forked chain where users that had funds on bitcoin, now also have funds on some new chain but usually at a much lower value than the original. These forked chains, created out of nothing, usually suffer economically as opposed to the original bitcoin. Although it is a copy, it is not counterfeit it's just another blockchain network.


Bitcoin-cli createrawtransaction with 3 outputs example

You need to use (simplified notation) [{addr:amount},{addr:amount}] for the outputs, not [{addr:amount,addr:amount}]. This is to permit multiple outputs with the same address (which wouldn't be valid JSON in your assumed syntax).

A simpler alternative also exists, namely {addr:amount,addr:amount}.


Tons of red flags here.

I've been around for a while and have never heard of this client.
Browsing the site, all the pages dedicated to code or developer documentation are non-existent or lead to placeholders.
I reached out to Will Binns whose name is given as the maintainer of
the ostensible "Bitcoin client" Bitly Core on the "developer
documentation page" (which looks like it was scraped from
bitcoin.org). Will Binns tells me that he is unaffiliated with the
project.

The obvious explanation is that the software is either malware or part of a scam. I would recommend that you do not install it, do not let it interact with any wallet backups, and regard anyone who recommended its use with suspicion.


LoadBlockIndexDB: transaction index disabled

transaction index disabled is logged when the txindex=1 or -txindex flag is not set. If it was once indexed, and you don't pass that flag, then bitcoind will prevent you from accidentally rebuilding the database without the indexes unless you explicitly tell it to with -reindex. Check your bitcoin.conf file and the startup script. Alternatively, try adding -txindex to /etc/systemd/system/bitcoind.service where bitcoind is called:

ExecStart=/usr/local/bin/bitcoind -txindex -daemon -conf=/home/bitcoin/.bitcoin/bitcoin.conf -pid=/home/bitcoin/.bitcoin/bitcoind.pid


why block minning not interrupted when block found?

A realistic bitcoin miner finishes a work unit in less than a second and blocks are only found every ten minutes. So interrupting a work unit would increase mining efficiency by something like 0.1% at best. The additional hardware required to support such interruption on a realistic mining platform would not justify the small performance improvement you might get.

However, it is still beneficial to switch to a new work unit as quickly as possible when a new block is found. But in modern mining systems, this is implemented at a higher level, typically somewhere between the miner's end of the connection to the mining pool and the mining hardware itself.

You can think of it as the software controlling the actual mining hardware having a "big" work unit and, from it, doling out "smaller" work units to individual mining hardware units. When a new block is found, the software gets a new "big" work unit from the mining pool and when the mining hardware needs a new smaller work unit, it gets one from the new big work unit. It's counterproductive, because the small work units are already so small (typically only a few billion hash operations) to try to interrupt them.


Why would I choose to use Bitcoin and not other crypto currencies like Ethereum or Dash? Why is Bitcoin better or worse than the rest?

I find this article convincing in its analysis of the dynamics between Bitcoin and competing networks: The Coming Demise of the Altcoins

To summarize briefly, the author suggests:

The utility provided by a currency system is related to the willingness of its users to save using that currency.
Currencies have a strong network effect.
Most altcoins don't have a significant technological advantage over Bitcoin.
Therefore, altcoins are destined to lose value in comparison to Bitcoin in the long run.

I do recommend reading the article, though.


How can I run bitcoin-cli with disabled syncing?

You could use the invalidateblock RPC. Bitcoin will not bother checking validity of blocks past that an invalid block.


Lightning network: which update messages are replayed?

You should look at BOLT 07 which describes the gossip protocol and depends on BOLT 08 (Transport via the Noise Protocol framework) and BOLT 01 (Messaging)

In particular if you look at the channel_update message you will find this quote from the BOLT 07:

  if timestamp is NOT greater than that of the last-received channel_update for this short_channel_id AND for node_id:
  SHOULD ignore the message.

  otherwise:
  if the timestamp is equal to the last-received channel_update AND the fields (other than signature) differ:
  MAY blacklist this node_id.
  MAY forget all channels associated with it.

  if the timestamp is unreasonably far in the future:
  MAY discard the channel_updat

Also in the section about rebroadcasting you can find the following quotes:

  upon receiving a new channel_announcement or a channel_update or node_announcement with an updated timestamp:
  SHOULD update its local view of the network's topology accordingly.

  after applying the changes from the announcement:

  [...]

  SHOULD update the appropriate metadata AND store the signature associated with the announcement.
  Note: this will later allow the node to rebuild the announcement for its peers.

The way how I read this is that nodes only store the latest channel_update message per channel which they can detect via the timestamp. Also when the initial sync takes place the latest update messages for each channel are also being sent.


What are the DER signature and SEC format

DER

The Distinguished Encoding Rules (DER) format is used to encode ECDSA signatures in Bitcoin. An ECDSA signature is generated using a private key and a hash of the signed message. It consists of two 32-byte numbers (r,s). As described by Pieter here the DER signature format has the following components:

0x30 byte: header byte to indicate compound structure
one byte to encode the length of the following data
0x02: header byte indicating an integer
one byte to encode the length of the following r value
the r value as a big-endian integer
0x02: header byte indicating an integer
one byte to encode the length of the following s value
the s value as a big-endian integer

Note that the r and s value must be prepended with 0x00 if their first byte is greater than 0x7F. This causes variable signature lengths in the case that the r value is in the upper half of the range (referred to as "high r"). Signatures with high s values are non-standard and usually don't appear in the wild.
Also note that in rare cases r or s can be shorter than 32 bytes which is legal and leads to shorter signatures.
Note that in bitcoin transactions a byte is added at the end of a DER signature denoting the SigHash type used.

SEC

The Standards of Efficient Cryptography (SEC) encoding is used to serialize ECDSA public keys. Public keys in Bitcoin are ECDSA points consisting of two coordinates (x,y). x and y may be smaller than 32 bytes in which case they must be padded with zeros to 32 bytes (H/T Coding Enthusiast). Bitcoin uses two formats, uncompressed and compressed:

Uncompressed:

0x04 byte: header byte to indicate ECDSA point
the x coordinate as a 32-byte big-endian integer
the y coordinate as a 32-byte big-endian integer

Compressed:

As the coordinates (x,y) must satisfy the secp256k1 curve equation y² = x³ + 7, the two possible values for y can be calculated from the x value. Thus, we can express a public key just as the x coordinate in combination with an indicator which of the two y values to use.

0x02/0x03 byte: header byte to indicate compressed ECDSA point, 0x02 for even y, 0x03 for odd y
the x coordinate as a 32-byte big-endian integer

The above is more comprehensively explained e.g. in Jimmy Song's Programming Bitcoin: Ch4. Serialization.


Why did bitcoin programmers release mining code?

Bitcoin is a decentralized digital currency.  It is meant to be resistant to corruption and external control.  That is the reason it was created.

Bitcoin achieves this only through the approach where consensus of the ledger is achieved by performing work.

Bitcoin is vulnerable -- this consensus mechanism can be blocked by anyone with 51% of the mining network capacity.   To prevent anyone from having that ability to block, the mining network needs to be large enough so that there it is vastly economically unfeasible for an attacker to disrupt the network.

So to achieve this requirement of being protected with a ginormous amount of hashing capacity, the mining process is subsidized.  This subsidy comes from the issuance of new currency. This subsidy helps to bootstrap the currency by putting it into many hands who might be willing to spend the funds for goods and services which draws merchants and service providers into the bitcoin economy.

So the combined goals of bootstrapping the bitcoin economy and ensuring that mining capacity is more than sufficient to dissuade any 51% attack are two reasons to release mining code and letting mining revenues be distributed to those willing to participate.

Because bitcoins aren't always circulating, there must be some willing to hold bitcoins as a store of value at all times.  Again, Bitcoin has value only because it is a decentralized digital currency that is resistant to external control.  If it doesn't have that then it is simply an online ledger -- no different than what PayPal provides, or what your online banking system provides.  There are plenty of other open source ledger software options for this.

Only from the protocol being open (and trusted as being open by having the software being open as well) would an investor that is willing to hold bitcoins be assured that the currency truly is decentralized.

For Bitcoin to be valued, the source code had to be released.   If the source code were never released, Bitcoin would never have achieved any value.


How to prove to my landlord that bitcoin came from my wallet?

One way might be to have the landlord generate a different address for each tenant. So you pay your landlord using address A, and your neighbour pays using address B, and the landlord can tell who the payment came from by the destination address.

That doesn't prove that the payment came from your wallet of course, but this allows somebody else to make the rent payment on your behalf (and the landlord wouldn't know the difference).


How do I transfer my wallet to a new one?

Instead of transferring the wallet, just transfer the bitcoins - i.e. on Android: Send the entire amount to your electrum-address.


How exactly does a block get constructed and verified?

So when Alice sends Bob 10 BTC, how does this information get put onto the newest block? I guess I am wondering who collects all the transactions and then constructs the new block? Does the client facilitate this and how do we know it contains trustworthy data?

That's what the Bitcoin software does. It relays transactions from anyone who generates them to the miners so they can include them in blocks. You know the data is trustworthy because you always check it completely. Bitcoin operates based entirely on mathematical rules and the data either follows the rules or it does not.

  And when the block is discovered by a mining node, I understand that it tries to find a nonce which hashes to leading zeros as part of proof of work. I read that miners help 'verify' transactions. How does finding a nonce verify what is in the block? Or does the verifying refer to other nodes checking that "block + nonce" hashes to correct number of leading zeros?

All the computational effort that a miner does on a block cannot be separated from that block or the nonce would no longer produce the leading zeroes. One of Bitcoin's rules is that among valid blocks, the one with the most computational effort wins. By heaping absurd amounts of computation on top of blocks, the mining process ensures that someone else cannot create their own valid block that "wins" over a block that contains a transaction you have considered accepted.


What can be done about the no-transaction block relayer (currently 71.123.170.150)?

There are too many issues rolled up into this question, I'll try to address each separately.

The fact that the miner does not include transactions is not a problem. Miners have a right to exclude transactions, even all transactions. Senders can include tx fees if they want to improve the chances of being included quickly (if the miner excludes transactions due to its nature of operation an individual fee won't help much, but if the general fee level increases, 0-tx miners will be much less profitable and thus less influential).
The fact that there is a mining botnet is a problem insomuch as we don't want Bitcoin to be an enabler of harmful activities, but it does not harm Bitcoin itself. It is likely that new FPGA- and ASIC-based mining products will make CPU-based botnets less effective.
Orphaned blocks are a normal occurrence in the functioning of the network, and an occasional orphan by this particular miner is of no concern.
If the miner starts rejecting longer branches (as in a 51% attack) it is a problem, but it is a heavily discussed core problem which is not specific to botnets and is not yet resolved. I am of the opinion that a proof-of-stake system can drastically mitigate the problem (and will probably make botnets less effective miners).
If we want as a matter of principle to discourage blocks that have little or no transactions, we can include some measure of transaction volume in the branch selection criterion. One such measure is Bitcoin days destroyed. It is resistant to manipulation by sending the same coins to oneself again and again, because such coins will only destroy few days each time.


What are these strange outputs in the Litecoin blockchain?

Those are from an early version of P2Pool, which mistakenly sent outputs to the literal string "script" rather than the variable script. This was naturally fixed, but left lying around are a number of these outputs.


If you mean the generate function, which creates blocks on demand, it is only available for the Regtest mode. Use the -regtest option to run in Regtest mode.

If you mean the setgenerate mining function, it has been disable since the 0.13 version of Bitcoin Core, due to the fact that mining difficulty became too high for doing it with CPUs.

If you want to restore that functionality you will need to restore the mining functionality code from a previous version and try to integrate it again in the source code (you will need to recompile it).

debug.log is the reference log file. You can refine the log output through the command line options. See https://en.bitcoin.it/wiki/Running_Bitcoin