Requirements to accept and send SegWit transactions?

How does that work, do they look like normal addresses? Will older non-SegWit clients also be able to send txs to such addresses? Or is it a new address format, that will not be recognized by older clients?

There are two types of "segwit addresses": P2SH nested and Bech32 addresses.

P2SH nested addresses just make use of the currently existing P2SH address and output styles. Since P2SH addresses are supported by all modern Bitcoin wallets, non-segwit clients can still send to these. These look like normal 3... addresses.

Bech32 addresses are completely new. They are a new construction designed specifically for segwit. Only wallets which have been updated to support Bech32 can send to Bech32 addresses. These look like bc1...

  If I want people to be able to send SegWit transactions to me, do I have to give them a SegWit address, or can they also send SegWit txs to regular addresses?

There really isn't a "segwit transaction" per se. Rather there are segwit outputs, and these outputs are spent in a different way from other outputs. A transaction can create both Segwit and non-segwit outputs, and a transaction can spend from both segwit and non-segwit outputs. If you are a receiver and you want to use segwit, then the person sending you money must create a segwit output that you can spend. If you want to use segwit and send money to someone who does not, then you can create a transaction which spends a segwit output and creates a non-segwit output.


Must block contents be stored with the proof that they haven't been changed?

Sounds like you are describing a pruned node. As of Bitcoin Core 0.11, you can run it with the experimental -prune=N option, which only keeps the last N megabytes (min 550) worth of blocks, plus the UTXO set. In 0.11 it is only useful for some RPC commands and mining, but it disables the wallet due to being too experimental. In 0.12 the wallet function will be available in pruned mode.

All blocks and headers are still downloaded and validated fully, but the old blocks are deleted from disk occasionally.

Also, I think it is a bit incorrect to say that hashing power prevents modification of the block chain. Block chains are by means of hashing always immutable and only append-only. However, in the presence of multiple valid competing block chains, most hash power decides which one is to he accepted.


The leaked database dumps (from when MtGox was hacked after they closed down) shows 189374 records as a result for this query:

mysql> SELECT * FROM platform.User_Wallet WHERE platform.User_Wallet.Balance != 0 ORDER BY platform.User_Wallet.Balance DESC;

Notes:

That's only non-zero balances
There are many currencies (BTC, USD, JPY, PLN, AUD, GBP, ...) in there, each counting as a seperate "wallet"
We don't know how many fake accounts there are (created by MtGox themselves).
The hackers that released these documents may have messed with them.
There are for example 8467 records that have Balance "1" (Satoshi or other currency). Likely remainders of incomplete withdrawals and such. There will be many many more that have up to a couple million Satoshis (which is still just dust).

Therefore, in short, this may NOT be a good approximate answer to your exact question.


How can we look at the hidden message in the first block?

Click on the sole transaction in that block (4a5e1e4b...) and click Show scripts & coinbase.


To engage in trading on an exchange, you have to make a deposit of either fiat or Bitcoin. As the balances are then managed by the exchange until paid out, there is no counterparty risk to your trading partner: You can only submit buy and sell orders that are funded. Once your order is matched, the exchange can atomically update the balances of the two users in their database:

When Alice wants to sell one Bitcoin for two hundred dollars, and gets matched to your buy order for one Bitcoin at the same price, your USD balance gets decreased by $200 and hers increased by $200, while her BTC balance gets reduced by 1 BTC, and yours increased by one.

However, there is a counterparty risk to the exchange. The exchange may be e.g.
a) running faulty software
b) misappropriate funds
or c) go bankrupt,
resulting in failure to perform payouts. This has happened in the past, most notably in the case of MtGox. Currently, I know of reports suggesting that two more exchanges might be unable to honor their liabilities to their users.

To this end, some exchanges get themselves audited and publish proof of their balances.

It is therefore advisable to keep informed about exchanges that you entrust with your money, and not to keep money on exchanges that you are not using to trade with.

Unfortunately, I cannot serve with a neat statistic on this topic.


Security implications of removing CHECKSIG in a test

The security implication of removing a checksig operation from the encumbrance script is that the coins can be stolen while in flight by anybody, and especially by miners.  Obviously, on testnet, only someone who's bored or interested enough to grab the coins will take the time to "attack" your transactions.

There's not much sense in listing and analyzing the vulnerabilities in your method.  Testnet coins are worthless and certainly nobody will take the time to brute-force sha256, or grind through a hash table to get them.

As for checksig-less scripts in general, there are indeed bots on mainnet that listen for such transactions being relayed and try to grab any coins.  It's probably easy enough to run the same bot on testnet.

In any case, if you want to avoid this scenario altogether, you can migrate your setup to regtest.


What will happen if i change the checkpoint data from bitcoin source code and try to synchronice with blockchain?

It will think that the  databases have been corrupted and so it will attempt to redownload the entire blockchain. When it does, it will find that all of the blocks are invalid (because you changed the genesis block) and then it will just do nothing as it is unable to sync what it believes to be a valid blockchain.

  Is this what orphan block is?

No. Orphan blocks are something else entirely and unrelated.


Bitcoin 2 of 4 Multisig script with one required

Bitcoin script does not let you require a specific signature, however you could give the person that is required to have a specific signature additional keys and change it to a 4 of 6.
Manager has 3 keys.
Employee 1 has 1 key.
Employee 2 has 1 key.
Employee 3 has 1 key.
With 4 signatures required to spend the Manager only needs one employee present to sign, however the 3 employees can not produce a fully signed transaction without the Manager present as their 3 keys combined does not meet the 4 minimum required.


Address not valid when withdrawing money from Binance

Note: You cannot withdraw to a bitcoin wallet as it is an entirely different network.

You would need to install a wallet that supports the so called "Vibrate" cryptocurrency, then use that to generate an address to withdraw to. I have no idea what "Vibrate" is to be honest, the closet I could find was something called "Viberate" which seems to be an Ethereum ERC20 token.  So, if you want to withdraw those, you need an Ethereum wallet that handles tokens.  One popular wallet is MyEtherWallet.


You can try this

openssl req -new -x509 -days 365 -nodes -out cert.chain -keyout key.pem

The cert itself is one CA added to the chain from the above command.
A .chain file is just a concatenation of signed ca certs


Is Bitcoin's value the same, country to country? If not, which valuation is correct?

Things only have value if you can get stuff with it.  The value of a bitcoin is dependent on supply and demand and how much the BTC-currency exchanges are exchanging for, so it does not necessarily have the same value in a all countries.


Anyone who knows the private key will have full access and control of any coins stored at the corresponding address.

When you put a password on a wallet or login account, that password is only for unlocking that instance of the wallet (it is possible to create another instance, that is not locked by your password). Once unlocked, the wallet will use the private key to sign transactions that move the coins, etc. But without the password an attacker can not unlock the wallet if it the wallet alone is found.

However, having the private key itself means you don’t need to unlock the wallet, because you already have the key. You can import the key into just about any other wallet software, and then use that wallet instance to move the coins, etc.

There is BIP38, which allows you to password protect a private key itself, but this is different, and a less common set up.


-- dropping this in the answer secton, cause too many characters for comment section ---

certainly you can create your own blockchain, and create all your own fake nodes. But why would someone join your network? What is the value?

Bitcoin blockchain is currently managing ~19 billion US$, and must assure, not too many fake nodes "come in". In this case, the network is protected by +5000 other nodes, and many mining nodes to ensure proper functionality of the network. I recommend reading "https://bitcoin.org/en/how-it-works" or it's translations, especially the link to the mining section, and "Going down the rabbit hole". As this here is more a development oriented area, it might be better to discuss such question in a forum like "https://bitcointalk.org/index.php".
Hope this helps :-)


Secret Key value for decimal versions over 127

The reason is historical.

The 'version' byte was originally really just a version number. Satoshi probably intended to introduce more types of standard scripts to addresses. There were comments in the code about upgrading an address from one version to a new one even.

In that vision, to not restrict the options for future versions, I chose to make the private key just set the highest bit, leaving still 127 possible future versions.

Only one new version was ever introduced (P2SH), and since it is so powerful (it can encode any script indirectly), no other versions ever appeared.

So the short answer is: it does not matter at all.


I bought Bit Coins while on a Bidding site. They were bought with my Credt card. How do I trace them?

You can go back and check your credit card records for the purchase.  That should at least give you a name of a company.  Contact that company (if they still exist), and see if they can give you access (assuming you lost your credentials).  If they can, and they were storing your bitcoin for you, then you can transfer it to a wallet you control.  If you already transferred then out when you bought them, but lost the key/password/data to your wallet...then you are just out of luck.


Blockchain.info API: How to cancel callback notifications

1) No

2) your callback url must respond with the text "*ok*" without quotes and nothing else, just text. This will stop Blockchain.info from sending further notifications.


If you're paying through your mobile phone, it's most likely that your app creates and signs a transaction based on unspent inputs available to your address. This is then passed on to the receiver who posts it to the blockchain. This transaction cannot be modified, it can only be posted to the network in order to prove payment. So, from your standpoint, payment through Bluetooth, NFC, or even by sharing the transaction through a QR code is secure.

Unfortunately, as bitcoin is network based, unless you can connect to the network [through the internet] you can confirm nothing, but as the sender of the transaction, you don't really need to. You can/should just assume that the input are spent, because once that transaction is created it can be posted at any time as valid (provided that it's inputs aren't already spent).

You can still check the blockchain at any point in the future when you do have internet access to confirm that your inputs are spent. And if they are not, you can go ahead and spend them in another transaction. When the original transaction enters the blockchain after this new one, it is rejected because it's inputs have already been spent. So, it's actually in the interest of the receiver to post the blockchain and confirm payment as soon as possible. This doesn't really matter for the sender.


How do nodes contribute to security when the power comes from mining and what is the chain of transaction validation?

