Practical way to split a bip39 seed into a 2 out of 3 factor auth?

I see Shamir Secret Sharing recommended; yet One Time Pad or XOR is an elegant way to split a BIP39 seed. It's a method simple to describe (apt for a will), easy to verify (trust only yourself) and like SSS is information-theoretic secure [1]. It can be computed entirely with paper and pencil eliminating risks from malware and best of all the resulting shares are themselves mnemonics thus convenient to record (cryptosteel). The method does not scale efficiently for "n of m" when m is large, but works well for "n of n", "2 of 3" and "3 of 5".

Consider an example of a three word mnemonic from the 2048 word BIP-0039 dictionary:

S = "night love grit"

We will split the seed S into two parts, A and B, such that A + B = S (where + is element wise addition mod 2048). First generate a random key A of the same length, say A = "steel siren layer". To find the second key B, go word by word subtracting the dictionary indexes mod 2048 of A from S:

1st: (night - steel) mod 2048 = (1197 - 1706) mod 2048 = 1539 = scare

2nd: (love - siren) mod 2048 = (1060 - 1612) mod 2048 = 1496 = road

3rd: (grit - layer) mod 2048 = (822 - 1011) mod 2048 = 1859 = tribe

Thus B = S - A = "scare road tribe". To retrieve S add the two keys together:

1st: (steel + scare) mod 2048 = (1539 + 1706) mod 2048 = 1197 = night

2nd: (siren + road) mod 2048 = (1496 + 1612) mod 2048 = 1060 = love

3rd: (layer + tribe) mod 2048 = (1859 + 1011) mod 2048 = 822 = grit

Thus as promised, S = A + B. Even with infinite computing power A and B reveal zero information about S. Individually they are nothing but random numbers. "3 of 3" can be achieved by generating two random keys, say A and B. Then the third key C is found as:

C = S - A - B; giving S = A + B + C. This can be extended to "n of n".

For "2 of 3" repeat the method three times. Each time use a different random key A; say A1, A2 and A3. This generates three keys B1, B2 and B3. So now we have:

A1 + B1 = S

A2 + B2 = S

A3 + B3 = S

Divide the keys like this:

Switzerland: A1, A2

Canada: A3, B1

New Zealand: B2, B3

Vires in Numeris!


bitcoind: How to generate new address and broadcast?

You don't have any bitcoins, so you can't create, sign, and broadcast a transaction.

As for generating a new address, use the getnewaddress RPC.  It will give you an address you can give someone else to send you bitcoins.  Once you have bitcoins, you can create and broadcast a transaction in one step using either the sendtoaddress RPC or the sendmany RPC.

Use help getnewaddress, help sendtoaddress, and help sendmany to learn more about each RPC.


How to setup USB Cold Storage for Bitcoin and Monero?

Yes, it is possible.

The difference between a HDD and a USB stick is HDD is attached to your computer most of the time exposed to internet, USB sticks on the otherhand can be taken out and can be kept in a vault. Therefore you can store multiple cryptocurrencies in a USB stick.


With the rise and fall in value of bitcoins, how do I store them once I've accummulated enough

There are a couple of different aspects to your question.

How to avoid accidentally losing coins?

You need to have reliable and secure backups of your wallet's private keys.  Depending on the wallet you use, this could be a file (e.g. wallet.dat), a mnemonic phrase, or some other sort of information.  Make sure you know what you are storing and how to use it to recover your wallet.  In particular, just storing addresses is not enough.  If possible, practice your backup and restore procedure, even if you have to make some unnecessary transactions (and pay fees).

Keep the backups somewhere safe, perhaps in multiple copies, so that no single foreseeable disaster can destroy all of them.  Also, the backups must not be accessible by anyone untrusted, or that person could steal your coins (see below).  You could encrypt the backups, but then you need to figure out how you will make sure to remember the encryption key or passphrase.

You can store your coins with some exchange or online provider (Coinbase, etc), but this carries risks: they might go bankrupt or lose your coins due to mistakes, fraud, theft, or accident.

How to avoid having coins stolen?

We have another question about this: How can I keep my wallet secure?

You have to make sure that nobody else ever gets access to your private keys.  If you store them on the computer, phone, or other device that you typically use to work with Bitcoin, be sure to account for the possibility that the device may get lost or stolen or hacked.  Use whatever encryption or other protection mechanisms are provided by your wallet software or operating system.  Use good security practices in general; avoid installing unknown software or visiting unknown websites, and keep up with security updates.

You can also store some of your coins offline, in a paper wallet or offline USB stick.  You'll need to make sure this is stored in a safe and secure place, where nobody else can get to it, and be sure to have backups in case it is accidentally destroyed.

How to avoid having coins lose value?

You can't.  The price of Bitcoin will continue to fluctuate.  The only way to "lock in" your gains is to sell some or all your coins (or perform some sort of exotic hedge which amounts to much the same thing).   This does mean that you won't benefit (as much) if the value goes up later; you can't have it both ways.


The hashes are computed on the raw byte value of the key, not the hex-encoded string:

from hashlib import sha256
key = '0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6'
sha256(key).hexdigest()
# Output: '32511e82d56dcea68eb774094e25bab0f8bdd9bc1eca1ceeda38c7a43aceddce'
sha256(key.decode('hex')).hexdigest()
# Output: '600ffe422b4e00731a59557a5cca46cc183944191006324a447bdb2d98d4b408'

So the trick is to hex-decode the string into its original form before hashing it.


How to install specific version of bitcoind

Source code for Bitcoin Core, v0.12.1 can be downloaded directly from GitHub, via https://github.com/bitcoin/bitcoin/releases/tag/v0.12.1

Binaries are available at:  https://bitcoin.org/bin/bitcoin-core-0.12.1/

Be aware, v0.12 has known vulnerabilities, and should not be used in new work.  https://bitcoin.org/en/release/v0.13.0 shows some of the vulnerabilities that were fixed in v0.13.


Does the GUI of the daemon show that you are connected to inbound peers?

If it does, you may have to do a re-sync of the blockchain from scratch. It's happened to me before.

Not sure which crypto you're using, but I'd try backing up your wallet.dat files, you can save a copy of the blockchain database as well if it's huge and restore it later just in case.

But back up your wallet files, then do a fresh install, re-sync the blockchain, and see if it gets to sync status. Then open your wallet files.


The bitcoin block chain is the record of every bitcoin ever generated and every transfer of bitcoins from one party to another. Each crypto-currency that is based on the same type of technology as bitcoins has its own block chain. When people talk about other blockchains, they mean other currencies based on the same distributed currency / published transaction model (namecoin, Ixcoin, and so on).

The phrase "blockchain technology" is a reference to this model of published transactions to implement currencies with no central authority.


Short answer: no. Imagine this scenario: a developer writes a closed-source Android wallet that becomes extremely popular. At some point the combined worth of the user wallets is $100M. The developer could have purposely left an open vulnerability, and claimed that a hacker exploited it. There would be no way to know if he was telling the truth.

Rule of thumb: keep the bulk of your BTC in cold storage. Online wallets should be treated like the wallet in your pocket. How much cash are you comfortable carrying around, knowing that you could lose your wallet and it's gone? That's how much you should have in an online wallet.


Blockchain.info transaction unconfirmed for several days

This is normal. Your paper wallet consisted of lots of small transactions inbound, and now you are sweeping them to a new address. A wallet is a collection of unspent outputs.

The transaction looks fine, and the txfee is standard. Given that the network is under a spam attack of sorts right now, its possible that the fee is simply not high enough to confirm. It may take a while under the current circumstances until it does.


Is the appreciation in bitcoins taxable?

My guess is that as long as you have a receipt for the buy, and one for the sell then there is no reason why the government would say no to taking their share if it. I guess it's just classed as currency trading??


How does blockchain.info get miner revenue?

This number means something else then you expect. It is the value of the reward for the miners, so exactly the revenue.

I will show you how this number is calculated:

There are (currently, may differ in the future) 144 blocks mined. That means that there are 144*25 = 3600 bitcoins awarded to miners. The value of 1 bitcoin is  $465.07 USD according to the statistic page. The 3600 bitcoins have a total value of $1,674,252 USD. Add a little of the transaction fees (13.41473297 BTC, which is 0.37% according to the statistics page) and this will results in the 1.68 million USD revenue.

Blockchain can simply calculate all these things from the different blocks, because everything is also on the site.


How do I pay for something anonymously from the UK using bitcoins?

Buying coins non-anonymously in the UK:
Transferwise to Bitstamp's European account - £1 transfer fee, then <0.5% commission to buy.

Spending:
I guess you would use a mixer service


When would I change my Ripple client's Web Socket IP and Blob vault URL?

The blob vault URL lets you choose who you trust to hold your wallet. While the wallet is encrypted, the organization that holds your wallet could attempt to brute force your password with the only limits being their computational resources.

The selection of web socket IP and port allows you to choose what Ripple server you want to connect to. The plan is to eventually let you have multiple servers saved in your wallet.

These choices have to do with how your client connects to the Ripple network and finds out your account information and annotations. It is not related to a choice of gateways, what IOUs you wish to hold, and so on.


Improve uniqueness of block for nonce creation

Blocks include more than just those 3 variables. One of the most important ones is the merkle root. This is the hash of all of the transactions in the block, in a particular order. If different transactions are included or they are included in a different order, that merkle root is going to be different. So if each miner has a different merkle root, then they are going to have their own set of nonces to work with. That is what actually provides uniqueness here.

Miners all have different merkle roots. This is because the merkle root includes the transaction that pays the mining reward - the coinbase transaction. Since every miner wants that reward, they will have a coinbase transaction which is different from every miner as it will include their payout address, not someone else's. So by virtue of having different payout addresses in their coinbase transactions, the blocks that miners are working on will be unique and different from other miners.


Bitcoin config file to setup bitcoin node in testnet network in ubuntu