Miners offer up blocks to the network hoping that their offerings will be accepted. Other nodes may accept or reject such blocks. A node that accepts a block adds that block to their copy of the blockchain. Nodes that don't accept a particular block don't add it to their copy of the blockchain and don't pass on that block to anyone else. Any miner that is consistently a source of bad blocks is likely to be ignored thereafter.
Miners can't spend income from a block until a further 100 blocks have been added on top of their block. So miners have a great incentive to only offer up blocks that are acceptable to everyone.
All nodes validate blocks and the transactions in them. This consists of checking that the blocks and transactions conform to a set of common rules. These rules are often called the consensus rules. The rules protect the interests of the buyers and sellers in transactions.
Nodes will eventually be ostracized if they consistently apply different rules and attempt to pass on blocks that meet their different rules but don't meet the mainstream rules.
All nodes called "full nodes" do check hashes and perform cryptographic checks on signatures. Some nodes (Simplified Payment Verification or SPV nodes) rely on other nodes to do much of this work, but they will still perform some checking themselves.
The classic example of an illegitimate transaction is one that attempts to spend money that has already been spent in a prior transaction. A trivially illegitimate block would be one whose independently calculated hash is greater than the current target value (inverse of difficulty)


Yes. You can just stop bitcoind (using bitcoin-cli stop, or just killing it with SIGINT). Next time invoke it without -reindex, and it will continue from where it left off. If you do pass -reindex again, it will start over.


How do I know I can trust the head of the blockchain

Your node doesn't know for sure. Actually, nobody ever knows for sure that the current chain-tip will be in the chain with the most work, it just becomes increasingly likely as more time passes and additional blocks build on-top.

Once a sufficient number of blocks have been built on top of the observed block, it will be sufficiently unlikely that the observed block will end up in a stale chain-tip, and you can trust it.

Users make different judgment calls about the number of blocks they wait for: some don't wait for another block and accept at first confirmation, some wait three blocks, some require six. The extreme is likely to be the 100 block waiting period the network requires before mining rewards may be spent.

However, until proven wrong, the node will assume that he has the newest information: after all finding a block is an unlikely event, and thus will respond with information about his block when queried for the blockchain-tip.


What happens to my bitcoins if there's a permanent fork in the chain?

The question is too speculative to answer. The groups could institute whatever rules they want.

If you assume there's a group that's willing to modify the software to create a permanent fork, presumably they are doing so for some reason. And whatever that reason is, that will affect what changes they make that cause the fork.

They could decide to allow people to transact on both chains. Or they could demand that you send the Bitcoins to a Bitcoin eater in the other chain before they allowed you to move them.


How do I delete a Bitcoin full node from my hard drive?

Before you delete you Bitcoin data from your hard drive, ensure that you have backed up the wallet.dat file, or you risk losing your bitcoins in case you received them on the addresses generated by Bitcoin-Core.

Ubuntu

The most easy way to remove Bitcoin-Core from Ubuntu is by running:

sudo apt-get remove bitcoind.

When you run bitcoind, it typically (by default) creates a .bitcoin directory in the home directory of the running user unless you have explicitly specified the datadir to where the software will download the blocks and other data. If you're not sure where this path is, you could run the following command to help find it:

sudo locate .bitcoin.

After finding the path you can purge the entire directory by running the command: sudo rm -rf /path/to/.bitcoin.

Windows

Navigate to Start --> control panel --> programs and features and scroll down the list to where bitcoin core/bitcoin-qt is listed, right click and click "uninstall or change a program" and then try uninstalling it that way.

In Windows, by default the block data is stored in the directory C:\Users\your_username\AppData\Roaming\Bitcoin. If you want to delete the entire existence of Bitcoin blockchain from your machine, you can delete the entire folder.

Finally, run regedit (win + r -> regedit). In the search, enter bitcoin and delete all entries matching the list.


Why is it dangerous to hard fork the Bitcoin network?

The following assumes that one understands what happens with a soft and hard fork. See all the answers here for a good explanation.

Say a new change is implemented in the bitcoin protocol and it requires a hard fork. Full nodes are required to upgrade to the new version (otherwise there are dangers...).

  What are the dangers of a hard fork?

The real danger is that the blockchain will split in two parallel blockchains. Miners, merchants, users (via wallets and other software), etc. that did not upgrade will support/use blockchain A and miners, merchants, users, etc. that did upgrade will support/use blockchain B.

  How would people lose money due to a hard fork?

Effectively there are now two bitcoin blockchains. The bitcoins that you had before the fork will exist in both blockchains A and B (they doubled!). A simplified example would be that: You can use your bitcoins from an old wallet and buy something from a merchant that uses old nodes. Then you can use a new wallet and buy something from a merchant that uses the new nodes with the same bitcoins. This is not even doublespend since the chains are different.

However, what this also means is that the bitcoin users and community are also split. Each blockchain instead of having X nodes (the nodes before the split) that keep it secure will have X/2 nodes. Several merchants accept bitcoin but some accept version A and some version B... and so on. This is not user friendly and it will cause much confusion. Something like that will shatter trust in the bitcoin network causing its price to diminish. Fear of future hard forks (splits) will diminish trust (and price) even more. So people will lose money indirectly since the value of bitcoin will collapse (best case scenario the price will split... but it is probably going to be much much worse).

  Why is it necessary to give more than a month time to prepare for a hard fork?

Because we want to make sure that everybody is aware of the change; miners, merchants and users. We want to make sure that they do not have objections to the change and that they agree on the upgrade. In addition wallet creators and merchants might also need time to upgrade their software accordingly (depending on the upgrade changes). The delay is for both (first) social and (second) technical reasons.

Also note that if the split is, say 95% upgraded - 5% did not (or vice versa), it will not be a big problem since the bigger chain will have the overwhelming majority and the remaining will be forced to upgrade or be ignored.


Bitcoin Blockchain in the Quantum computing era

If quantum computers become viable and the approach of factorization of numbers which has been theoretically presented works, this means that Bitcoin will have to use a different way of signing transactions as through the use of quantum computers, it becomes easy (only polynomial time required) to calculate a private key from a public key.

Simply increasing the key length doesn't work. If you double the key length, a classical computer has to work twice as hard to encrypt or decrypt the message but it becomes much, much harder than twice as hard as before to crack the encryption. Signing, in this case, really is just encrypting a hash of a message. However, for a quantum computer, the problem of cracking the encryption, only becomes twice as hard. So you can't keep up with using longer and longer keys because then the increase in effort an attacker has to put in only increases as fast as the increase of effort you have to put into using the keys.

However, there are ways to approach the problem of the signatures currently in use being rendered useless by the advent of quantum computers. Namely, quantum digital signatures.

Because quantum computers aren't faster than classical computers but reduce some exponential problems to polynomial problems, and cryptographic hashes can't be broken using quantum computers, their advent won't impact the difficulty to find a new block.


Is there a logical reason to buy bitcoin for more than it costs to mine it?

Mining:
It's a lot of trouble and expensive to set up a proper rig and the return on investment can take a long time when mining. It's not as cheap or profitable to mine the coins as you make it seem.

This online calculator:

https://www.cryptocompare.com/mining/calculator/btc?HashingPower=12&HashingUnit=TH%2Fs&PowerConsumption=1300&CostPerkWh=0.15

allows you to enter electricity cost, energy consumption and hashing power of specific rigs to figure out how much you'd make. It takes into account total network hashing power, average block time etc.

For example:

An antminer S9 (currently viewed as being the best pro-sumer miner on the market) has a hashing power between 12 and 14 TH/s and consumes between 1200 and 1400 Watts of power. at an average electricity price in the US of $0.12 per kW/h (and Europe's avg price is between 12 and 18 cents) you can expect to profit just a little under $500 per month on the machine.

Those machines are sold out direct from the manufacturer but you can find them from resellers on amazon or eBay for between $5000 and $7000 depending which batch they were from. It would take you a year to make your money back on your investment, and since the nature of that playing field is that a piece of equipment's yields reduce over time it will most likely take a lot more than one year to break even from the purchase of that miner.

Most miners are pretty much the same or take even longer to pay back; feel free to play around with that calculator and input different mining rigs you find on the internet.

Renting Servers: this site, the top result in a google search,
https://www.nicehash.com/buy will rent you 50TH/s of hashing power, for 24 hours, for ~$94USD (they charge in Bitcoin). Using the calculator I linked above 50TH/s and an electricity cost of $0 would yield $2447/month worth of bitcoin or just over $81/day. So you'd be giving them $94 for $81 worth of Bitcoin.

Bottom Line: the reason people don't easily mine it for a tenth of the cost is because it's neither easy nor much cheaper to mine it.


Who pays on-chain fees for settlement transaction?

As long as we don't have BOLT1.1 and dual funded channels the fees for settling a channel are always paid by the party who funded the channel as described in BOLT 03 - Transactions:

  Base commitment transaction fees are extracted from the funder's amount; if that amount is insufficient, the entire amount of the funder's output is used.

There is one exception to the rule if the channel partner has an output that is below the dust limit this output is also added to the fees and reduces the fees that the funder of the channel hast to pay.

  Note that after the fee amount is subtracted from the to-funder output, that output may be below dust_limit_satoshis, and thus will also contribute to fees.

On a side note. A mutual close has less fees at it works by settling all pending HTLCs and then create one spend of the funding transaction.


How does a non-segwit full node ensure validation of the blockchain?

Non-segwit nodes validate blocks in the exact same way they did before. The still check the Proof of Work, they still check the inputs and outputs of a transaction, they still verify scripts, etc. Everything is validated the same way as was validated before segwit.

The only difference is that with segwit inputs, the non-segwit node does not validate the signature because it does not have access to that data nor does it know how to interpret it. The scriptSig and scriptPubKeys for segwit inputs are still validated as normal scripts and still validate to true (they were designed to always validate to true).

Segwit does not redefine anything that was already in Bitcoin. Instead it defined a new  standard output script, with that output script already being valid without segwit. So blocks and transactions that contain spends of such outputs will always see those as valid, even if the new data required for such outputs (i.e. the signatures) is invalid.


How do honest mining pools generally divide their rewards?

Mining pools use a system that is based on shares. Shares are blocks with proof of works for a different difficulty than the network difficulty. Mining pools will set the difficulty for a given miner to be something that is reasonable for it to achieve. So when that miner mines, it is looking for a block hash that meets the pool difficulty. Once it does, it submits the block. That submitted block, although likely not valid to the Bitcoin network, meets the pool difficulty and is known as a share.

So mining pools will count the shares and give weight to each share based upon the difficulty that it was mined at. In this way, the mining pool can determine how much work each miner has done on average and pay them accordingly once a block is actually found.

Blocks are found when a share meets both the pool difficulty and the network difficulty.


why is bitcoind is missing from /usr/local/bin?

If you've followed the first link, you will also need to sudo make install, this will take the relevant binary files and place them in the /usr/local/bin directory.


How can Forks and Orphan Blocks be used to attack a Blockchain?

The paper you link to includes attacks on blockchain applications as "attacks on blockchain". Personally I would restrict "attacks on blockchain" to literal attacks on the underlying blockchain rather than applications built on top. Regardless there are a number of theoretical attacks on blockchains (51 percent, selfish mining etc) but I don't think we have any evidence of them being executed on Bitcoin at least.
Selfish mining is when miners collude to withhold newly mined blocks and start mining on top of them without announcing the newly mined block to the network. It is not an attack on the blockchain per se, rather than the profitability of other honest miners. In this case honest miners may mine a block that ends up getting orphaned because they were unaware of the latest blockchain tip.
A 51 percent attack on the other hand is most definitely an attack on a blockchain. If a miner tried to execute a 51 percent attack (with 51 percent of the network hashrate) they could theoretically include a double spend in the chain with the most accumulated proof of work. In practice the attack may fail as full nodes on the network reject the chain with the double spend in a block and fork to a chain that doesn't include that block. This resource from MIT highlights some examples of attempted 51 percent attacks on blockchains other than Bitcoin.


How do I claim bitcoin from an old wallet?

From your earlier (now deleted) comment, I think this is your address: https://blockchain.info/address/176T2BxKAraEnusvuuK48RPA5yVYQRhMdc.

You need access to the original wallet with which you received the bitcoin. Which wallet did you use back in 2015 and 2016? Can you still access it? The "Request Payment" button is for sending more bitcoins to that address, not for spending the coins that are already there.


where is the specification for bitcoin block-chain mining?

Who wrote the rule book

Satoshi, whoever that is, wrote the original set of rules. They have evolved a bit over time.

  and where is it stored?

In every node that runs bitcoin software.

  Is it stored in a block chain?

No.

  Who said bitcoin could hard-fork?

Nobody. It's a consequence of the way the system works. If two nodes use different rules, it's simply a fact that they can permanently disagree on which transactions are valid.

  What if some bitcoin holders don't want a hard fork

Then they should run code with the very same rule book as those who agree with them on what the rules should be. They will then never fork from each other, but the rest of the world may follow different rules. Nobody gets to force anyone else to use rules they don't wish to use, but only people who agree on rules can interact with each other.

This is why we have Bitcoin and Bitcoin Cash. There are two groups who cannot agree on the rules the system should follow.


calling getaccount rpc method on foreign address

You can't do that. The client only keeps indexes of the balances of addresses you own. There is no ability to query the balance of arbitrary addresses.


It depends on two factors.

One is, how many unspents are your funds spread across in CoPay? Will it be a really large transaction which will need high a transaction fee? Then sending to Core might be easy, but at a financial cost.

Two is, how comfortable do you feel with exporting CoPay's priv keys, safely transferring and importing then into Core? If you are OK with it, then you save the transaction fees.


Generally speaking, the only way to distinguish incoming payments is by some combination of

sending address (usually arbitrary and not always known in advance)
amount (could be same for many people if you are selling fixed-price widgets)
receiving address (no good if you give everyone the same address to send money to)

That is one reason why best practice is to generate a new receiving address per transaction.


In a multisig wallet setup what needs to be backed up and why?

Ben Kaufman answered this on Twitter.
The main caveat in a multisig wallet is that, while you need only a threshold of devices (ie. 2 of 3, 3 of 5, etc.) to sign a transaction, losing access to even a single device could potentially prevent you from being able to spend the funds - if you don't back up properly!
The reason is that (usually) in order to make a Bitcoin transaction, it is not enough to be able to sign it, but you also need to provide the "terms for spending", that is, the Script (code) that is used to lock the coins.
That's because the full script is usually not stored directly on the blockchain, but only as a hash (a unique identifier of it). In a single key wallet, this is trivial.
The script is composed of the public key of your wallet and a few standard commands - and satisfying it requires the signature for that key, so both the script and signature can be constructed by having access to that one private key.Then on spending, you need to provide both the original script code which matches that hash, and satisfy any condition that the script may include.
With a multisig, this is not the case. The script for a multisig contains the list of public keys of all possible cosigners - which means it can be constructed only by knowing the public keys of ALL devices in the multisig, not just of the devices you are signing with.
To demonstrate, let's assume a 2 of 3 multisig. When you want to get an address of your multisig, your wallet software is taking the public keys of all 3 cosigners, lists them in a standard way inside a script, hashes it, then with this hash constructs the address.
When receiving bitcoin to that address, there is a "commitment" on the blockchain for all 3 public keys, out of which 2 signatures are needed. But the public keys themselves are not listed yet on the blockchain - you must provide them too when spending from the address.
Now assuming you have lost access to one private key (a device and its mnemonic backup), you won't be able to tell its public key anymore - so you won't be able to reconstruct the script of the address. So even though you have enough signatures, you won't be able to access funds.
The solution - which is the extra step of a multisig backup - is to also keep a backup of the list of public keys (xpubs) of all cosigners, from which you will be able to recreate the script.
Since this list of public keys does not contain signing (private) keys, there is no risk of losing funds even if an attacker manages to access it, but this would be a privacy concern since the attacker will then be able to see the balance on the multisig wallet.
That's why it is not recommended to leave this file on some cloud backup or some other insecure option.
It's recommended that you keep it with each one of the cosigners/ seed backups so that you can recover regardless of the combination of signers you eventually use.
Besides the list of public keys, it is also necessary to know the script type used (whatever native SegWit, nested SegWit, or legacy), and the threshold chosen in order to construct the multisig script. These are possible to know by guessing (brute force), but better keep it too.
The last piece which you should include is the derivation paths used for each device. Each derivation path tells your wallet how to turn each master public key, into a different individual "disposable" public key used to generate every new address.
This data of derivation paths is standardized so that all wallets should use the same derivation path by default, but it is best to keep that around too especially if you use a unique one for some reason.
This might sound like a lot of components, but to simplify usage, there’s a standard for storing and recovering such information, which is called Output Descriptors.
Just as an example of what the final backup might look like, here are a few pics of a PDF backup generated from Specter Wallet.

This contains the individual devices keys list, as well as everything in an output descriptor format (and a bit of extra data like wallet name etc.)
You could save this by simply printing the PDF, storing it on an SD card, or just keep it encrypted on a cloud backup. What you need to remember is:

You need this information to recover the wallet.
Anyone with access to this information can see your wallet history.

So to simply sum it up, the additional piece you should backup when using a multisig wallet is the output descriptor - a list of the public keys of the cosigners with some data on the wallet.
This information is possible to derive only with access to all devices in your multisig and is necessary to spend from it.
So to remove the single point of failure of losing access to one cosigner, you should keep this backup along with each of your devices.


How to completely remove Bitcoin Lightning from Raspberry Pi

I don't know which Lightning Network node your are running but since you are talking about bitcoin core and not btcd I assume you run c-lightning. There you should be able to remove everything with make uninstall


How to manually rebalance Lightning Network channels?

Lnd itself does as far as I remember not provide an api for rebalancing channels.

However there is the lndmanage repository that uses the lnd api to provide a pretty strong rebalancing tool

https://github.com/bitromortac/lndmanage

Such rebalancing will cost you routing fees as they are regular (circular) payments.

That being said it is not clear why you would want to rebalance your channels before an onion on them actually fails. There is currently the discussion about JIT routing (which rebalance just in time if a channel such should be used can't be used) and fee free rebalancing taking place on the lightning-dev Mailinglist.


I'm not sure if the term "hardware" properly describes the scope you are asking about. To reach a hashrate of 107 TH/s, you'd need at least 9-10 ASIC miners at a total purchasing price of more than $20k.

Meanwhile the following image gives an impression of what you're competing with:


What if a malicious owns more than half of the nodes in bitcoin network?

No. The 51% hack is considered one of the main ways a hacker could control the network. However, it is almost completely implausible because of the sheer amount of power that would be required to have 51%. For example, the total hash rate of the network is currently 6.09 Exahashes per second. So, if a hacker wanted to take control of the network, he would need to buy about 6.1 Exahashes per second of hash power. An antminer S9, for 3,000 dollars, gives you 14 terrahashes per second. Thus, the supposed hacker would need to buy 435,000 Antminer S9's which would cost 1.305 billion. That's not even considering the growth rate of the network and the sheer amount of space and energy required to host all of those Antminers.


Low hashrate with cgminer 3.7.2 kalroth edition @ ubuntu 13.10 x64 @ R9 290 MSI GAMING EDITION @ 16 gb ram @ core i7 860

Since you have R9 290 you likely need patched Catalyst drivers as well as patch cgminer itself as described here. If you already done so, then search reddit and experiment with different configurations. You should be getting around 840-870kH/s with your card.


Do keypool keys from an unencrypted wallet backup become unusable once I encrypt my wallet?

They don't become invalid. When you ask for a new address from the client, it will not choose any that it has already given you. This is for your privacy, because it makes it more difficult to associate those addresses with you.

In this case, we're making them as used for a different reason. To explain why, let's suppose the wallet didn't treat the previously unencrypted addresses differently.

You generate a wallet.
You read about the importance of backups, and make a backup to an external flash drive.
You read about the importance of encrypting your wallet, and do so.
For about 6 months, you use 3 new addresses every week.
You get hacked, and you have the external flash drive plugged into your computer at the time.

Your wallet would be encrypted, but that wouldn't matter, because all of the keys that hold a balance are also sitting unencrypted on your flash drive.

In theory, you could just destroy all unencrypted copies of your wallet, but that seems more difficult than generating new keys and making a new backup, no?

  If I hadn't made any new transactions using the new encrypted wallet would I still be able to restore the backup using the unencrypted wallet backup or would this cause problems?

Yes, you could.


How to setup stratum with pushpool and VARDIFF? (litecoin)

i have come back to post up all the information i can for you.

through the last few months of working with Stratum-mining i have come to some conclusions: you need to know python well to get this working on anything but bitcoin... That being said, its possible to install stratum over a current custom pushpool installation through a project I released and am working on. (Currently it is for freicoin but there are two trivial changes you can make to get my implementation to work on litecoin). There is also another implementation of stratum-mining that you can use that was last updated on Jun 6 2013 (i would suggest using this versus my code if you are installing from scratch or using MMCFE currently. my version of the code is designed to be more friendly to version 2 getblocktemplate, where as litecoin only supports getblocktemplate version 1 at this time).

In the future it may be extremely useful to diff these two implementations as they have different database schemas...

In the mean time,
Here's how to install stratum-mining-litecoion a NEW system OR a system with MMCFE

step 1) back up your database
step 2) back up your database
step 3) back up your database