In general, you can use Lopp's Bitcoin Core config file generator to set up your Bitcoin Core config files. Parameters are collected in groups by topic (e.g: Mining, Networking, ...). Moreover, each parameter contains a description of what it is used for and what is it's default value.


Do not use your seed! It will compromise your whole wallet.
Export your current account's private key in settings->export on an account.
Before using this private key anywhere. Add a new account and send your Bitcoin to this new account in Mycelium. Now you can use the exported private key to claim your Bitcoin gold.
However where you can do this is still unknown to me. Apparently Bitcoin Gold will provide guides for all wallets including Mycelium.


BitCoin Core Error Message: "Assertion failed!"

It is possible that you are running out of RAM or HDD space.  Check this github report from a user with a similar issue.  If this is not the case then I would run a memtest and see if you don't have an issue with your RAM.


Delete Bitcoin Qt Mac: System folder inflated in size, although "Application Support/Bitcoin/" and app deleted

If you had enabled pruning, then a 7 GB Bitcoin folder makes sense.

Otherwise, you probably chose a different data directory in which case you will need to remember where it is. Try searching your computer for a file named debug.log or blk00001.dat.


What was the first official BTC miner software?

The first official mining software was Bitcoin Core (then known simply as Bitcoin, later bitcoin-qt), and it still serves as a reference mining implementation, making it the "official" miner. See its miner.cpp file, for example.

Bitcoin Core uses your CPU to mine. Mining eventually moved to GPUs and ASICs, so that mining on a CPU is practically pointless right now. In that sense, you should never use Bitcoin Core as mining software. But it still is mining software.


Are the addresses in my Wallet client considered to be all as only 1 account or wallet?

In the Bitcoin protocol and network there is no concept of "wallet" or "account". It only recognizes addresses. Whoever has the key corresponding to an address can spend the coins in it.

A wallet is merely a collection of addresses with their corresponding keys. The Bitcoin-qt client manages for you a wallet file on your computer. Every address in this wallet is spendable by you, so the software displays the total amount in all addresses as your balance. You don't really need to know how many coins are in each address, you just want to know how much you have in total.

I wouldn't say that the addresses "point" to a wallet as that would imply the wallet is a thing on its own. Note that you can have the same address in several wallets, but that's not recommended.

Some other software, such as Multibit, allow you to easily manage several wallet files, and see the total balance for each.


What are the top sites to purchase bitcoin from?

I recommend CoinBase.
Coinbase is a Bitcoin company based in San Francisco, and backed by trusted investors. Coinbase is the world’s largest Bitcoin broker, and also offers an exchange, wallet, and developer API.

Coinbase offers its brokerage services in the United States, United Kingdom, Canada, Singapore, and the following European countries: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Finland, France, Greece, Hungary, Ireland, Italy, Latvia, Liechtenstein, Malta, Monaco, Netherlands, Norway, Poland, Portugal, Romania, San Marino, Slovakia, Slovenia, Spain, Sweden, Switzerland.

Coinbase plans to enter the Latin American market in 2016.

Coinbase has a knowledge base and email support. Coinbase “Community” can be used to ask questions and get support help.


How is the previous transaction hash calculated?

You do not need to calculate previous transaction hash, because it is already known.
To spend the previous output you just have to know

tx hash
output index in this tx
output value
output script

plus you should choose

fee
new address

then create some byte data and sign it with appropriate private key

Good manual you can find here: How to redeem a basic Tx?


Run lightning-charge on c-lightning regtest

the problem is in your call of charged there you are passing the argument --ln-path ~/.lightning assuming that you run lightning in your home directory thus you have to set ln-path to /tmp/l1-regtest/.

Now you say that this also did not work. So before I give you a solution let me explain what is actually going on. charged talkes to lightningd via an rpc-interface on an UNIX Domain socket. In older versions of lightningd there was a file called lightning-rpc in the folder that you specified as lightning-dir however lightningd has switched its API recently to to have subdirectories in lightning-dir for mainnet, testnet and regtest. (the reason was that in particular in the default directory people wanted to have different configs for mainnet, testnet and regtest)

Thus I assume that you will find lightning-rpc when you do ls /tmp/l1-regtest/regtest which means that you should pass the tmp/l1-regtest/regtest in --ln-path when you call charged. If that is not the case I would have to see another error message.


bitcoin script for a competitive crowdfunding-like contract

It can't be done with today's infrastructure. We can imagine two solutions.

First solution: Bitcoin upgrades

Script gets progressively more powerful with new opcodes. In this case I think there would actually have to be a new UTXO set index (which nodes don't currently even calculate) so the script could find all the payments to a particular address/with a particular marker and reflect upon them. You could then have people put money into outputs with scripts that say in pseudo-code:

If it's past a certain time
Do the UTXO lookup to find all outputs tagged as being for party A
Do the same lookup for party B
Parse and sum them to figure out which one won. The existing instruction set might or might not be quite good enough for this, but re-enabling the opcodes that were panic disabled a long time ago doesn't seem impossible: just needs good unit tests.
Then using the result of that calculation, require a signature originated by the winning address

So the script architecture could do this, with an extension and a few of the disabled opcodes being re-enabled. But the real question is - should it?

The primary downside of allowing this sort of thing is that calculating the needed database indexes is computationally intensive and will slow nodes down, thus making them more expensive to run and hurting Bitcoin scaling.

The upside is that this construction would be audited and verified by every network participant, which is the best security you can have in Bitcoin.

For this particular use case, I'd probably feel the costs outweighed the benefits. The construction is IMO rather odd and uncompelling. It's possible though, that someone comes up with a use case for an OP_LOOKUP_OUTPUTS that actually is compelling, and we have been talking forever about making nodes calculate more indexes over the UTXO set. If we end up doing that for other reasons anyway, at that point exposing it via Script doesn't seem like such a big leap and making this construct as a "pure" smart contract would become possible (easy, even).

Second solution: oracle network

Since Bitcoin began there has been a debate about the balance between simplicity and power in scripting contracts. Bitcoin has a fairly restrictive scripting language, partly because in the early days it was found to be insufficiently well tested and open to security exploits, and reducing unused power was a quick way to stabilise the core.

Ethereum is the exact opposite, it gives scripts enormous power and access to lots of expensive capabilities, like data storage slots. How secure it is, how resistant to DoS attacks and so on is currently an unresolved question, but we know from bitter experience with Bitcoin, Java, Flash, HTML/JS etc that sandboxing mobile code is extremely hard. They're gonna have their work cut out for them. All mobile code sandboxes I know about have been found to have holes in them at some point, so nobody has ever managed to do what Ethereum wants to do without recurring exploits. This is why the Bitcoin community is so conservative with increasing Script's power.

It would be ideal if we could somehow create two scripting systems, one simple/trivial one that manages the movement of money in the core network and a more powerful one in which security breaches only impact the people using those features instead of everyone.

There's a couple of ways we can do this in Bitcoin.

One is to have an independent p2p network of oracles:

https://en.bitcoin.it/wiki/Contracts#Trust_minimization:_multiple_independent_oracles

In this case each oracle has an identity and people pay to a threshold signature of pre-selected oracles. Each oracle runs the program independently and then signs with their private key if the program succeeds.

The problem here is that you don't have much agility. Oracles can't come and go in the same way miners do.

Another is to use a side chain, when such technology becomes available. In this case the side chain does not contain any coins and two-way pegging is not necessary. Rather the side chain "transactions" just assert that a program was run and was satisfied. Oracles then "mine" the side chain thus proving that a hashpower majority ran the script and got the expected output.

A final way is to use SNARKs, when such technology becomes available.

The appeal of sandboxing things this way is that if, for example, a sandbox escape exploit is found in the dominant oracle implementation, it would result in oracle-locked outputs becoming stealable but not any other Bitcoin outputs, so the risk is contained.

The Ethereum design in contrast binds things together more tightly. An exploit in the Ethereum contracts engine could result in the entire system breaking.


How accounts, wallets and addresses are related

When you mine a block and get the block reward (50 LTC in your case), the coins are not spendable immediately. There is a maturity period of 100 blocks before you can spend them. I believe this is why they don't show up.


How to produce a Hash160 bitcoin address?

The address is already a hash, together with a 4-byte checksum and a version byte.  To get from an address to a hash160, you don't have to compute sha256 or ripemd160 of anything.  You just have to decode it from base58 back to hex, and discard the unwanted junk.

If you take mvm74FACaagz94rjWbNmW2EmhJdmEGcxpa and base58 decode, you get

 6FA73706385FFFBF18855F2AEE2A6168F29DBB597EF59C240B
 VVxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxSSSSSSSS

The first byte (6F) is the version byte; discard it.  The last 4 bytes are the checksum; discard it.  The remaining 20 bytes are the hash160 of the public key corresponding to the address.


A different way to create coinbase transaction

Sure, the protocol could have been designed that way.

The benefit would be that a block would be slightly smaller, since it only needs to contain a single address, rather than a full coinbase transaction.

However, a benefit of the current system is that miners have the flexibility to pay out their coinbase transaction in some other way than sending it all to a single address.  For example, a pool can distribute the coinbase transaction directly to its members in proportion to the amount of work they have done.  This removes the need for the pool manager to hold those funds, even temporarily, and gives the members some additional assurance against fraud by the manager.  It also lets miners take advantage of more sophisticated transaction types, such as multisig, segwit, etc.

The current system also means that coinbase transactions are handled the same as other transactions, using the same code; the only difference is that the inputs need not be checked.  Under your proposal, there would need to be special code to create the transaction, which would be another possible source of bugs and increase the "attack surface".

On balance, I think the current way is better.


Does a blockchain become opaque if it enable's schnorr-signatures, and require trust in the code?

When you sign a transaction with schnorr-signatures, it does not include the pubkey in the transaction data.

What? Schnorr signature validation still need public keys.

  1)Does this mean the input addresses become unknown, aka creating a opaque blockchain ?