From https://github.com/Neozonz/stratum-mining-litecoin/blob/master/INSTALL

"

> Installation Instructions
> =========================
>
> Step 0. Install litecoind     NOTE: Litecoind currently only supports
> getblocktemplate version 1. This code was changed to support version
> 1.    Set it up and start it!     Downloading the blockchain can take a few hours to a couple days!
>
> Step 1. Install the stratum core  git pull
> https://github.com/slush0/stratum.git     sudo easy_install stratum
> (or if using alternate python: sudo /usr/local/bin/easy_install
> stratum)
>
> Step 2. Pull a copy of the miner  git pull
> https://github.com/moopless/stratum-mining-litecoin.git
>
> Step 3. Configure the Miner   cp conf/config_sample.py conf/config.py
>   make your changes to conf/config.py     Make sure you set the values in
> BASIC SETTINGS! These are how to connect to litecoind       and where
> your money goes!
>
> Step 4. Run the pool  twistd -ny launcher.tac -l -    OR - using
> alternate python  /usr/local/bin/twistd -ny launcher.tac -l -
>
> You can now set the URL on your stratum proxy (or miner that supports
> stratum) to: http://YOURHOSTNAME:3333
>
> Database Setup
> ========================= Table Creation: Tables are auto-created if they don't exist (I will be adding a schema file later)
>
> None: Well, this doesn't do anything, so there is nothing to set up
>
> Sqlite: THIS IS THE DEFAULT! Just set the file path in the config file
> (or keep the default.) Support for sqlite3 is built into recent python
> versions. A couple notes for Sqlite:
>   - Sqlite and threading/concurancy just doesn't work right for that reason it is disabled.
>   - Since threading is disabled, The server will "pause" when archiving happens, this will affect         your miners. However this will not happen
> often (24 hours after finding a share)
>
> Postgresql:
> 1. Set up your parameters in the config file.
> 2. Install the postgresql libraries in your os:   Redhat and the like:        yum install postgresql-libs postgresql-devel    Ubuntu and the like:
>       apt-get install postgresql postgresql-devel
> 3. Install the python bindings    easy_install psycopg2
>
> Mysql:
> 1. Set up your parameters in the config file.
> 2. Install the mysql libraries in your os:    Redhat and the like:        yum install mysql mysql-devel   Ubuntu and the like:        apt-get install
> mysql mysql-devel
> 3. Install the python bindings    easy_install mysql-python
> 4. Create a database and user.
>
> Problems????
> =========================
>
> Is your firewall off? Is litecoin running?
>
> TODO: are there other problems?

"

If you are already using pushpool and a custom frontend and don't want to write over your system, i have a working (but a bit buggy with MBPM due to the nature of my project) "install over" version of stratum mining for freicoin available here https://bitbucket.org/joeswhite/joes-stratum-mining-freicoin/src/8eec8a0b11c6?at=master

this is how to install my version (DO NOT INSTALL THIS VERSION UNLESS YOU HAVE EXPERIENCE CODING!), there is an added step for the litecoin implementation but it is not yet tested by me.

"

> stratum-mining Basic implementation of bitcoin mining pool using
> Stratum mining protocol. This fork includes a database implementation
> for: None Sqlite Mysql Postgresql Basic worker stats are provided (and
> updated) See the INSTALL file for install instructions. For more info
> on Stratum: http://mining.bitcoin.cz/stratum-mining. Original version
> by Slush Updated version by GeneralFault (Tips Welcome:
> 15Zk7DoFYJ7hESpZzmix1WLkomTMGW81c2 ) This version by Joe White
> http://pool.cr.rs (freicoin mining pool) Joe's Stratum Mining Freicoin
> Implementation of generalfault's
> https://github.com/generalfault/stratum-mining that works with Mark
> Friedenbach's https://github.com/freicoin/stratum-mining This
> installation can be put directly over top of your current pushpoold
> Known bugs: Does not handle subscriptions properly upon connection,
> but properly pushes block template and everything submits without
> issue To do: add Joe's Pool front end in to implementation
> (simplebtc's implementation heavily modified) add firewalls, security
> services, add google authenticator, add other things like tripwire.
> how to: Easy: download vmware image go to town make sure to set up any
> and all firewalls, security measures, and other information. manual:
> first download freicoin from freico.in/downloads install freicoin edit
> your freicoin.conf file change the rpc port for security (i like to
> mix it up on each server i use) nano .freicoin/freicoin.conf something
> like this works (freicoin.conf file): server=1
> rpcuser=changethisusername rpcpassword=changethispassword rpcport=4252
> rpcallowip=127.0.0.1 test to make sure freicoind works once you are
> sure of that, then get the git package git clone make the stratum log
> directories mkdir /stratum mkdir /stratum/log/ touch
> /stratum/log/stratum.log recurse in to the directory and edit
> conf/config.py MAKE SURE TO READ AND CONFIGURE ALL SETTINGS!!!! I HAVE
> DISABLED PLUG AND PLAY FOR YOUR SAFETY/SECURITY nano conf/config.py
> ALWAYS BACK UP BEFORE STARTING ANYTHING!!! YOUR DATABASE COULD GET
> SCREWED! I CAN NOT BE HELD LIABLE FOR ANYTHING, ESP THAT! import the
> database if you are starting from scratch (it is not standard and is
> not optimized, you could opt to make your own database and edit
> DB_Mysql.py (or corresponding database) and edit anything that is a
> sql execution (anything that has "select * from, or any other sql
> statements can be easily updated without changing most or anythign on
> the server side schema.sql <- THIS IS THE SCHEMA FOR THIS
> IMPLEMENTATION OF joe's THIS SCHEMA IS NOT OPTIMIZED AT ALL! ALWAYS
> BACK UP BEFORE STARTING ANYTHING!!! YOUR DATABASE COULD GET SCREWED! I
> CAN NOT BE HELD LIABLE FOR ANYTHING, ESP THAT! start a new screen so
> you don't log out and stratum crashes (this is helpful for logging
> too) screen

"

*litecoin specific step
At this point you need to go back and write over (at very least) the halfnode.py block_template.py and coinbasetx.py files with the files provided in stratum-mining-litecoion. most likely you will need to write over all of them. (This is the untested part i was talking about).

"

> ./startjoes.sh it should load up and work, you will see one error on
> submission at this time it is okay this error does not affect any pool
> performance, it is tested working. please update this as there are
> many probable errors. I have included the sql architecture for this
> implementation as it is not standard and can plug-and-play over an
> existing pushpool implementation ALWAYS BACK UP BEFORE STARTING
> ANYTHING!!! YOUR DATABASE COULD GET SCREWED! I CAN NOT BE HELD LIABLE
> FOR ANYTHING, ESP THAT!

"

I am trying to get an implementation up today or tomorrow and can report back any changes i need to make then.

Please let me know if this was a satisfactory answer, if not. I will update this until it is. Thanks for not bashing me ;)


Is bitcoin running over a structured or unstructured overlay?

Bitcoin uses an unstructured network.

The primary reason a network might opt for a structured system is to allow systemic retrieval of information. This is not necessary in Bitcoin, since each node maintains the same information.

Bitcoin does not, however, employ the flooding technique at the start. It uses a set of DNS seeds to get an initial node list, and connects to nodes from that list, before asking them for additional peers. This prevents the bandwidth issues associated with flooding, while maintaining a reasonably decentralized discovery method.

Note that even if all the DNS seeds ceased to exist, new nodes could connect by connecting to any existing node, and then asking for a peer list, and cascading down the peers' peers. In the based, IRC channels were also used for node IP discovery, which again shows how the system can remain functional without the DNS seeds.


I guess every time a getblocks message is needed because our client
  needs to check if the blockchain we have is the latest.

Thats right. You can also compare the blockheight from the version message, but you will still need to check if you are not on a fork.

  So the getaddr messages follow the getblocks message

I would say that up to you. If you connect to a new peer, and the chains are different, you dont know directly if he is on the wrong chain or you are. So it would be good to know some other peers to ask as well.
I think its better when you first call the getaddr message, because thats a one time command you run. If you ask for blocks, seeing you dont got all, you will start calling the getdata message and so on. Than your getaddr message would continuous be delayed.

  And if the client had connected in the past will he need any getaddr
  messages or his database of peers would be enough?

The stored peers should be enough. Remember, once a node is connected to a peer node, they share new peers by exchanging addr messages whenever a new peer is discovered. So you also get new peers without asking for them.
You will just have one problem, those peers which have disconnected. So its always a good idea to ask again for peers, just to be up to date.


Where can I get tick by tick historical BTC volume data?

You might want to try http://www.cryptodatasets.com/ It has free raw data and sampled data from Bitfinex and HitBtc (currently).

P.S. it's my website


How do you calculate when 98% of Bitcoin will be mined?

I have created this Google sheet to calculate various metrics of the reward schedule. The numerical maximum of bitcoins that could be created is 20,999,949.9769 BTC.
0.98 × max = 20,579,950.977362

So, the network will have issued more than 98% of all bitcoins once there are more than 20,579,950.977362 BTC. Looking at the table I linked above, we see that at the end of the fifth epoch, 20,343,700 BTC will have been mined, and 20,671,825 BTC at the end of the sixth. This means that 98% of all bitcoin will be issued some time in the sixth reward epoch, i.e. the time between the fifth and sixth halving. Since the block subsidy is constant for the whole epoch, we can calculate how much will need to be issued in the sixth epoch to reach 98%:
98%×max - supply_after_5th_halving = amount_to_issue_in_6th_epoch

To reach 98%, 236,250.977362 BTC need to be mined in the sixth epoch.
The block subsidy is 1.5625 BTC per block in the sixth epoch.
236,250.977362 ÷ 1.5625 = 151,200.63

I calculate that 98% of all bitcoins will have been issued with the 151,201st block in the sixth epoch. Since the genesis block was at height 0, and each epoch has 210,000 blocks, the first block of the second epoch was 210,000. Likewise, the first block of the sixth epoch is 1,050,000 which makes the 151,201st block occur at height 1,201,200. Since the fifth halving is projected to happen in 2028 and the sixth halving in 2032, and 151,201 is slightly less than 3/4 of 210,000, the network should have issued 98% of all bitcoins in 2030 or 2031.


Why didn't the difficulty adjust for the first 30,240 blocks?

Because blocks were not being mined in less than 10 minutes on average during this time (so the difficulty would only decrease and not increase), and the difficulty cannot go lower than 1.


Bitcoin core wallet - got 0 balance after transaction

The second output is most likely change being returned to your wallet. Just like when you use a $5 banknote to buy a $1 item. You get $4 back in change. You don't try to tear off 1/5th of the $5 banknote.

Unspent Transaction outputs (UTXOs) can't be half spent, you spend the whole UTXO and get change back.


I had bitcoin via Changetip but it closed and I transferred coin to a wallet which I don't remember.

You'll need to remember what wallet you used to clear out your change tip account. Without that wallet, you'll be unable to recover/spend those bitcoins. Try searching your email, browsing history, etc, for clues as to what wallet you used. Best of luck.


Why is GDAX charging maker's fee when using API?

There is no maker fee using API, but when place new order, the default parameter for "post_only" is false, which means it is possible set a price to become a taker, hence GDAX will make sure you have enough funds to cover the fees.

Set post_only to true then GDAX will allow you to spend your entire account without reserves for fees.


Yes it is possible, though I highly doubt that you would be able to invest in a coinbase round without being an accredited investor with lots of experience in the bitcoin space. That's not because of legal requirements, it's just where they're at in their business. As a general rule though, anyone can invest in a startup if they're able to convince the existing controlling shareholders to allow it.


How to make a payment processor like Bitpay?

Can you clarify whether you just need the ability to handle bitcoin-only transactions, or does your service need to be able to trade fiat currencies such as USD or EURO for bitcoins? If so, then you will need to invest in lawyers and find yourself a bank that is willing to extend you a loan, or supply your own funds to get it up and running.

If you're only needing to deal with bitcoins transactions, then I would suggest you learn about how blocks and transactions work at a low level. This is a good site for learning the nitty-gritty of how the blockchain stores data

http://codesuppository.blogspot.com/2014/01/how-to-parse-bitcoin-blockchain.html

Beyond that, understand how to set up a bitcoind server, and send JSON-RPC commands to it using the API explain here

https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list

Once you know how these commands work, you'll be able to build software that will accept payments. Again, if you need to get fiat currencies involved that's you'll have to deal with legal/regulatory concerns, but it is possible.


Increase a transaction fee in bitcoin core

The bumpfee RPC command takes a "totalFee" argument. When passed, this is the total fee that will be used for the replacing transaction.


Is it possible to copy transactions between Bitcoin's forks blockchain?

Yes, some people call this a 'Replay Attack'. But it's not literally an attack, but the desired outcome. If a fork don't want this to happen it can change the rules to prevent it.

You can also avoid it but using inputs mined in BTC after the fork, if your wallet app allows this kind of selection.


Bitcoin - Technical difference between P2PKH and P2SH address generation?

P2PKH, P2SH, and Segwit are all different address types. Segwit and P2SH addresses are not the same.

P2PKH and P2SH addresses are generated in a similar way. P2PKH takes the hash160 of a public key (RIPMED160 of the SHA256 of the public key), appends the version byte of 0x00 to the hash160, and Base58 Check encodes it.

P2SH addresses are the Base58 Check encoding of the hash160 of a script (known as the redeemScript). It uses a version byte of 0x05 instead. The rest of the encoding is the same, just Base58 Check encoding.

For Segwit addresses, there are multiple types. There are native segwit addresses which follow the Bech32 standard. There are also P2SH wrapped segwit addresses.

For a P2WPKH (pay to witness pubkey hash) wrapped in a P2SH address, the redeemScript is 0x0014 <hash 160 of the pubkey>. That redeemScript is hashed  and encoded in the typical P2SH way.

For a P2WSH (pay to witness script hash) wrapped in a P2SH address, the witnessScript (redeemScript but for segwit addresses) is first hashed with SHA256. Then the P2SH redeemScript is 0x0020 <SHA256 of witnessScript>. The hash160 of this redeemScript is then encoded in the typical P2SH way.

As for your code, you are appending 0x04 to your public key which is simply incorrect. The 0x04 is not part of the address encoding, it is part of the public key encoding itself. Your public key generator should already be doing this for you. Note that if the public key is compressed that the prefix byte will be either 0x02 or 0x03 (depends on the Y value of the public key) instead of 0x04 which is for uncompressed public keys.

[Technical difference - Example solution]

`

    def hash160(self, v):
        r = hashlib.new('ripemd160')
        r.update(hashlib.sha256(v).digest())
        return r

    def doublehash256(self, v):
        return hashlib.sha256(hashlib.sha256(v).digest())

    def ecdsaSECP256k1(self, digest):
        # SECP256k1 - Bitcoin elliptic curve
        sk = ecdsa.SigningKey.from_string(digest, curve=ecdsa.SECP256k1)
        return sk.get_verifying_key()

   def publicaddress1(self):

        prefix_a = b'\x04'
        prefix_b = b'\x00'

        digest = self.privkeyhex.digest()

        p = prefix_a + self.ecdsaSECP256k1(digest).to_string() # 1 + 32 bytes + 32 bytes
        self.pubkey = str(binascii.hexlify(p).decode('utf-8'))

        hash160 = self.hash160(p)

        m = prefix_b + hash160.digest()
        checksum = self.doublehash256(m).digest()[:4]

        self.pubaddr1 = base58.b58encode(m + checksum)

    def publicaddress3(self):

        prefix_even = b'\x02'
        prefix_odd = b'\x03'
        prefix_a = prefix_odd
        prefix_b = b'\x05'
        prefix_redeem = b'\x00\x14'

        digest = self.privkeyhex.digest()

        ecdsa_digest = self.ecdsaSECP256k1(digest).to_string()

        x_coord = ecdsa_digest[:int(len(ecdsa_digest)/2)]
        y_coord = ecdsa_digest[int(len(ecdsa_digest)/2):]

        if (int(binascii.hexlify(y_coord),16) % 2 == 0): prefix_a = prefix_even

        p = prefix_a + x_coord

        self.pubkeycompressed = str(binascii.hexlify(p).decode('utf-8'))

        redeem_script = self.hash160(prefix_redeem + self.hash160(p).digest()).digest() # 20 bytes

        m = prefix_b + redeem_script
        checksum = self.doublehash256(m).digest()[:4]

        self.pubaddr3 = base58.b58encode(m + checksum)`


The seed derivation works by increasing a "nonce" and deriving an address from that. So, by example, if we pretend that we have 1234 as our seed, then we could increase that seed by 1 for each address derivation. If we use a simple sha256 hash of that as our private key, then we get the following addresses:

NonceFinal SeedAddress
    0      12341B3PHXB6g5YGLvzTkxrrPEdLbpvfEoC5Qi
    1      12351NxaF9cYPL53fNTHMN6wtmq1w8bmHEe3gp
    2      12361DPF9wFiuFowUK4NwJdbd2W9L59bPPnWNM
    3      123713ehhpMndUoh5E4QcHJ7QSWwuKC7ySpxrL
    4      123817CF5qesU9KXBHAsa9tEz1126kqSDy56tC
    5      12391MfTGTiszztzzjzKajvS1Wc3TznqpfyPh7
    6      124016t3QqxUVssdTAYUibdY8K4aCFYsP6pUWE

This is obviously oversimplified, and not the derivation that is used in most BIP32 implementations. As to how they are restored, you simply keep deriving addresses until you hit a bunch in a row that are unused. This is called a lookup gap, and is normally configurable.


How long does it take to receive bitcoins?

You should check the following:

Are you sure you entered the right address to receive the Bitcoins?

If the address is not correct, the coins are lost

Did your Bitcoin client download all the blocks in the chain? (>150000)

If not, you need to let it run for awhile, until it downloads all the blocks, making sure that you have a couple connections and the block number is slowly increasing in your client application


How can I convert a SHA256 hash into a Bitcoin base58 private key?

What you are requesting is described as computing the Wallet Import Format for that private key:

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

Using your example:

1.) Take a private key (Below is the HEX representation of binary value)

  7542FB6685F9FD8F37D56FAF62F0BB4563684A51539E4B26F0840DB361E0027C

2.) Add a 0x80 byte in front of it

  807542FB6685F9FD8F37D56FAF62F0BB4563684A51539E4B26F0840DB361E0027C

3.) Perform SHA-256 hash on the extended key

$ echo -n '807542FB6685F9FD8F37D56FAF62F0BB4563684A51539E4B26F0840DB361E0027C' | xxd -r -p | sha256sum -b

  7DE4708EB23AB611371BB778FC0C8BDE80394AB2D8704D7129FB5771E2F1730D

4.) Perform SHA-256 hash on result of SHA-256 hash

$ echo -n '7DE4708EB23AB611371BB778FC0C8BDE80394AB2D8704D7129FB5771E2F1730D' | xxd -r -p | sha256sum -b

  CD5C4A8E03DFBB0E3AA021C2D74A9EAA43CE4C9CB1B20FC88729A7A5834141CA

5.) Take the first 4 bytes of the second SHA-256 hash, this is the checksum

  CD5C4A8E

6.) Add the 4 checksum bytes from point 5 at the end of the extended key from point 2

  807542FB6685F9FD8F37D56FAF62F0BB4563684A51539E4B26F0840DB361E0027CCD5C4A8E

7.) Convert the result from a byte string into Base58 to get it into the Base58Check format. This is also known as the Wallet Import Format