No, there are still addresses just like before (or more technically: every input still explicitly refers to a single identifiable previous output which is being spent in its entirety)

  2) How can one make sure that for example bitcoin still only has 21 million bitcoins ?

By summing up the value of all UTXOs.

  3) How does the UTXO set updated and than later on verified by others, seeing only the output address is know.

Nothing is changed. The UTXO set still contains entries, each of which has a txid, amount, and scriptPubKey. Now you just need a Schnorr signature to spend them.


How do cryptocurrency exchanges handle users' accounts?

When you send funds to an exchange, you do not own the UTXOs created. They are owned by the exchange.

Exchanges use the UTXOs from all their wallets to process withdrawals. This means that if you were to deposit and withdraw coins with no trades in between, your withdrawal will still not come from the UTXO created by your deposit. It could come from any of the thousands of UTXOs owned by the exchange (comprising of other peoples' deposits).

It's similar to how your bank account functions. When you deposit cash, the cash you hand over becomes the property of the bank. From that point, any balance that you have solely exists on the banks' internal databases. If that database was tampered with or destroyed, no one can prove you had money there. If you were to withdraw cash, the notes you get back will not be the same ones you deposited, and were likely deposited by some other customer.

Similarly, when you send coins to an exchange, your balance exists solely in the exchange's  internal database system. As you make trades, this internal balance is debited and credited. When you withdraw, the coins come from a UTXO set that includes everyone's deposits.

This is also why it is recommended to only keep coins you are actively trading on an exchange, since it leaves you open to the possibility of an exchange losing your money.


How to do refunds and internal transfers on bitcoind?

Unfortunately, there's no distinction between "external" and "internal" transfers in bitcoin. If you want coins to be in another address, you have to pay the transaction fee. That said, you can create a single transaction that does everything you want and only pay the fee once (though, obviously, that transaction will be relatively big, you should still save some fees because you'll not have as much overhead in terms of tx size)


How do light clients using compact block filters get relevant unconfirmed transactions?

There's no design consideration in Neutrino / BIP157 for unconfirmed transactions, but it's not as much of a concession with context. A light wallet can effectively do nothing with information about an unconfirmed transaction as they can not verify anything about its validity to begin with. At best it is a suggestion that a transaction may have occurred, but this is even weaker than a normal unconfirmed transaction sent to a fully validating wallet.
It has always been an issue with "SPV" wallets that they can be duped into showing completely absurd false data, for BIP37 especially it was completely possible to sniff the incoming filter and dynamically produce transactions paying to the addresses that likely matched it billions of dollars. The client, as dumb as it is, can only show them to the user and hope that common sense on the part of the user prevails.


European online stores selling electronics

Through websearch I have found e4btc.com. They seem to be based in Berlin.

I do not have any further experience or information about their offers, nor am I affiliated to them in any way.


How much bandwidth needed for bitcoin bigger blocks

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

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


importmulti with BIP84 derivation always fails

The issue is that your hardened paths use the single quote notation which breaks the single quoting that surrounds the entire import command. You will need to escape those properly, and \' is not the way to do that. Instead, for every single quote within your import command, you need to do '"'"' - an explanation for why can be found here.

Alternatively, you can change those single quotes to h, but once you do so, you will need to recompute the descriptor checksum. But iff you give such a descriptor to getdescriptorinfo it will give you back the descriptor with single quotes (there is a pull request open to fix this) so you will need to use an external checksum tool to do this. I have a python script which can do this.

Running your descriptor with h instead of ' through that script, I get:

wpkh([18734cbe/84h/0h/0h]xpub6AC5B4KkrtMkXmzUWAiVVYWvhzwMJDX46ZJhm2tusm7SPc2KjeSqwEjLTaB8vAo7ev3zUFbGdWcX3EMy1ZQ9JxDgpc1pzBGLVpftq84naq5/0/*)#rxk7wl9c


If you have turned off -txindex (which should have happened when you enabled pruning), then you can just delete the the indexes/txindex folder as it isn't being used.


You can trace the coin back to its origin, the question is whether that information is meaningful.

Say I steal 50 bitcoin. I can pass them around between several different Bitcoin accounts, all mine, and you can trace them. The problem is, you don't know whether any of those transactions are real.

Say Jack has 50 bitcoins that come from a block reward and are untainted. Now, say Jack and I both deposit our 50 bitcoins in a web-based wallet. And say Jack withdraws his 50 bitcoins from that web-based wallet and he gets my 50 bitcoins.

Jack now has 50 bitcoins that you can trace to a theft and are therefore tainted. But Jack has done nothing wrong and it doesn't do any good to be able to track his bitcoins because I, the bad guy, now have untainted bitcoins.


Does it take longer to generate an address when I stop and restart vanitygen?

tl;dr If you stop vanitygen for 5 minutes, on average you've added 5 minutes to the time it will take to complete.

While it is running, vanitygen tells you how much longer it will take until you have a 50% chance of finding a suitable address.  About half the time, that countdown will reach zero, and then the countdown starts again, but this time showing the time until you have a 75% chance.  And so on.

This gives the impression that it is making "progress" towards finding a suitable address, but that is misleading.  Every second that vanitygen is running is has a certain chance of finding an address.  There's no progress being made, in the same way that you don't "make progress" towards winning the lottery if you play it every week.  Just eventually if you play enough times, you win.

So if you stop the program running and start it again, you've lost nothing other than that you've wasted the time between stopping and restarting when it could have found a solution.


Are you talking about the CCriticalSection class?  As you can see in sync.h, it's just a wrapper around Boost's recursive_mutex class.  (It looks like the CCriticalSection name comes from Windows.)

You can read all about Boost's threading API in its documentation.


Bitcoin is a cryptocurrency. It runs on blockchain technology. Ethereum is another independent cryptocurrency that runs on blockchain technology as well.


What are the economics of confirming a block of transactions?

Mining a block (also called confirming) is not dependent upon the number of transactions in the block. A block with a single transaction is just as hard to mine as one with 1,500 and earns you the same reward.

In addition to the reward, miners can claim a fee, which practically is the difference between the sum of the inputs and the sum of the outputs. The rule to compute whether a fee is required can be a little complicated. The person issuing the transaction is free to include a fee or not but a transaction that doesn't may not get confirmed.

Finally, the mechanism by which reward and fees are claimed is by inserting a transaction in the block, in the first position, that sends the total amount to the miner's public address. The network validates it with all the rest.


Creating a raw bitcoin transaction and signing it with the private key using php and javascript

You also need to acquire the UTXO's which are spendable by your private key.

The private key in WIF private key format provides the information required to derive the pubkeyhash found in P2PKH(pubkeyhash) and P2WPKH(pubkeyhash) output scripts spendable by the private key. Deriving the pubkeyhash, or even address, can be done with BitcoinJS on the front-end.

Once you have derived the pubkeyhash or address key, you need to have an index to look-up all unspent spendable output points (utxo's) belonging to this key.

You can either build your own pubkeyhash/address index, or use an Bitcoin server implementation which does this (e.g. Libbitcoin-Server).

Your backend can lookup the pubkeyhash/address key and fetch all spendable UTXO's which are then signed on the front-end by your private key (depending on the amount and coin-selection strategy, you will select specific UTXO's to build the transaction which spends to your destination address(es)).


The total node count is not relevant. It's easy to spin up  nodes, or even fake nodes that just report a certain user agent string. That doesn't mean that they care about the rules, plan to keep following them if the hashrate majority goes another way, whether they'd even notice if they're forked off, or even whether they actually implement the rules.

What does matter is how much economic activity is following the fork's rules, and whether they're planning to keep doing so regardless of what happens.

Measuring that is something you cannot do inside the protocol. You need to look at company statements, press, ...


How's Blockchain like "magical Smart Contract"?

Bob's Candy Shop

What does this mean?

Sadly I think some of it is nonsense. Or at least overenthusiastic. Firstly when the author says taxes I think they are only referring to sales tax in the USA, not to other taxes such as income tax. Secondly I'd be very surprised if the taxman wants to receive individual tax payments for each customer transaction, normally these sort of taxes are paid periodically - e.g. at the end of a month. Thirdly, tax is often complex, there are often different tax-rates for different categories of product, different tax-thresholds and so on. Fourthly, I suspect the US taxman wants to be paid in USD not BTC and will want the unit-conversion to be based on an exchange-rate from a specific source - I don't think Bitcoin payment scripts have access to this sort of external data.Therefore I'd by very surprised if any but the most simple tax payment could be encompassed wholly within a purely  Bitcoin transaction without some off-chain support.

Buyer like Alice has QR Code. Why Charlie gave Bob QR code?

I believe the author is probably just referring to the standard way that a seller communicates a receiving-address to a buyer. Nothing special there.

This is just QR Code and buying movie ticket online What do with Block Chain?

If you purchase anything with bitcoin, the transaction involves a bitcoin-script. The transaction details, including this script are recorded in the blockchain.
The script is written in a simplified programming language and in an abstract way defines the parties involved and defines how they must prove they are entitled to spend the proceeeds.
There are some standard scripts.

Where's Block Chain in this analogy? Does Blockchain suppose be the "magical SmartContract"?

The blockchain is simply a list of transactions. It is like an accountants journal.
Smart contracts are either in the bitcoin-script in the transaction details or in some extra layer of software that sits on top of the Bitcoin network and only uses the bitcoin blockchain for final settlement (e.g. monthly reconciliation of accounts) not necessarily for each transaction.

Smart Contracts in Bitcoin
Wikipedia says

Bitcoin provides a Turing-incomplete script language that allows the creation of custom smart contracts on top of Bitcoin like multisignature accounts, payment channels, escrows, time locks, atomic cross-chain trading, oracles, or multi-party lottery with no operator.

The article refers to this PDF file: Atzei, Nicola; Bartoletti, Massimo; Cimoli, Tiziana; Lande, Stefano; Zunino, Roberto (2018), "SoK: unraveling Bitcoin smart contracts" (PDF), 7th International Conference on Principles of Security and Trust (POST), European Joint Conferences on Theory and Practice of Software

ELI5
This is the problem with ELI5. Many explanations to five year olds are of the form: "If you don't eat your greens the bogeyman will eat you in the night". You are not a five year old and are unlikely to find those sorts of explanation satisfying.


Help me understand Instawallet better to trust it more!

Instawallet doesn't support green addresses anymore.

It would have required to maintain a fork of the Bitcoin client which is not very practical, and probably not very secure either.

Instawallet works as a simple shared wallet, it monitors transactions coming in to each wallet's address and adds them to the wallet's ledger as they come in.

When transactions are sent from a wallet they are simply sent using the Bitcoin client, which will pick random addresses from the pool of funded addresses, that is why you can't derive the balance of a wallet or track its activity by looking at the block chain.

That also makes it an useful privacy-protection tool. (But contrary to what I saw written in a couple places it is absolutely useless to hop through multiple wallets, it doesn't increase anonymity in any way).


What happens if your transaction is never confirmed?

If a transaction goes unconfirmed for too long, it will eventually disappear from the network.

Most clients will remove it from their pool of unconfirmed transactions at some point. When most clients have removed it, you can go ahead and send the transaction again, this time with a higher fee. There's not a precise time when the transaction will disappear from the network, it could be days or up to a week. This is why it's always recommended to set a transaction fee.

The wallet that you sent it to cannot spend it because it's not confirmed. So you have to wait until it disappears from the network and send an entirely new transaction.


How does Bitcoin coordinate time between nodes

Nodes determine which block is "first" based on whichever block they receive first.

Or in other words, the timestamp on a block is not used to determine which block a node will add to their blockchain; nodes simply add the first valid block they receive to their blockchain.

As a result, if two blocks are mined at the same time, it's possible that different nodes on the network will have different blocks at the top of their blockchain. To illustrate:

Node1    Node2
-----    -----

 [x]      [y]
 [c]      [c]
 [b]      [b]
 [a]      [a]

block [x] was mined "first"
block [y] was mined just after block [x]
Due to network delays, Node2 ends up receiving block [y] first
Therefore, Node2 adds [y] to the top of their chain (but they also keep a copy of block |x|)

So at this point in time, there is a disagreement about the state of the blockchain on the network. This happens.

This situation is resolved when a new block gets mined.

For example, if Node1 mines a new block on to their chain:

Node1
-----

 [z]
 [x]
 [c]
 [b]
 [a]

This new block [z] creates the new longest chain on the network. So when Node2 receives block [z], they will adopt the new longest chain:

Node1    Node2
-----    -----

 [z]      [z]
 [x]      [x][y]
 [c]      [c]
 [b]      [b]
 [a]      [a]

...and the network is back in agreement about the state of the blockchain.

Summary:

The order of blocks (or which block is "first") is not determined by the timestamp on blocks relative to any network time.

Instead, nodes will add the first block they receive, and are free to disagree on which block is at the top of the chain. The order is resolved when a new block is mined, and all nodes adopt the longest known chain.


How can I restore my dogecoin wallet (android client)

I just hit the option softkey and a menu popped up. Then I tapped "Back up Keys" then tapped "Restore private keys".


Bitcoin ABC, Bitcoin Unlimited Cash, and Bitcoin XT are Bitcoin Cash node clients. They do the same job, and the most important difference among them is their developers: They are developed by three independent development teams.

Some other differences:

Bitcoin ABC uses Compact Blocks, Bitcoin Unlimited uses XThin, Bitcoin XT uses both Compact Blocks and XThin to download new blocks.
94% of the nodes are Bitcoin ABC, more than 5% of the nodes are Bitcoin Unlimited, and only a few (1-5) nodes are Bitcoin XT.

Update: It was 94% when this answer was written (when edited, there are more BU nodes!). You can see the live statistics here

Other than their brands and those ^ differences, they're all the same.

If you really want to help the network, I'd suggest to run XT or Unlimited, because if a node crashing bug was found in Bitcoin ABC, it'd affect 90% of the network. If the network was 33% Bitcoin ABC, 33% Bitcoin Unlimited and 33% Bitcoin XT, then no such bug would be important that much, and the network would be more decentralized.


How to determine if a cryptocurrency has a promising future?

Whenever I am looking into an ICO, there are some things I generally take into consideration.

1. Team

-Make sure the team is real, and verifiable. Check linkedin, or other sites to verify the teams identity.

2. Token allocation and funding

-Check their practices and see if they are common. Pundix’s ICO is a great example. Removing total investments as soon as an ICO’s coin reaches an exchange is a widely practiced strategy. Lately, more ICO’s are looking for ways to ensure the token is held for longer terms.

3. Token or coin supply

-Check to see the burn policy, and the % of coins going to the public vs the investors.

4. Purchase cap per person

-Some ICO's have bonuses for early investors with huge capital. Make sure there isn't 1 person holding a majority of the coin.

5. Know the Market Caps

-Try to guesstimate and speculate a realistic market cap for an idea. If the market cap is low based on the fundraising, but something that could potentially become huge, there’s a lot of potential.

6. Project idea

-What is the value proposition? Does it really need blockchain? Or is it just riding the hype? Make sure that Blockchain is necessary.

7. Likely to end up on exchanges

-To cash out easily, it must hit an exchange. The more likely, the easier it is to get your profit.

8. Working MVP or product

-Are you investing in a product or an idea that has to be proven and validated? The more developed the product is, the safer it would be to hold long term.

9. Activity among fans/investors

-Check telegram and other sites to see the feedback/hype from other investors.


Is it possible for the network to stop finding valid blocks?

The simple answer: no.

The not to simple answer: extremely unlikely.

Miners hash an input block, in the hopes of getting a result that satisfies the difficulty requirement, i.e., has a certain number of zeroes in front. Now the possibilities for the miner to vary the input are quite large. There is the 4 byte nonce, there is the order transactions are put into the transaction (for simplicity let's just assume it allows all permutations of the merkle root, 2^256), there's the coinbase in the reward transaction (which also influences the merkle root), there's the timestamp (not that variable but let's say we can vary by two hours => 14 bit) and there's the transaction count (up to 4 byte, that are not independent from the merkle root, but let's assume they are indipendent). So in total we have something in the order of 2^256*2^32*2^32*2^14~=3.49E100 possible inputs to find a block and 2^256~=1.15E77 possible block hashes. (These are all back-of-the-envelope calculation, and probably wrong, but just to give an idea of the scale of this)

Hence we would find ~3.02E23 hash collisions for each hash, and would have to not find a single hash that matches the target. Notice that hash functions are built with the stated goal of making hash collisions really hard (researchers have used super computers for decades to find a single hash collision), and you'll see it is unlikely to ever occur in anyones lifetime.


How to tell if a cryptocurrency exchange or trading platform is trustworthy?

Here's a few checks I'd advise anyone to do.

Does it promise to earn you more than 10% profit in less than a month? If so it is a fraud.

Does it make implausibly impressive claims like "SEC awards {businessname} as one of the best Trading platform of 2018 with 247 contact"? (hint: that's not the sort of thing the SEC ever does).

Are there very many spelling errors and poor grammar?

See if the website is a copy of another website. Take a jargon-phrase from the website, it should be around a dozen words and not include the business name (or other things copiers change) and put it in quotes in a web search engine. See if other websites are using the same phrases. See if any found websites are nearly identical copies. e.g. "We are the only binary options broker that truly places emphasis on you" (LOL!)

Use a "whois" service to look up the domain name registration

if the website is http://example.com/ look up example.com. Was it only registered a few months ago?
Where was it registered? Is the registrar located in a faraway country with a poor record for investigating online crime? Do you want to deal with a business that you have no way to sue? A place with no feasible legal remedies for you as a foreigner?

If the website claims for example "7 years of forex experience" but was only registered 1 year ago you should regard it as probably untrustworthy.

Check the website for contact details. Does it give a physical address?

if not I'd say it is untrustworthy.
Is it a full address or something vague (one site has "west midlands UK" as a contact address - which is obviously deliberately vague and useless as a contact address).
Use something like streetview in Google Maps to view the contact location.

Some websites give an address that is actually a small wooden home in farmland or suburbia - this is obviously a fake address chosen at random.
Some websites give an address in an office building that rents tiny
offices by the day - this is suspicious

Look for company registration details. For example, if the site says it is registered company 123456 in the UK, go to the UK companies house website and look up that company number.

If details don't match, don't trust the website
If details do match check how long ago the business was first registered and whether they have filed accounts etc in the last year. Are they shown as active or inactive, have they changed names. Look for evidence of a bad business - sometimes you find a winding-up notice or de-registration notice.


Yes. All of the information about your wallet is stored in the file of the same name as your wallet in the wallet folder of the electrum datadir. Copying that file elsewhere will allow you to keep all labels and comments on your addresses and transactions.


Why are exactly 4 bit windows used in the lookup table of libsecp256k1 to speed up point multiplications?

What you are talking about is the table used for constant time operations w/ secret values, e.g. for signing and key generation (see the heading "Point multiplication for signing").  To prevent leaking secret key data the entire column must be processed for each digit. More bits in the column increases this work exponentially.  From memory, I believe that 5 bits was similar but slightly better performance on systems with big fast caches and memory busses, but worse performance on systems with slow memory.

There are other ways that we could increase performance there (e.g. constant-window NAF, or the techniques from PR546) but we don't generally consider signing/key generation performance to be terribly important. I think generally our only strong goal wrt that performance is to be no slower than less carefully developed alternative software.

You can try changing the sizes with a few lines changed in the software.

The variable time multiplies in the library use much larger tables and fancier techniques.


Where can I get historic data series of Bitcoin prices?

EDIT: These links appear to no longer work

You can get it at Bitcoincharts:

http://bitcoincharts.com/t/trades.csv?symbol=SYMBOL[&start=UNIXTIME][&end=UNIXTIME]

It returns a CSV file with the format:unixtime,price,amount.

For example, you can use this link to get the MtGox prices since August:

http://bitcoincharts.com/t/trades.csv?symbol=mtgoxUSD&start=1312174800


However, have never had the option of providing a passphrase.

You must certainly have set a passphrase in the past. There's no way to remove it without knowing exactly what it is. If you can not recall what password you set, your funds are lost.


How prevalent are coin attacks with botique altcoins?

If you'd like to be absolutely sure that some malicious miner won't attack your coin, you could hard-code in a set of 'approved' miners (ie, your miners). Doing so greatly undermines some of the core concepts of a cryptocurrency though (open, permissionless system, etc), so that probably isn't a good option by most measures.

So then, what is the best option?

Many coins choose to employ an 'ASIC-resistant' algorithm, with the goal of preventing ASIC-wielding miners controlling their network. Instead, the idea is that GPU (and perhaps CPU) miners will be the ones securing the network, and many people argue that the the distribution and economies of scale involved in GPU mining are better-suited to create a decentralized network.

However, in practice we've seen that perhaps no algorithm is ASIC-proof. In fact, an algorithm that is extremely difficult to build an ASIC for may just concentrate mining power even further, as very few people will have the skills and resources to create an ASIC for such an algorithm. Such people could thus easily control the majority of hashpower on a network, once they have built some ASIC miners.

For a more in-depth look at this issue, check out this article written by David Vorick (a SiaCoin dev).

It is worth noting though: nobody is going to invest the resources to invent an ASIC that attacks a very small coin. There would be no economic incentive to do so, this problem only becomes apparent once the network has grown and is storing a worthwhile amount of value. (Keep in mind though, if you choose an algorithm also employed by a larger chain, then such ASICs might already exist).

Trolling aside, it is also worth noting that it is not necessarily in a miner's economic interest to attack your coin. If a miner owns some ASICs, and can make money by mining with them, then there is perhaps a substantial opportunity cost involved in instead using the ASICs to attack your chain. This incentive helps keep miners 'honest', in that they will benefit more by using their hashpower to secure a chain, rather than attack a chain.


Why can't lightning network channels increase balances？

Any additional funding transactions would not be covered by older commitment transactions which can result in the loss of funds. Older commitment transactions will not contain inputs that spend from the new funding transaction. The funds sent in the second funding transaction require B to sign a spending transaction, and if B refuses, then A has no way to get those funds back should an older commitment transaction be broadcast.


The tlv_payload is a modification to the way onion packets are created between the 1.0 version and the 1.1 version (current working version) of the BOLT specs. The (optional) feature is named var_onion_optin in BOLT#9.

In V1.0 of the spec, there was a fixed structure for sending onion payloads to hops along a route, which contained a short_channel_id, a cltv_expiry and an amount_to_forward. In the latest version, implementations can add custom data to be forwarded in addition to the previously required ones. These contain a type and length encoded as a compact size integer, and the value of length bytes is serialized afterwards. Hence Type-Length-Value, or TLV.

Nodes which support the newer format advertise the var_onion_optin feature when they broadcast a node_announcement message, by setting bit #9 in the features field of this message.

In the lnd codebase, the feature folder contains the logic for feature bit vectors. It appears from manager.go that LND now treats the tlv_payload as enabled by default unless it is disabled as part of the config. Older versions of LND will obviously not support the feature and will use the legacy hop_data payload format.


What exactly happens when a new wallet is created?

Your wallet is a collection of private keys and a record of the transactions relating to them.  By default your wallet has a key pool of 100 keys.  So when your wallet is created, around 100 private keys are randomly generated and stored in your wallet.

Each private key has a corresponding public key, and each public key has a corresponding address.  A public key isn't "the same thing as" an address, but there is an algorithm that can give you the address corresponding to any given public key.  The reverse isn't true.  There are many different public keys for each address, since public keys are 256 bits wide and addresses are only 160 bits wide.

When you click 'new address' in the 'receive coins' tab of the client, it will show you an address you've not seen before.  It is taken from the 100 address keypool.  The keypool is topped up when possible to always contain 100 unseen addresses.  If your wallet is encrypted then it's not possible to top up the keypool until the wallet is unlocked with the passphrase.

Also, when you make a transaction out of your wallet, it's quite likely that the amount you are sending doesn't exactly match the sum of any of the inputs you currently have private keys for, and so some 'change' needs to be sent back to your wallet.  When this happens an address from your 100 address keypool is used to receive the change.  In this case the keypool will be immediately topped up, since your wallet will need to be unlocked since you're spending coins.

This all happens behind the scenes - you won't see any evidence of it happening unless you look at the blockchain.


How to solve error: Incorrect or no genesis block found. Wrong datadir for network?

Question:

  when I run ./bitcoind I get this error

Error: Incorrect or no genesis block found. Wrong datadir for network?

Answer:

Delete /home/boodu/.booducoin (~/yourcoinname/.yourcoindatadir) folder and restart daemon.


Why wouldn't miners change the protocol? (e.g. change difficulty)

The rest of the network, which uses the existing difficulty parameters, will reject the new blocks generated by your modified miners. There will be a longer blockchain, but there will not be a longer valid blockchain according to the established rules.


How to connect a bitcoin node to a complete node through the local network?

As mentioned above, your command needs to be ./bitcoind -connect=<iplocal>

-connect= will connect ONLY to that specified node. -addnode= will connect to the specified node in addition to attempting to connect to global nodes. If you're bootstrapping a new node either will work


Is there an open source bot I can get for BTC-E?

You can write your own bot in any modern programming language using the BTC-e API. Also MtGox, Bitstamp, Bitcoin-24 and probably more popular exchanges support this.

These API's mostly give you the possibility to track the price, the market depth and place orders, making easy for you to implement your own trading bot.


Unfortunately, this is not possible, unless Bitpay allows you to import individual private keys, which, AFAIK, they don't.

Almost no wallets use the same wallet file format. They are generally incompatible from wallet to wallet and there is no standard (nor should there be). A wallet file is only good for the same software the made it.

Electrum's seed phrase is also incompatible with all other wallets as it uses a different algorithm to generate and decode the phrase. They do this since the standard way (BIP 39) is much less secure as it was primarily designed for hardware wallets.

Lastly, why would you move away from using Electrum? Electrum is, IMO, far better than any other SPV wallet out there, and especially better than the ones created by services like BitPay which rely on BitPay operating special servers in order for it to function.


Unconfirmed Transaction? Money does not show in wallat

Unfortunately ou have set a fee that is way too low.   This tends to happen if you are using an older version of whatever wallet your are using.  The newest version of a wallet do not allow you to set a fee that will get you into trouble.  I will try to enter your transaction into the ViaBTC accelerator, that usually will do the trick.   I suggest that you upgrade to the latest version, and make sure that your fee is of a reasonable amount.  Here is a site that shows you what the current wait time are for confirmation based on fee amount.   https://bitcoinfees.21.co/


Best way to get the OID of an order created at TradeHill?

You must keep a record of your orders and compare them with the returned list. Alternatively, you can sort the returned list according to date. The order you posted is the most recent.


Fastest device to perform single-threaded SHA256 hashing

Well, existing Bitcoin mining hardware would indeed not be any good for iterated hashing, as it's not designed to do that. However, SHA-256 is not a hardware resistant hash function. The most complex operation in the hash function is addition modulo 2³², which is quite easy to implement in hardware.

An attacker could implement a fast SHA core on a chip, which would consist of calculating a single round as fast as possible. This is the opposite optimization as a Bitcoin miner: miners prefer very many parallel cores that run at slower clock speeds to save energy per hash. Such a hypothetical chip would definitely be much faster than a CPU at calculating iterated hashes.

What you want is a memory-hard hash function such as Argon2. Its execution requires fast cache, which is plentiful on commodity CPUs but costly to build into other hardware. It has a parallelism parameter where you can allow up to, say, 4 cores. Iteration of the function will not be any faster past that number of cores, and custom hardware will not increase the attacker's speed.


Allowing Incoming Connection on Bitcoin Core

I had the same problem. The port was open, but the test at bitnodes.21.co would fail. However after my Bitcoin client downloaded the entire BlockChain everything worked. I used about 144 hours to download the entire chain with a 150Mbps fiber line.

Before the entire chain was downloaded the test at https://bitnodes.21.co/#join-the-network would give an "Unreachable" error. After it downloaded it changed to Green saying it's reachable.

So you just have to be patient :)


Inflatory and deflatory economy comparison

This topic on bitcointalk forum might be a good place to start:
Deflation and Bitcoin, the last word on this forum


Why tx informations of a specific transfer in BITCOIN protocol will send to many IP addresses?

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


How to recover an electrum wallet from seed

First download Electrum, try to get a version closest to the one you were using. Get the portable version because you may need to get a higher version if it doesn't work.

Open the program, File -> new/restore -> enter in your seed when asked.

When it asks for a password, it means a new password to save this wallet with encryption.

Then wait for the syncing to happen.


What goes in the tx hash preimage when signing with 0x83 (SINGLE|ANYONECANPAY)?

From BIP143:

  If the ANYONECANPAY flag is not set, hashPrevouts is the double SHA256
  of the serialization of all input outpoints;

  Otherwise, hashPrevouts is a uint256 of 0x0000......0000.

All the details you need are in the BIP


Is the time a transaction was done recorded in the block chain?

There's a unix timestamp in the block message. https://en.bitcoin.it/wiki/Protocol_specification#block

So you would be able to get know the transaction hit the blockchain down to roughly a 10 minute resolution.


The seed generated by Electrum is a 128-bit random number. It is encoded as a sequence of 12 words, for the purpose of memorization. However, it is important to understand that it has 128-bits of entropy.

https://bitcointalk.org/index.php?topic=153990.msg1632127#msg1632127

https://electrum.org/faq.html#seed


What computers are those in the picture?

These are Application Specific Integrated Circuit(s), a computer that is designed for Bitcoin mining. PCs used to mine too, but when FPGAs released (later ASICs released), mining with a PC wouldn't be efficient because of competing ASICs (and electricity fees).

Currently Bitmain (shop.bitmain.com) is the most preferred ASIC manufacturer, but it looks like it may not stay so, in a 6-12 months. (The most popular ASIC is Antminer S9, $1500, currently.)


Mining pools allow miners to reduce the variance of their income. It is possible to mine without a pool. This is known as solo mining.


Can I retrieve my Bitcoins when I only know my receiving address?

If you neither have the mnemonic, the identifier, or the wallet file, there is probably nothing that can be done to restore your wallet.

Especially, the receiving address is not sufficient to restore your wallet. Otherwise, any other user could claim your wallet as it is public knowledge. Clearly, that would not be secure.


What does it mean when a confirmed transaction gets reversed?

Every now and then, blocks become orphaned during what is called blockchain reorganization.  This happens when two valid blocks are found at about the same time, and the network is split on which one is considered the top of the blockchain.  These two blocks can contain different sets of transactions, so one block may contain your transaction while the other one doesn't.

This situation will be automatically resolved.  Let's call the two blocks A and B.  Eventually, a new block will be found on top of one of the two competing blocks.  Let's say this new block, C, is found on top of A.  When C is broadcast, any nodes recognizing the B as the tip of the chain will see that more work as been done on the other fork, and will orphan B in favor of A and C.  It will be like B never happened.  If your transaction was confirmed as part of B, it will be like your transaction never happened.

The good news is that it is likely that A and B share a good deal of the same transactions.  Even though you may have been recognizing B instead of A, there's a good chance the transaction will be already confirmed in A when you come around to recognizing it.  If not, it means the transaction will still be in the mempool, and is likely included in C or will be included in a later block.

As you can see, the odds of this happening go down as each new block piles on top of the block containing your transaction.  By the time 5 blocks have been mined on top of the block containing your transaction (thus 6 confirmations) there is no reasonable chance of that block being orphaned.  The transaction is now permanent.


How does vanitygen calculate difficulty?

There are two parts to this.

First is leading 1s.  A leading 1 represents a 0 byte i.e. 8 bits.  This means that for every additional 1 you prefix your search string with the difficulty increases by 256 (2^8).  You can see this easily by checking the difficulty of prefixes 1, 11, 111 etc.

Second is other characters.  Here the difficulty changes depending on how many bits you are specifying, because as your value is converted from base58 to an integer value and from there to a power of 2.  Depending on your second number in your 2-digit prefix the difficulty will move around a bit (plus there will be rounding errors).  Again, easy to see with prefixes of 12 and 1z (which are 1 and 57 in base58 encoding, respectively).

Once you get past all of that you should find that your 58 to the power of the number of digits comes in to play.  For example the difficulty of 1234 should be 58 times the difficulty of 123.


What are these bitcoin nodes and what purpose they serve?

The rules of bitcoin, much like the rules of a board game, are fixed. In board games, there is an instruction booklet that tells you what the rules are, and anyone not adhering to the rules is breaking them, which is known as cheating.

Bitcoin's rules were laid down by Satoshi Nakamoto, its inventor, and its rules are enforced by each player (node). Nodes check if the blocks are constructed according to the rules of Bitcoin, and punish miners who construct cheating blocks.

Having played Catan quite a bit, I've found that some people enjoy playing with house rules. Some people feel that every player should start with at least one of each resource, for example. These rules can be enforced by the whole group, as if they were in the instruction manual.

The same is true for bitcoin. Some people feel that the Bitcoin protocol is better suited by having small additions to the rules, or notable omissions. These people are free to write their own software, which enforces their own rules on Bitcoin.

Some are just translations of the bitcoin instruction manual to another language. Some aim to change fundamental parts of the protocol, such as the btc1 nodes, or Bitcoin XT nodes.

edit: The most-used client is bitcoind, which is the command-line interface of "Bitcoin Core". Due to the fact that a majority of people are using this client, it dictates the current consensus rules (the rules of the game), and other clients either adhere to it, or risk getting "forked".

Node software has been politicized these past few years. This is a different topic altogether, and I recommend you google "the bitcoin scaling debate" for a primer.


How can I verify someone controls the private key behind a segwit address?

First of all, the operations signmessage and verifymessage allow to prove that whoever creates a signed message with this address specified can receive Bitcoins in that address. This does not prove the user owns the private key (corresponding to the public key the address is generated from) as this address' private key could be handled by a third-party wallet service (like an exchange), so the exchange would be able to create this signed message too (and the user may not have access to the private key).

With P2SH addresses you cannot create signed messages as they are Pay-to-script-hash (P2SH) addresses. This means using this addresses in outputs can only be unlocked by specifying a valid redeem script in a transaction that spends this outputs where the adress is specified. Therefore, not necessarily public keys must be present in the mentioned script (like a HTLC) and a signing scheme can't be developed as it would require to reveal the redeem script which may cause a serious security issue (like in HTLC after the timelock is over).

A fix you could try in order to get the same functionality is to create a transaction that spends this UTXO where the address is specified with a minimal amount of 1 satoshi and no outputs. This way who does this can prove they can receive Bitcoins in that address.

But notice the security issues revealing a redeem script means (for instance this would not be appropiate for a HTLC but could be for a multisig where every one agrees to create that transaction). This problem replies also to the problem with performing this operations with P2WSH addresses as they share the same main problem.

With native P2WPKH (and P2SH-P2WPKH), a new signing scheme had to be defined due to technical issues. This is already partially implemented (just implemented with P2SH-P2WPKH addresses) in Trezor's web wallet and under development in Bitcoin Core.


Multi-sig N of M where 1 of the keys can see the balance but not spend (read-only key)?

The author of this paper seem to have put some thought into the problem you describe and has proposed a solution that seems relevant to your question:

A new HD wallet that tolerates key leakage
Master key generation. Instead of one master private key, our HD wallet uses
m master private keys ˆd1, . . . ,ˆdm for some reasonably-sized m to be determinedby the requirements of the wallet. (For example, in the combined treasurer-auditor use case of Section 2, m must exceed the number t of departments in the organization.) To keep the master private key size down, these master private keys could be generated pseudorandomly with no loss of security using, say, therudimentary deterministic wallet described in Section 1.*

https://eprint.iacr.org/2014/998.pdf


How to make the commission for withdrawal of Bitcoin on the exchange consistent with the miner’s fee viewed on the blockchain browser

The fee your exchange is charging you is the fee for their services, which includes the miner fee that they need to pay on your behalf.

It is normal that this number is higher than what you view on the block chain explorer.


BitcoinSharp does not use the same format that the standard Bitcoin client uses for its wallet file.

BitcoinSharp simply serializes the Wallet object into Binary and writes it to a file whereas the standard Bitcoin client writes its wallet.dat file in a BerkeleyDB format, so the two are not compatible.

You could use something like pywallet to export the keys from wallet.dat and then manually add them to BitcoinSharp's Wallet object, but you won't be able to directly read a wallet.dat.


The -gpu=X command line is telling it which of your CUDA devices it should use, not how many it should use. Like most things written by programmers, the index starts at zero.  If you have two video cards, run it once at the command line with -gpu=0 and then a second time again with -gpu=1.  Once you work out your ideal fine tuning on aggression, gpugrid and gputhreads (if you do at all), it's easiest if you make a batch file (unless you're using GUIMiner, in which case create a new CUDA miner for the second card, same extra flags on both other than gpu=0 or 1).

You can execute it twice without specifying the GPU and it will certainly run, but from the console output it appears it assigns both of them to the first device.


Where and when should the coinbase transaction(including the miner key) be added?

The coinbase transaction is created when the miner creates the template for the block which they attempt to mine. Unlike regular transactions, it does not have regular inputs. The miner simply specifies the outputs to spend the coins, where the sum of the output amounts must be less than or equal to the total amount of fees in the block plus the subsidy. The coinbase is always positioned as the first transaction in the block.

The coinbase transaction has the same structure as regular transactions, but for each txIn it has, any txOutPoint should just have a zero value (there is no previous txid to refer to). The scriptSig can contain arbitrary information, as miners do not need to sign anything. Miners add information to the scriptSig such as their name, or additional source of entropy for mining. Additionally, some consensus rules which have been soft forked into Bitcoin require that the scriptSig contains the block height and a merkle root of wtxids (for segwit).

The process is roughly like this:

Miner creates a coinbase template which spends some not yet known amount of money to one or more outputs.
Miner sorts transactions in the mempool by highest paying fee per weight unit (per byte in original), and picks some number of transactions such that their serialized size plus the serialized size of the coinbase is not greater than the block size limit.
They sum all fees paid in the included transactions and add it to the subsidy to create an amount that the block is worth.
They update the coinbase template with at most this amount being spent (it is possible to not claim the full amount of fees or the subsidy, but overclaiming produces an invalid block).
The miner computes the merkle root of all of these transactions txids (where the txid is the double-SHA of the serialized transaction), taken as a binary tree ordered by the position the transaction is serialized in the block. The coinbase is explicitly the first transaction.
The miner inserts this merkle root into a block header with the 5 other required fields (version, prevBlockHash, target, nonce and timestamp) and serializes it.
The miner repeatedly attempts double-SHA256 on the block header until the resulting digest, when taken as an integer, is numerically less than or equal to what is required by the target in the header. The miner modifies the nonce, or occasionally timestamp for each double-SHA256 attempt so that a different digest is produced, but the other fields of the header remain unchanged.
At some regular interval, if the miner has not yet found a successful hash, or if a new block is received, they compute a new template by starting this process from the beginning, which can take new information and may provide a higher reward. They discard the previous template they were working on. If a new block was found, any transactions which were included in the block are dropped from the mempool.


How to get BTC and ETH prices from Binance in Google Sheets?

Following up on my question.

Leon had a point in his comment, Binance doesn't have USD pairs, only USDT.

I updated my cryptofinance calls to =CRYPTOFINANCE("BINANCE:BTC/USDT") and =CRYPTOFINANCE("BINANCE:ETH/USDT") and it worked like a charm!


How to efficiently find if in-address in transaction is valid and has required amount of data?

There are no such things as "in-addresses" or "from addresses", and this has nothing to do with merkle trees, or even blocks.

Bitcoin works by transactions creating outputs and other transactions spending from previous transaction outputs. Each output has an associated value. When you spend Bitcoin, you are spending from previous transaction outputs. Your transaction will include a reference to the output that it is spending: the txid and the index of the output. Since all transactions (except coinbase transactions - the coin generation transaction, not the company) spend from a previous transaction output, the transactions are all chained together. You can walk backwards through this chain of transactions to check that the values of all the transactions are correct.

So when a node receives your transaction, it looks up the outputs that your transaction is spending from and makes sure that no other transaction has spent those outputs already. Then it sums the values of the outputs being spent and makes sure that that sum is greater than or equal to the sum of the values of the outputs being created.


Do I need to hire miners if I don't know how to mine?

Mining and verification are different. Miners verify blocks, and verify what they're mining on before they mine it. Users also verify blocks, but do not mine them.

Mining and verification solve different problems. Verification makes sure that a transaction doesn't spend more than a person has. In this context, verification doesn't mean looking at official documents. Mining is used to determine what order two transactions happened in.


Could I store a bitcoin private key value in a Name Coin?

Yes. So that the whole world can see it? Yes seems like a good idea.

The NameCoin block-chain is public, although you could encrypt it in the NameCoin chain, but why there? If you are scared to lose any privates keys you should work on your back-upping strategies, not uploading it to the public domain in the hope none will realize it is a ECDSA Bitcoin private key.


Get "Value at time of transaction" from blockchain.info api

I inspected the network calls and found this endpoint: https://blockchain.info/frombtc?value=499987100&currency=USD&time=1449868758000&textual=false&nosavecurrency=true

it returns exactly what I need.


Easy Miner showing zero work, no devices shown

So if you read the fine print on "Easy Miner", you can only use the software with their hardware devices in "out-of-the-box" mode (direct download --> run) (Disclaimer: I have a Jalapeno 5 GH/s miner, this shows up as a valid device. My GPU does not, however).
See this thread about how to configure GPU mining. I believe it's in the settings, plus you need to set a bunch of flags to get the miner to recognize your GPU settings.

You would most likely be better off using CGminer / BFGminer, if you want to go the GPU mining route, however as the comment says, you're unlikely to get any real yields from any amount of GPUs, as they are just not as efficient as ASICs or FPGAs (see this for a good comparison of dedicated hardware versus graphics cards).


Where does the random number come in to play when signing a transaction?

This is a common misunderstanding. It just so happens that signing with RSA is the same as encrypting with the private key. But this is a quirk of the RSA algorithm. Bitcoin doesn't use RSA, it uses ECDSA. DSA is strictly a signature algorithm -- it has no encrypt operation at all.

The ECDSA signature operation, like the DSA signature algorithm, requires a random value in order to generate a signature. The signature consists of two derived parameters that can only be generated with the private key but that can be verified without it. The relationship between the derived parameters depends on the message, so the message cannot be altered.

Sadly, if the same random value is used for two signatures, the private key can be derived from the signature.


Are bitcoin commands resistant to race conditions and thread-safe?

Yes. All these transactions do is create a new transaction (or move entry) in the wallet. Balances are always calculated on the fly (though partially cached) from the transaction list.


How does ScriptPubKey know the public key of an Bitcoin address?

Addresses are really just shorthands for particular scripts. The standard address type (starting with a '1' on mainnet) does in fact correspond to the exact type of script you gave above.

If you base58 decode such an address, you end up with a byte string of the form 0x00 + [20-byte hash] + [4-byte checksum]. The corresponding script is OP_DUP OP_HASH160 [20-byte hash] OP_EQUALVERIFY OP_CHECKSIG.

So, in a way, your address does contain the public key's hash.


crypto currency exchange and cold storage

I sincerely doubt that any exchange uses individual cold storage wallets, the overhead would be too big: Every time an offer is matched on the exchange or somebody wants to withdraw money, the individual wallets of the involved parties would have to be imported from cold storage and then recreated.

On the other hand, if an exchange only used a single address for cold storage, if they ever had to import it, all money would be online at the same time. That would be very insecure.
It might be feasible to sign transactions offline and then safely transfer those via mobile data storages. The offline computer would have to be made aware of the current state of the Blockchain regularly though, so, on the other hand the blockchain would have to be transfered to it manually as well. The problem I see with that would be that withdrawals would be extremely slow, or you'd have to have people running USB sticks 24/7.

I would assume that every exchange uses many different cold storage addresses. If I were to create a scheme, I would reroute all deposits directly to cold storage upon receival, and change the cold storage address in use whenever a pre-determined cap is reached. I would only store an amount on each cold storage wallet, that I'd be comfortable to have in my hot wallet at one time.

I would then keep a small amount of crypto currency in my hot wallet, in order to automatically process withdrawals. Whenever the amount in my hot wallet runs low, I would import the oldest cold storage address.


Is there a way to make a crypto-currency stable by design? How?

There is a few problems with giving a crypto-currency a stable value algorithmically:

Stability compared to what?

The algorithm would have to be specifically pegged to either an asset, a currency, or some kind of calculated wealth index. But, if it were stable in comparison to e.g. the USD, it would not be stable in comparison to other currencies, or a barrel of oil. There'd always be room for speculation, and it would become completely decoupled when the value it is pegged to ceased to exist.

Stabilizing the value requires control of the money supply

In order to guarantee a certain value, e.g. an exchange rate of 1 SC (StableCoin) = 1 USD, you'd have to create an unlimited offer to buy and sell SC at that price. Both is very hard to integrate into the protocol:

In order to lower the price to 1 USD/SC, you can easily have the algorithm create more SC. However, it is hard to algorithmically accept fiat payments in order to sell them! Essentially your algorithm would need to implement bank contracts, user management and all the other shenanigans exchanges do.
To increase the price to 1 USD/SC, you'd have to be able to buy any amount of SolidCoins at 1 USD/SC. That requires very deep pockets. You also have to provide all the exchange services as before.

Then, if you wanted a proof-of-work validation, you'd also have to be able to buy back any mining rewards.

In short, I don't think that stability can be guaranteed algorithmically. You would need a central entity that guarantees the price by buying and selling at a fixed value, perhaps for a trading commission. This cannot be implemented in the algorithm, as it would require interfacing with the fiat world, which is not completely digital.

Addendum:

After thinking a bit more about it, I realized that when you create a system that is stable compared to another unit of account, essentially you create a debt-based voucher system for that other unit. Unless your currency decouples from the central market maker by being more successful than what it derives from, your currency remains completely dependent on the well-being of the central market maker – it will lose most of its worth should the central market maker default.

If you follow through on that thought, you essentially arrive at the system that is ripple, where any user can be a "central market maker" and issue his own StableCoins in form of IOUs pegged to any unit of account other people trust him to owe them.


Can I use Electrum seed as a paper wallet?

You should create your wallet from a pc that will never connect to the internet again if you want to secure your bitcoins 99.99%

If you don't have another PC, use Ubuntu Live CD/USB.

Boot from Ubuntu live cd/usb.
Install Electram, Bitcoin core, or any tools that enable you to generate wallet and create transactions.
Generate your wallet.
Write the seed (or private keys) on a paper.
Re-boot your pc.

But, in this way, you need to install Electram each time you need to sign a transaction.


Copying the same wallet.dat to two different computers will initially seem to work, but if you continue to use bitcoin-qt to send bitcoin, the two copies will get out of sync.

The reason for this is the automatic use of "change" addresses. Each time you send an amount less than you originally received, there is "change" that must be returned to you.  The developers of bitcoin-qt considered this to be a privacy weakness, as it would make it easier to tell for sure how much was paid and to whom.  To make it more private, they generate a new random "change" address in your wallet and send back your change to that new address.  To a third party looking at the block chain, it is hard to tell who holds the change address or who was the actual recipient of the transaction.

The reality is that the use of change addresses does little to improve privacy, but sets up new users for a "big surprise" the first time they send a small amount and see their wallet balance temporarily go to zero prior to confirmation of the change. It also makes it unsafe to copy the same wallet to multiple computers.

There are other wallets that give the user control over use of change addresses and that also make the change addresses visible and therefore more understandable.

Another area where other wallets can help is in the generation of new addresses.  The original bitcoin-qt wallet generates new addresses randomly.  It tries to keep a pool of pre-generated addresses, so that if you copy a wallet it will seem to generate the same new addresses as the original, but eventually the pool of keys will be used up and after that the two copies of the wallet will start to have different contents.  The Electrum guys solved this by making the whole wallet "deterministic".  That means that all future keys are determined completely by the "seed" and are not truly random.  Because of this, you can restore the same wallet on multiple machines and all copies will forever remain in sync.

There are plans to add this sort of functionality to the main bitcoin-qt wallet, but until that is done, alternate wallets are needed if you want to share between computers. Electrum is not the only wallet that provides all these features, but it is the one I am most familiar with.  See electrum.org.


Are specific private keys weaker than others?

They are weaker in the sense that they are easier to guess because the attacker has a more limited set of private keys to guess from. All private keys are equal in terms of just taking a public key and trying to guess the corresponding private keys, because, without extra information, one has to check every possible private key (until the correct one is found). But when one knows the private keys weren't truly random, by implication one knows that there is a certain pattern to the possible private keys. This means that the attacker can guess private keys from this pattern which is smaller/quicker than guessing all possible private keys. I can't speak to the specific weak generator in question, as I haven't heard of it, but with a general understanding of cryptography, I can say this is what people mean when they speak of weaknesses in the key generator.


Armory 0.93 on Testnet: consistent unconfirmed Txs sent from connected Bitcoin-cli (log attached)

OK, I solved this by numerous trial and error CMDs. The problem lay in the Armory implementation, specifically, the --datadir flag.

The working CLI flags:

ARMORY: -qt.exe --testnet --datadir=d:\data\armory\testnet3 --satoshi-datadir=d:\data\bitcoincore --rpcport=8332
BITCOIN-QT: bitcoin-qt.exe -datadir="d:\data\bitcoincore" -testnet -rpcport=8332

Contradicting Armory's FAQ (in the FAQ itself) is the requirement to explicitly identify the testnet3 directory for the --data-dir flag (--data-dir==SOME\DIR\Armory\testnet3). If the testnet3 directory isn't identified, Armory confuses the mainnet blockchain data with the testnet chain data.

The bitcoin.conf contents were:

listen=1
daemon=1
server=1
rpcconnect=127.0.0.1
rpcport=8332


Problem to link to libsecp256k1 on ARM architecture

It seems like pkg-config found libsecp256k1 in the build-libbitcoin directory. which is part of libbitcoin, so they probably build libsecp25k61 there.

The reason your code doesn't compile is because your libsecp was compiled with libgmp enabled, now this is a dynamic link.
So if you're trying to create a binary here you need to add -lgmp and if it's not in your system libs you'll need to also give a location to the .so file

Another option would be to recompile libsecp with libgmp linking disabled.


Accounts are purely a client-side feature. It's just a virtual balance, allowing you for example to maintain a balance for different users of your wallet.

All coins in a wallet are always shared among all accounts, so the 'from account' field does not influence the actual transaction created in any way, or which inputs are used for it. It simply changes which virtual balance the amount is deducted from.

If you really are using the accounts feature (unlikely, it's only useful for a limited number of use cases), and really need to send 'from' different accounts, use the move command (which is local only, and doesn't construct any Bitcoin transactions) to move amounts from one account to another to correct before or afterwards.


What are the arguments for and against the increase of the block size limit?

Please note, this answer was written in Februar 2015. The debate has significantly evolved since then, but I haven't gotten around to updating this answer, yet.

I'm sorry, this kinda turned out less brief than it started.

TL;DR: Very briefly, it is an issue of opposing ideologies:
Proponents wish to provide a common good to everyone and believe the increase in blocksize to be necessary to that end.
Opponents feel that a) it is impossible to introduce a change of that magnitude to Bitcoin at this stage, b) bigger blocks will mess up mining dynamics, or c) the increase changes properties of Bitcoin that shouldn't be changed.

What happened before

Originally, there was no blocksize limit. In fact, Satoshi Nakamoto was envisioning "100 million transactions per day, [...] taking 100GB of bandwidth" even in 2008. The blocksize limit was introduced later, when people where starting to play around with bitcoin, but before the value picked up significantly, when a worry came up that people might bloat the blockchain with cheap "spam transactions".¹
The problem is that 1MiB of transactions provides such a small capacity that, we'd be limited to seven transactions per second at minimal transaction size, or extrapolating from current transaction sizes, around four transactions per second. The block limit has not been encountered yet, and is therefore not yet a serious restriction, however this is significantly less than competing global payment networks can handle.
The thing is, that Bitcoin has become fairly valuable, and people want different things out of Bitcoin. The "apolitical money" is very political suddenly (as it always has been).

Arguments against increasing

There are quite a few different concerns here:

Bigger blocks will destroy the market for transaction fees
Increasing blocksize will make more room for transactions, which could reduce competition to be included in a block, in turn lowering transaction fees. In the long run, the block reward will dwindle, therefore less money would go towards mining, and the security of the Bitcoin network would wither with the lower income.

Bandwidth requirements are too much for full nodes
At 20MB per block, full nodes would have to download 2.8GB transaction data per day. This will be not only challenging data storage, but might actually be beyond the bandwidth capacity/datacap of some full node maintainers. One must consider especially that full nodes also serve the requests of thin-clients, so upload capacity might be more important than download capacity. However, on internet contracts for home-users upload speed is often significantly lower than download speed.
It has been suggested that a larger blocksize would quickly lead to a large increase of transaction numbers due to induced demand.
"Bigger blocks will lead to centralization."

Consensus may not be achievable
Once the first block larger than the 1MiB limit will be mined, a hardfork will occur between the network participants that refuse blocks greater than the limit, and network participants that accept it.
Blocks mined on the old network remain compatible to the new network, but not the other way around. Some voices have announced that they would use the fork as an opportunity to double-spend all their Bitcoins, spending them to themselves on the 1MiB-chain, and selling them on the 20MiB-chain, to profit and drive the new chain in the ground.
Some users suggest that this supporters of that proposal have sufficient Bitcoin holdings and support that they can essentially force failure of the blocksize increase, they presume that exchanges would land on different sides in the discussion, but all users would quickly flock to the "safe old chain", once the "civil war" starts.

Bitcoin is destroying viability of altcoins
An increased Bitcoin blocksize would decrease demand for other blockchains, hurting investors of altcoins.

Bitcoin is not meant for every person on the planet to pay for their every cup of coffee
Some people feel that Bitcoin should be an exclusive privilege for settling between companies and the super-rich. A bigger blocksize would dilute the exclusiveness. They argue that something that is useful, but universally available is worthless. Bitcoin instead is meant to "force the poor to yield to the rich, universally, as a matter of course".

People are feeling that something is being decided without them being consulted

"There is only one proposal, we have no choice."
"We cannot predict how quickly bandwidth will grow, the proposed increase it too much."
"There is no consensus, forking without community support is a dead-end."
"There will be huge problems if we do this."
"Why haven't the miners been asked?"

I have trouble relating to these last statements, as the discussion about the blocksize limit has been going on for years.

Arguments for increasing

The transaction capacity is too low to support a global payment network
4.4 tps (transaction per second) are too few to support a global payment network.
At current network capacity, a bigger demand for transactions would cause regular users to be priced out of the blockchain. One would have to wait forever to have a transaction included in a block, and Bitcoin would eventually only get used to settle between banks, mayor corporations, and the super-rich. The blockchain instead should be accessible to everyone, and therefore the blocksize must be increased. Often, this is followed by the argumentum ab auctoritate, that the blocksize limit was always meant to be temporary, and the fork being necessary to achieve the vision Satoshi outlined in the original whitepaper.

Greater blocksize will increase total transaction fees
Even in a bigger block, transactions are not a free resource, as they cost bandwidth, data storage, and cause slower block propagation. Already, miners are not always including all transactions. Therefore, a market for transaction fees would exist even with bigger blocks, and more transactions would cause a higher total of transaction fees.

Effective blocksize will not increase over night
The blockchain of the past six years is smaller than 30GiB. It is wrong to assume that with the introduction of a larger limit, the blocks would suddenly fill up quickly, when they haven't done so before.

Consensus will be achieved before the hardfork is initiated
Major payment providers, exchanges, and mining pools will side with the hardfork supporters, causing the opponents to find themselves to be such a small minority that they will be stuck on an irrelevant alternative chain.

Technical issues will be fixed
Slower block propagation due to bigger blocks will be mitigated by Header-first synchronization and Inverted Bloom Lookup Tables. Internet connections will speed up sufficiently in parallel to increasing traffic demands on the network. Datastorage issues will be solved by introduction of a pruned blockchain, where most "full nodes" only keep a limited number of the last blocks, and few full nodes maintain the complete blockchain.

Conclusion

Personally, I think it is the natural progression of Bitcoin to increase the blocksize, as I see potential for Bitcoin to serve a broader audience. However, I do get some points of the contrarians, especially that it is hard to make predictions about how this will all play out.

Further reading is found here (and in a million other places):

About discussion:

Tim Swanson: What is the blockchain hard fork “missile crisis?”
Reddit: Should the maximum block size be increased soon
Quora: Who will win the Bitconi blocksize war?

Pro increase:

Gavin Andresen: A Scalability Roadmap
DeathAndTaxes: Permanently keeping the 1MB (anti-spam) restriction is a great idea,… if you are a bank.

Contra increase:²

Mircea Popescu: Let's address some of the more common pseudo-arguments raised by the very stupid people that like the Gavin scamcoin proposal

¹ Does anyone have links to the discussion on the introduction of the blocksize limit? I was looking for that.
² I'm still looking for more representative contra-positions. Wading through a few threads of some forums gave me a skin rash, but hardly anything useful.


After sending/flooding transactions, how do we know that a specific transaction is on all nodes?

From a novice, what it means that if someone who isn't bitcoin savvy accepted bitcoin on the deprecated block and gave that person something of value, that person is out of luck, you just lost that item of value.
Previous answers eluded to it, but, simpletons like me look at "So what does this really mean".  It means, when you get paid in BitCoins, you are not "PAID" until that transaction appears in at least 6 blocks to that chain, since that chain could be voted invalid anytime before that 6th block is reached (It can still be called invalid after that but highly unlikely).
This means, instantaneous transactions using BitCoin are "RISK".  If I accept bitcoin at my restaurant, it is possible that the chain in which I got paid could be voted invalid, thus, I never received actual payment.  I think the time is currently 10 minutes to "confirm" a transaction is on the valid chain "6 blocks deep".
A person could gamble and spend money twice, the money doesn't actually get spent twice, but a novice person could be taken advantage if they don't understand how things work.  In short, don't give up anything of value until the chain gets at least 6 blocks deep, then your "payment" is most likely confirmed.