(Converted from point 6 to base58 using https://bitcointools.appspot.com, or using encodeBase58 from https://github.com/grondilu/bitcoin-bash-tools)

  5JhvsapkHeHjy2FiUQYwXh1d74evuMd3rGcKGnifCdFR5G8e6nH


How do bitcoin clients update after downtime?

Peers of the node will tell the node the height of their longest blockchain, and if this is greater than what the node currently has stored, it will request the missing blocks from that node (to validate and store them). Also, if a node is on the network and receives a new block, it will look at the hash of its parent and decide if it has the parent already or not. If it doesn't have the parent, it will ask its peers for it. That way it will eventually download all the blocks it is missing and be up to date again

The node will keep track of how long each fork of the blockchain is, and will use the longest one it finds which it considers valid. If a long fork appears which the node thinks is not valid, it will show a warning that either the node is out of date or the peers are.


That wouldn't be a cold wallet. A cold wallet is one where the private keys aren't stored on an Internet-connected device, even in encrypted form.
If you just want to check your balance, you should be able to export your addresses, and import them as a watch-only wallet, then keep the private key file (even encrypted) off of your computer. Also, 10+ BTC is far past the point at which I would just consider purchasing a hardware wallet.


How to get block height, if I have only block header?

It looks like this function from validation.h does the job:

CBlockIndex* LookupBlockIndex(const uint256& hash)


The problem might be, that the JSON data does not contain line breaks. I was facing the same issue. My 'subscribe' call had no effect until I added line breaks to the JSON data. I haven't even gotten an error message back from the API.

You could use JSON library for Java which will handle the correct formatting for you.

Please note, there are some existing Libraries for Bitfinex and Java. You don't need to implement the API calls on your own.

https://github.com/timmolter/XChange (this one uses the REST API)
https://github.com/jnidzwetzki/bitfinex-v2-wss-api-java (this one uses the Websocket API)


If I am on a fork, can the reindex parameter fix this?

No, it would not. --reindex only handles the data that is stored on disk. Blocks are stored in the order that they are received, which is what brought you to your current view of the blockchain. So all that would happen is that you end up at that same state.

Switching to another blockchain fork requires your node to be aware of it, so you need to have received those blocks from another node and they will be on your disk. If that chain is truly valid and has more work, then your node will have switched to it without a reindex.


Compressing a more-or-less random number is futile. Your best option is simply to use a more compact encoding. Base64 is better than Hex but there exists may other encodings that prform better
Wikipedia lists many and ranks them in order of efficiency
Encoding            Data type                    Efficiency
yEnc                Arbitrary, mostly non-text   ~98%
Ascii85             Arbitrary                     80%
Base85 (RFC 1924)   Arbitrary                     80%
Base64              Arbitrary                     75%
...

You can obviously do better if you use 8-bits (e.g. Unicode printable code points that have single byte encodings in UTF-8) but since SMS uses a 7-bit character set (so far as I know) you won't do much better


I don't think anyone can predict anything, especially that it's estimated to happen somewhere in 2140 ;)

But I'll share my take on it.

Please note that the number of BTC rewarded will he halved few times until then: https://docs.google.com/spreadsheets/u/1/d/12tR_9WrY0Hj4AQLoJYj9EDBzfA38XIVLQSOOOVePNm0/pubhtml?gid=0&single=true

So the proportion of BTC reward to transaction fees will be less and less - and the network will adjust.

Also - what is important - that this is self-regulating. If the reward was to disappear, some miners would leave the network (because of the cost bigger than transaction fees earnings). But then the difficulty would decrease, and mining cost to profit should more or less equalize.

So, unless bitcoin network is abandoned for some other reason*, the disappearing of block reward should not have a significant effect on the network itself.

BTC is like every other money - if people believe it's money, then it's money. Same with Bitcoin - doesn't matter if mining has any extra bonus or not.

(*) the biggest challenge to bitcoin seems to be the block size, which limits the network throughput. If you wanna read more thoughts on that - check my other answer here https://ethereum.stackexchange.com/questions/39477/why-is-there-a-possibility-to-increase-block-gas-limit/39479#39479


Is there a bitcoin source, fork available that does not include a GUI?

Yes. If you compile the bitcoin client using the following commands, it will not build the GUI components:

./autogen.sh
./configure --without-gui
make


How often do miners update their block transaction list?

Welcome to the site!
It depends on the protocol being used.
Some protocols have the pool dictate how often the list of transactions is updated, and others have it defined by the mining client.
Stratum
In Stratum, the pool sends the miner a new merkle branch when it sees a new block or when a certain amount of time has passed. By default, it updates the list of transactions every 60 seconds.
Of course, this is only a default; a pool operator can change this.
GBT
In getblocktemplate with longpoll, the pool sends new work on block change, or after 60 seconds. (For bitcoind, at least.)
// Wait to respond until either the best block changes, OR a minute has passed and there are more transactions
...
checktxtime = boost::get_system_time() + boost::posix_time::minutes(1);

(Source)
In getblocktemplate without longpoll, the miner looks for new work every so often. 'Every so often' is miner-defined.
cgminer does it every 60 seconds:
static void gen_gbt_work(struct pool *pool, struct work *work)
...
if (now.tv_sec - pool->tv_lastwork.tv_sec > 60)

(Source)
bfgminer is user-configurable, but defaults to 60 seconds:
--scan-time <arg>   Upper bound on time spent scanning current work, in seconds (default: 60)

(Source)
Conclusion
Changing work every after the network finds a new block and every 60 seconds is by far the most common way of doing things.


Which block explorer indexes the keys used in mutisig scripts?

You must not see the address in the blockchain as a receiving address. It is a P2SH tx, which means, that the spending condition is sha256’d. This is the type 3address above. The 1-of-1 multisig condition inside defines, that anyone who has the private key to the “1xW3APN...” address can spend this tx, which happened on 2014-07-28 to the target address “1UxOYSY...”
I highly recommend reading Andreas’ book mastering bitcoin (online available), which explains in nice detail the reasons and insights of those multisig adddresses.

Blockexplorer blockchain.info obviously doesn’t show the decoded script, cause it is not an address used to receive funds.


Bitcoin Script Execution - Must end with just `true`?

Quoting Bitcoin wiki:

  A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero).

From the source code:

if (CastToBool(stack.back()) == false)
    return false;

(In case you don't know what vector.back() does, it returns the last item.)


Public Addresses: '3' vs '1' in front [Bitcoin]

A Bitcoin address prefix is a function of the locking script type for a particular transaction output.

Older Bitcoin Pay-to-Public Key Hash (P2PKH) scripts are associated with addresses that start with the number 1, resulting from a one byte version prefix prior to base58check-encoding being set to 0x00.

Newer Pay-to-Script Hash (P2SH) transactions start with the number 3, resulting from a one byte version prefix prior to base58check-encoding being set to 0x05.

Examples of P2SH are singe single P2SH signature addresses, multisig addresses, and nested P2SH(P2WPKH) that resulted from segwit to maintain backward compatibility with older wallets that are not explicitly segwit-enabled to wallets that are segwit-enabed. Such addresses conform to the BIP 49 hierarchical deterministic scheme.


Blockchain gets stucked if no blocks are mined

In my ignorance I'm going to assume it is normal: how do I fix it without having to delete everything and making a new chain?

You can just comment out or remove the check in getblocktemplate so it won't error there.

You should also be able to bypass this by setting your computer's clock to around the time of the most recent block before you start the software. Once it has started, you can bring your computer's clock back to real time and then mine a block.


If the sender address is known is it possible to find the recipient address?

The person you gave your address to wouldn't know if the address you subsequently sent the funds to was actually your cold storage or a merchant, or friend, etc. However if you did business with this person again in the future, and he sees that you again sent it to the same address you sent it to before, then he could assume it might be your address.

With that said, there are BIP32 wallets that allow you to only store one extended public/private key pair that will allow to restore the millions of private keys and address that you may ever generate. This way you wouldn't have to keep all funds in a single address, instead just a single extended BIP32 key chain.


Acting as a passive node rather than an active one using bitcoind

What you are asking for is not possible with an unmodified version of bitcoind. So I will interpret your question as why not and how to achieve something similar.

Having bitcoin nodes that do not relay transactions is a danger to bitcoin: If nodes start behaving that way, not only do we move a tiny step further towards risking that transactions are stuck because someone sending a transaction does not get them forwarded at all, but more importantly, mining exploits like the one described in the preprint Majority is not enough: Bitcoin Mining is Vulnerable move from the rather theoretical to the practical. In fact, someone trying to implement this exploit might ask pretty much the same question as you do!

So what stops you from just doing it anyways, with a modified version of bitcoind? Nothing, really, except that it seems a bit self-defeating. Consider that as soon as others start perceiving it as a sufficient nuissance (and they should, for reasons of fairness and security!), we'll come up with some modification that will require you to forward at least some transactions or not get transactions forwarded yourself. Or get stuck with only similarly selfish nodes to connect to. That'll be the exact opposite of what you want to achieve for verifying transactions. Just consider that eventually you may only see those transactions more likely to not get propagated all the way to the mining pools!

So what options do you have to limit bandwidth (I doubt you can save much CPU time, anyways)? Here are your options:

You already know the most radical answer: Not running your own copy of bitcoind, and instead use the public APIs of blockchain.info and blockexplorer.com (or some commercial solution). I presume you are not happy with relying on free external services, but considering that there is redundancy (to either deal with individual downtime or to get more than one confirmation). So this super-low bandwidth approach (at least for few transactions to actively monitor) may not be quite as bad as it must sound at first.
Limit the number of nodes your bitcoind connects to. This, unfortunately, is a double-edged sword. It simultaneously limits the data you will send out (fewer peers!) and the data you receive. Hence you have a greater chance of being late to see a transaction, if for whatever reason it did not reach the very few (one?) other node you connected to, or because few peers mean you are at an elevated risk of simultaneously lose connection to all of them, being cut off from the bitcoin network briefly.
Modify your client in a sensible way. Maybe you can live with relaying new transactions, but throttling bulk downloads of the entire blockchain? This could potentially have a huge impact on your outgoing (and total) bandwidth, whilst offering the potential for very sensible overall behavior. Consider that it could even make sense for the mainline bitcoind if alternative means of bulk download of the blockchain could be implemented---and as long as we find mirrors for them, this should be doable. In fact, by putting a "blockchain mirror" part of your site behind a free cloudflare account to serve static content at zero cost, you could do it!

May I suggest that option 3 could be the way to go? If the necessary modifications to bitcoind are a problem for you, I could help (or even do it all), although I am sorry to say I probably couldn't do it for free.


How can I create smaller transactions? Can a vanity address make things smaller?

Take a look at the specification for transaction messages, particularly the sample transaction: https://en.bitcoin.it/wiki/Protocol_specification#tx

The best way to minimize transaction size is to minimize the number of inputs. Avoid accumulating "dust" balances of very tiny amounts. This is why mining pools have minimum payouts.

Vanity addresses are still the full 20 bytes. Even if you use a firstbits address, you have to look up the full address before using it.

[Moved the answer from the comment below to here:

You don't get a transaction size saving from using firstbits, because it is not legal in the protocol and you will have to use the full address anyway.]


Accept bitcoin easily without strict terms of services?

I wrote a webshop app using armory daemon. It can generate bitcoin addresses on the fly and not put any funds at risk since it's using a watch-only wallet:

https://github.com/goatpig/BitcoinArmory/tree/master/webshop

If you're not afraid of a little code, this should work without having any dependency on external services.


Do all weeks of blocks take the same time to process?

It's the number of transactions that counts. The progress bar in recent versions of the reference client (0.8.2 and higher) uses an estimation of this, so it represents real time better.

Also, after the last checkpoint (block 250000, as of 0.8.5), signature checking is enabled, which requires significantly more CPU to validate.


error code: -26 error message: 16: mandatory-script-verify-flag-failed (Signature is found in scriptCode)

Even though this question is a bit old by now, it might be useful to add a couple of things for future readers who might encounter the same Signature is found in scriptCode error.

First, the error appears when the policy change introduced in commit 9dabfe49c0 is triggered.  Specifically, the error will fire when FindAndDelete() detects the signature being passed to a CHECK(MULTI)SIG(VERIFY) operation to exist in the scriptCode itself.
This will never (actually, with neglible probability) happen when a simple p2pkh script is being redeemed.

Secondly, the spending transaction and signature in the original question is in fact valid :

printf '%s\n' 01000000018df8ae6050992976497b63349c281bd05666842a6a82d6d8b26dc51812d58201000000006B483045022100c4befe583a3bc22eeaf1516c6d26fb3e1240bdfdf25db266494d82c77ccb36100220108ad79c4a34115eec23f5b0202d492dd88ec637df17a1982d4a63382e457599012102a018e21c743a4b67dcf38f9b693e807b1fbb833dfe705aa513abbf177b04adc2ffffffff01c0a6b9290100000017a91450628702abb40cc5fee219b9c834f4126c4198848700000000 '[{"txid":"0182D51218C56DB2D8D6826A2A846656D01B289C34637B497629995060AEF88D","vout":0,"scriptPubKey":"76A914E08E0B7AF54A0A5B4CA39ECC5430AB2730ECC2A188AC"}]' | regtest-cli -stdin signrawtransactionwithwallet
{
  "hex": "01000000018df8ae6050992976497b63349c281bd05666842a6a82d6d8b26dc51812d58201000000006b483045022100c4befe583a3bc22eeaf1516c6d26fb3e1240bdfdf25db266494d82c77ccb36100220108ad79c4a34115eec23f5b0202d492dd88ec637df17a1982d4a63382e457599012102a018e21c743a4b67dcf38f9b693e807b1fbb833dfe705aa513abbf177b04adc2ffffffff01c0a6b9290100000017a91450628702abb40cc5fee219b9c834f4126c4198848700000000",
  "complete": true
}


What is more effective than ASIC mining?

Well, the ASICs machines would probably be more and more refined over the years (like processors), they can get bigger and so forth. So that will probably be the progress for a long while.

Asides that, we have the quantum computers that might be the next big leap forward for all fields of computer science, but for now they can only do really small calculations (3x5=15... on 5 atoms, or something like that). However, there is no telling if and when quantum computers might become viable enough to do anything Bitcoin-related with them, or even whether they might be used to destroy Bitcoin's algorithms altogether.


Why can't my bitcoin-qt sync with network?

Please have a look at the debug window. Does it show peers? In addition, look at the debug.log file, it might show specific problem information.


This is list of many repeated random (ephemeral) keys used in bitcoin: https://dev.to/maelvls/why-is-go111module-everywhere-and-everything-about-go-modules-24k

AFAIK ever since around 2015, nearly all bitcoin wallets use RFC6979 (https://tools.ietf.org/html/rfc6979) which is a deterministic algorithm to get the ephemeral key instead of using an RNG so I highly doubt you'll find any recent ones (after around 2015)


Little endian.

See, for example, the script_PushData unit test in the source tree that pushes one 0x5a byte onto the stack 4 different ways:

// Check that PUSHDATA1, PUSHDATA2, and PUSHDATA4 create the same value on
// the stack as the 1-75 opcodes do.
static const unsigned char direct[] = { 1, 0x5a };
static const unsigned char pushdata1[] = { OP_PUSHDATA1, 1, 0x5a };
static const unsigned char pushdata2[] = { OP_PUSHDATA2, 1, 0, 0x5a };
static const unsigned char pushdata4[] = { OP_PUSHDATA4, 1, 0, 0, 0, 0x5a };


Why does this transaction use the same address for multiple inputs?

It is hard to guess on "intention" of the sender. But let's say I collected many small payments (some Satoshis) in my system. Similiar like many small pennies or cents in a FIAT wallet. Then I have for each payment a UTXO. Now I want to transfer all these little payments (or pennies and cents). The wallet has to collect all UTXOs from that address, and create one output for it. This makes then appear many small amounts from the originating address.

Further detail: I had collected many small amounts at the beginning via  bitcoin faucets, then had many, many small amounts in my wallet, and then transferred it. E.g.: https://blockchain.info/de/tx/c9908124e59a2794f3807b366be7d235ff7654251adcdf396e209236341b3c32


bitcoin-cli createrawtransaction and purpose of "scriptPubKey"?

Currently, the create raw transaction method only uses the txid and vout parameters from that argument. You can view the relevant part of the source here.
For all practical purposes, you could pass in 00 for the scriptPubKey and still get the same result.


Fee is not very high (considering the period) but it's a bit strange. After 72 h many miners drop transactions from their mempools. You may try to contact Blockchain, here's the ticket page link:

https://support.blockchain.com/hc/en-us/requests/new

The fee is chosen automatically by Blockchain, so you can underline it's not your fault.

But for the future, remember you can choose the fee you want selecting Advanced:

Here you can find hints on the best value:

https://bitcoinfees.21.co/

And I suggest you to google these terms, so that you can make suggestions to the Blockchain's staff and look cool, and, most important, you'll learn a lot (as I just did in the past hour)

Opt-in Replace-by-fee
Full replace by fee
Child Pays for Parent

These are all methods to unblock a transaction by rising the fee, but only Blockchain can do something.

Last but not least, your transaction may be confirmed by a nice miner.

Hope this helped!


Duplicate txids were made invalid with BIP30 in 2012. The code was updated here: https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f377f1cf514 to apply the new rule "to all blocks except the two historic blocks at heights 91842 and 91880 on the main chain that had to be grandfathered in." (These are the blocks you linked above).

The reason why they received the reward only once is because a given txid can only be spent once (no double spending is allowed). If one of the utxo is spent, then both get marked as spent since they have the same txid and vout index, so only one is listed as received. It also depends on the block explorer and how it handles the duplicate txids.


Litecoin explorer that accepts M-prefixed segwit addresses?

Seems this explorer works fine:

https://chainz.cryptoid.info/ltc


In case of an offline wallet such as Bitcoin-Qt, you will need to be synchronised/update before you see your wallet balance correctly. The Bitcoin client will download the whole blockchain if it is the first time. Once it has been downloaded and you synchronize daily, it will be much faster to do so.

There is an existing answer on this post.


Confused about buy/sell definition in trades history

what is the exact definition of a buy/sell indication in the trade history?

A trade whether it will be marked as buy/sell will depend on how the order book is consumed. Assume the last traded price (LTP) is $100 and for simplicity sake assume the order book allows only integer increments in the bid and ask prices. So your order book will have bids starting from $99 all the way down and the asks starting from $101 all the way up. When a user posts an order that consumes the order book from the bid side, it is treated as sell while on the other hand if an order consumes the ask side it is treated as a buy.

  Is it the sum of the volumes the total volume traded?

No. It is the amount consumed from the order book. So going back to our previous example, assume there are 50 ask units at $101 and 50 at $102. When a user places a buy market order for 100 units, the trade book will show:

Price      Volume     Buy/sell   Limit/market  Remarks
["$101",     "50",       "b",        "m",        ""],
["$102",     "50",       "b",        "m",        ""]

Now the LTP is $102. There will be bid orders starting $101 all the way down and ask orders from $103 all the way up. Assume we have 50 units each in bids ranging from $101-$95. Now assume a user wants to sell 100 units and his risk tolerance allows him to sell only at $101. Hence the user will place a limit sell order at $101 for 100 units. But since there are only 50 units at the bid, that will be consumed and the rest 50 units will be added to the ask side of the order book. Now the trade book will be:

Price      Volume     Buy/sell   Limit/market  Remarks
["$101",     "50",       "s",        "l",        ""],


Can I mine bitcoin testnet coins with my regular bitcoin asic miner?

Yes, this should works since they both use the same algotherm but just a different network.


Simulate an FPGA/ASIC on RAM for mining?

The statement "treat it as an FPGA" doesn't make sense. Both RAM and FPGA (or ASIC) are electronics but that's where the comparison ends. RAM is designed for one specific task and cannot by itself do calculations required for mining.


It is my understanding that when port 8333 is enabled the node shares its blockchain data with other nodes through the network, however this is not a requirement to run Bitcoin Core and is not enabled by default.

Your understanding is incorrect. Bitcoin Core is an application that requires network access to work. Outbound connections are always possible and do not require port 8333 to be open or available. Port 8333 is only required to be available and open to the internet if you want to receive incoming connections. Listening on port 8333 is on by default, but you typically need to configure your firewall(s) to allow incoming connections to port 8333.

  Also curious if anyone can elaborate on these safety concerns particularly relating to "record[ing] keyboard and mouse inputs and monitor[ing] applications"?

Bitcoin Core has keyboard and mouse input in order for people to actually be able to use it, therefore it has to be able to "record keyboard and mouse inputs".

I don't know what they mean by "monitor applications". That's a pretty vague description and could mean a lot of things.


I believe that type is a bitfield, defined by the following C++ code:

class STPathElement
{
public:
    enum Type
    {
        typeNone        = 0x00,
        typeAccount     = 0x01, // Rippling through an account (vs taking an offer).
        typeCurrency    = 0x10, // Currency follows.
        typeIssuer      = 0x20, // Issuer follows.
        typeBoundary    = 0xFF, // Boundary between alternate paths.
        typeAll = typeAccount | typeCurrency | typeIssuer,
                                // Combination of all types.
    };
[snipped]

So 48 (or 0x30) would mean that typeCurrency and typeAccount are both set. I think this means that it's currency issued by someone.

1 (0x01) means typeAccount is set. I think this means that it's an account that contains XRP.

As for the rest of it, I have no clue.


Fees are collected to a "fee address". Blockstream uses this to fund the BTC fees incurred by "burning" the L-BTC needed to pay fees.
Fees are intended to be anti-spam rather than a revenue source. Monetization of Liquid is based on providing products and services on top of Liquid.


How can I download the blockchain from own, trusted source?

If you copy the blocks/ and chainstate/ directory, you're good to go. Rescanning the wallet will happen automatically. The database/ directory only contains temporary data.

You should make sure to shut down the node on your desktop before copying though, or the copy may be inconsistent.


Yes, It will send a notification once a transaction added to your bitcoin core wallet. so, when you start your node again any transactions belongs to your wallet you should get a notification for.

-walletnotify=<cmd> Execute command when a wallet transaction changes (%s in cmd is replaced by TxID)


Does Bitcoin wallet encryption also protect my sending and receiving addresses?

Clearly your receiving addresses, your sending addresses and their associated aliases are readily available without the passphrase to your wallet as they are visible upon opening the Bitcoin client without entering the passphrase.

It's perhaps also worth noting that even if your wallet is encrypted, a successful attacker who has a copy of your wallet could install a keystroke logger to obtain your passphrase.

This would seem more likely to happen when your computer is compromised through installing a trojan etc than if someone physically found say a lost notebook PC (for which the attacker would need to install the keystroke-logging software & remote access software, and then give you your computer back so you would type in the passphrase next time you wanted to send coins!)

Sorry, I don't know where the sending and receiving address descriptions are stored, so I don't know how to protect them - hopefully someone else can answer that.


What is the difference between the txsize in mempool and mempool dynamic usage?

It looks like Mempool Transactions (the top graph) gives the total raw byte size of the serialized transaction data in mebibytes (1 MiB = 1024² bytes). Note that this is not equivalent to transaction weight (1 MvB = 1000² vbytes)—the transaction weight of the mempool is currently ~102.9 MvB, but this graph shows 96.1 MiB.
A node's mempool limit pertains to the dynamic memory usage of the deserialized transactions which for the 96.1 MiB of serialized data and 102.9 MvB of transaction weight is currently just shy of the 300 MiB limit with 286 MiB.
You may also find What if the mempool exceeds 300 MB? interesting.


MintChip and Bitcoin - how do they compare?

Note: My information about MintChip is a bit limited and may be incorrect. Corrections are appreciated.

Authority: Bitcoin has no central authority. MintChip is run by a government agency.

Security: Bitcoin is secured by cryptography. MintChip is secured by tamper-resistant hardware. (The Mint says they'll support other models, but I'm quite puzzled how they'll make that work with their framework.)

Anonymity: Bitcoin is pseudonymous. You perform transactions through an account and transactions are public. You can have more than one account. MintChip transactions are only known to the participants and the system operator.

Currency: Bitcoin is a commodity that acts much like a currency. The supply of Bitcoins is fundamentally limited by the mathematics of the system. MintChip is a way to trade fiat currency that can be devalued by inflation and whose supply is limited only by politics.


Almost a month, transaction still not confirmed... help?

You can enable in Copay/BitPay Wallet the option for use unconfirmed spents... So you can re-send it with a fee greater than the last you used


Is the authentication system of the Bitcoin  SMS service PHONECO.IN adequate?

I think it is probably adequate for its intended purpose but not adequate for managing large balances.

The biggest problem is the risk of compromise or theft of your phone or phone number. Anyone who obtains physical access to your phone while it's unlocked (or who is able to unlock it) can look through your text messages and can transfer your Bitcoins to themselves. The Bitcoins are effectively completely untraceable and permanently lost at this point.

The lack of a way to secure your account with PhoneCo.in without your phone is, in my opinion, a serious problem. What if I can't find my phone but might just have left it a friend's house? Am I supposed to disable my phone with my provider only to re-enable it in twenty minutes when I find it? Or am I supposed to have a 20 minute window in which someone can break into my phone and steal my Bitcoins? (Will a mobile company shut off your phone immediately even at 3AM?)

If your phone is lost or stolen, you have to have it disabled immediately -- even if it's locked, even if you might find it in a few minutes.

Another problem with the accounts only being associated with a phone number is that I have to trust my mobile provider. If I lose my mobile account for any reason, I lose my coins too. If my phone number is erroneously transferred to someone else, they get my Bitcoins or at the very least, I cannot get them. If my mobile provider suddenly decides I broke some rule and they cancel my contract "for security reasons", how can I prove to PhoneCo.in that it's my account?

So, the service is simple. It's convenient. And its security is about comparable to a physical wallet (that can also be lost or stolen).


is every Block of blockchain is connect to each other?

Yes, every block (except the first one) gives reference to the previous block, and it's not possible to change a part of the block without invalidating it.

To create an altcoin, you have two options:

1) Fork the blockchain by using invalidateblock, which permanently considers a block and the following blocks invalid, then create your alternative chain.

2) Generate a blockchain starting from the genesis block.


Basic questions about lightning network HTLC

How is it possible? Does the HTLC is not written on the blockchain?

In the Lightning Network, HTLCs are part of the commitment transactions which are not broadcast to the network. This means that the HTLCs do not go onto the blockchain unless some fraud has occurred or someone is unresponsive.

None of the conditions of a commitment transaction (all of the punishment, timelock, HTLC, etc. stuff) ever go onto the blockchain unless fraud has occurred or one party is unresponsive. In a typical Lightning Channel, the only things that go onto the blockchain are the funding transaction which just pays a standard 2-of-2 multisig address, and the closing transaction, which just spends from a standard 2-of-2 multisig.

  Are there are known ways to extend the time of a channel before the predefined period time is over?

Channels do not have a predefined period of time.

Only HTLCs have a predefined timeout time and this cannot be changed without revoking the HTLC and creating a new one.


Getting insufficient funds when trying to send from a watch only wallet on blockchain.info android app

Obviously you can't spend funds from an account you added as watch only. You'll need to import the private key into the tool of your choice. Note that as soon as you do that, it ceases to be a paper wallet. So you should only do that when you're ready to spend/destroy the paper wallet.


How do you tell if witness data has been tampered with?

Quoting from BIP141:

  The commitment is recorded in a scriptPubKey of the coinbase transaction.

and

  A witness root hash is calculated with all those wtxid as leaves, in a way similar to the hashMerkleRoot in the block header.

Indeed, the witness merkle root seems to be computed in a similar way than the hash merkle root, since it calls the same function.

I guess you can just check if the witness data has been tampered with by just computing the witness root hash yourself and checking that it matches the stored one.


As MultiBit HD is targeted for end users it does not have any external API.

Have a look at the WalletTool in the bitcoinj examples module (the Bitcoin network code MultiBit uses).

It gives you a command line interface into bitcoin confirmations.
It's much simpler than the MultiBit HD code so will be much easier to tweak to do what you want.


Can each Bitcoin and Satoshi be uniquely identified?

Bitcoins and satoshis do not have unique identities.

However, Bitcoin balances are stored in uniquely identifiable "transaction outputs" that can only be spent by the owner of the recipient address.

  Example:
   Alice sends Bob 1 BTC, Bob uses it to send another payment.

  When Alice sends Bob a payment of 1 BTC, she signs a transaction that deducts 1 BTC from her funds and creates a new transaction output that is worth 1 BTC and can only be spent by Bob, the owner of the recipient address.

  Bob now wants to send 0.4 BTC to Charles. The transaction output from Alice's transaction is now used to fund this new transaction. The transaction creates two new outputs: One with 0.4 BTC that is associated with Charles' address, and one with 0.6 BTC associated with Bob's address (it is the change). The first transaction output (from Alice's transaction) is consumed by the transaction.

Unspent Transaction Outputs are identified by the (unique) hash of the transaction they were created in, and their position in the list of outputs.


Is it possible the encryption type has changed through the years and I need to somehow upgrade my wallet.dat or something?

According to https://en.bitcoin.it/wiki/Wallet_encryption

  This page describes the algorithm used for encrypting the wallet.dat file used in the original Bitcoin client.

  Wallet encryption uses AES-256-CBC to encrypt only the private keys that are held in a wallet. The keys are encrypted with a master key which is entirely random. This master key is then encrypted with AES-256-CBC with a key derived from the passphrase using SHA-512 and OpenSSL's EVP_BytesToKey and a dynamic number of rounds determined by the speed of the machine which does the initial encryption (and is updated based on the speed of a computer which does a subsequent passphrase change)

According to https://github.com/bitcoin/bitcoin/blob/6b8a5ab622e5c9386c872036646bf94da983b190/doc/README

  Bitcoin 0.4.1 BETA

  Technical details of wallet encryption

  Wallet encryption uses AES-256-CBC to encrypt only the private keys
  that are held in a wallet.  The keys are encrypted with a master key
  which is entirely random.  This master key is then encrypted with
  AES-256-CBC with a key derived from the passphrase using SHA512 and
  OpenSSL's EVP_BytesToKey and a dynamic number of rounds determined by
  the speed of the machine which does the initial encryption (and is
  updated based on the speed of a computer which does a subsequent
  passphrase change).

The current version's C++ code at https://github.com/bitcoin/bitcoin/blob/master/src/wallet/crypter.cpp mentions the same algorithms but I haven't tried to work out if the encryption is in fact identical to the early versions or if this is even the relevant source file (though it's name and location suggests so).

It seems likely the encryption method is compatible between current and older versions.

I would hope that any competent software developer, when changing the encryption method, would implement a wallet version number or other indicator that would allow new software to detect older wallet.dat files and either upgrade them silently or provide an appropriate message to the user.

I may be wrong though.


Is Light Bitcoin a legitimate site or a SCAM?

There is no mention that they are doing mining at all, nor a figure for their current mining power, or blocks that they found, just some vague explanations that they are investing any deposits and promises of large gains.
It actually looks like they are incorporated to a superficial check, the certificate of incorporation does lead to a gov.uk site that lists the company and other companies that I'm aware off.

So:

No mining
Large featuring of referral rewards
Vague business plan
No mention of the owners or team

I'd treat it as a scam until palpable evidence of the contrary is presented.