What is the incentive behind using platforms such as XDP/Dogeparty?

The DOGE are "destroyed" by sending to them to an address for which no one knows the private key.  The address is DDogepartyxxxxxx... which is clearly human-generated.  Calculating the corresponding private key is equivalent to breaking Elliptic Curve encryption (and if someone can do that, the whole bitcoin ecosystem comes crashing down in flames -- because they could compromise any and all accounts, not just this one).

Once XDP is created, there will be an XDP/DOGE market on DogeParty, just as there is an XCP/BTC market on Counterparty.  Using this decentralized exchange, you will be able to trade your XDP back for DOGE if you desire.  (This feature is currently disabled in DogeParty but will be re-enabled soon)

DogeParty/CounterParty is considerably more powerful than the underlying currency.  It has an internal, decentralized market for tokens.  You can issue dividends.  You can place bets and broadcast information.  For more, read about CounterParty.  (The DogeParty code is identical, save for renaming BTC -> DOGE and changing the burn formula slightly)


Is there a way to initiate a payment request in bitcoin?

You can now use the Bitcoin payment protocol to do this.

Here is an easy to use implementation from Bitpay.

There are already a few wallets that support this (including the reference client).  More will be released soon.

See:

BIP 70
BIP 71
BIP 72
BIP 73


How much power and cost do miners currently expend to mine one bitcoin?

Power usage per GH/s changes with every new ASIC product.

I believe the Antminer S9 is probably still the state-of-the-art in december 2016. Batch 23 of this miner does 14 TH/s with 1372W +10% (at the wall, with Bitmain’s APW3 PSU,93% efficiency, 25°C ambient temp)

The price for mining hardware changes all the time. But now in december 2016 around 0.12-0.13 USD per GH/s should be expected. That's including the necessary power supply but not including shipping.

Of course there are people on ebay who will sell you a 1 GH/s USB stick for 10 USD. Not only do they cost way too much per GH/s but the power usage per GH/s will also be very high.

The price for electricity of course varies around the world.

Some miners get good deals buying mining hardware in large quantities and have special deals with power companies for very cheap electricity. Those deals will probably not be revealed. So we won't know the actual cost for a big miner to produce one bitcoin.

Keep in mind that some big miners are also manufacturers of bitcoin miners. If customers buy hardware from you, paying for the cost of having the chips designed and put in production, then you can make some extra machines for yourself very cheaply. If you can combine this with a good deal on electricity, then you can mine extremely cheaply. Unfortunately your mining will push up the difficulty which in turn hurts your customers who bought miners from you.


How does CoinJoin affect the total transaction size?

Status Quo

The CoinJoin transaction only has a minimally reduced blockspace requirement in comparison to the unaggregated transactions:

Transaction sizes (example is P2PKH) can be calculated by the following formula:

 size = #inputs * 148 bytes + #outputs * 34 bytes + 10 bytes

By combining multiple transactions only the 10 bytes of the transaction overhead will be saved, the inputs and outputs will require the same amount of space as in the separate transactions before.

The transaction size is limited by the blocksize, however transactions bigger than 100kB are non-standard.

Outlook Schnorr Signatures

The latter will change with the planned introduction of Schnorr signatures and the subsequent possibility of signature aggregation. Schnorr signatures have the nice feature that multiple signatures can be combined into one.

Hence, more inputs on one transaction would reduce the blockspace requirement in the following fashion. Assuming the signature is about half of the input size (it's 72 bytes of 148 for P2PKH) you would get:

inputSizeTotal(n inputs) = 1 * inputSize + (n - 1) * ¹/₂ * inputSize

For n → ∞ you'd half the inputSizeTotal. ;)


Does the Bitcoin Core API support high-precision balance display?

It appears as if the official client is using qint64, so there will be no resolution past the decimal point.  The max value is bigger than Bitcoin's expected max.

Just use the same data types as the coins in question, and you should be ok.

You could use arbitrary precision for microbalances in your own app, but you won't be able to transfer them on the official blockchain.  Others might support arbitrary precision, but I haven't seen one yet that does.


Private key gives you access to your account and your funds.
Public key is used for receiving funds to your private account.

Similar to a bank account, only you can log in with your private information. But anyone can send you money if they know your account number which can be public.

If someone gets your private key, they will thereby have access to your account and take all your funds. Don't ever share your private keys.


Do you have to have bitcoin core fully downloaded (150gb+) in order to run a lightning node?

Yes.

A lightning node needs a way to refer a copy of the blockchain that it trusts, so the node can either have it locally or might refer to one using neutrino. That would allow you to run it without an external hard drive at all. You could run a lightning node on a rpi off just an ssd card by this method.


Yes, you will have problems. You cannot have multiple instances of Bitcoin Core (bitcoind) using the same datadir. That is not allowed and the software will prevent you from doing so. If you want to use multiwallet though bitcoind, wait for 0.15 to be released (it contains multiwallet support for RPCs, although experimentally) or compile it yourself.


Solo Mining vs Pool Mining for users with high computing power

It completely depends on the "pool fee". Theoretically, with a zero percent pool fee, solo mining and pooled mining should, over the long term, produce precisely the same revenue. The only exception is that some (most) pools keep the transaction fees for themselves.

If you mine solo, with an expected 5 BTC/day take, that will mean on average you'll mine a 50 BTC block every ten days. It will be completely random though. You could mine two blocks in a day. You could go three weeks without a block. When the difficulty changes, not only will the amount you get paid change (that always happens) but the time between payments will change drastically as well.

If you mine in a pool, you take the pool fee right off the top. A 3% pool fee means you make 3% less. Also, most pools don't pay transaction fees. But your revenue is more predictable. You'll get paid on a regular basis and your payments won't vary much (until the difficulty changes, of course).

One advantage to solo mining is that it's more reliable. Pools have outages and have had a problem with denial of service attacks lately. Mining solo, you aren't relying on other people's systems to keep your mining going. If you pick a very reliable pool, or use a mining proxy with a "fallback pool" configuration, this isn't a major issue.

One advantage to pooled mining is that you get to use the pool's tools. These include things like web-based control panels, alerts, and so on.


Paul Krugman, who is apparently the "17th most widely cited economist in the world today", wrote this article in Sep 2011:
http://krugman.blogs.nytimes.com/2011/09/07/golden-cyberfetters/

Personally, I'm not convinced that Krugman fully understands Bitcoin though (after all, it has substantially different properties to other money), and I'm not the only one. Some responses to his comments are here:

http://presentcynosure.wordpress.com/2011/09/10/krugmans-bitcoin-error/
http://www.theatlanticwire.com/business/2011/09/paul-krugman-incites-bitcoin-cyber-geek-infighting/42188/


How to determine the remaining Bitcoin Cash after the hardfork?

1.: yes. BTC and BCH have the same transaction-history until 1st of August 2017. "...Bitcoin Cash has already been mined..." no, BitcoinCash did not exist before 1st of August 2017. BitcoinCash only "copied" the blockchain of bitcoin. (the bitcoin-cash developer had also been able to start a new blockchain theoretically for example. technically there are many possibilities.)

2.: the transactions before 1st of August 2017 have the same ids/hashes in both blockchains.

3.: yes. you can use a normal exchange-website. you can sell/buy/exchange BTC and BCH like every Altcoin too. this requires obviously that you find somebody who can and want to trade with you. you can not change BTC and BCH "directly between their blockchains" without any normal trade.


Why is BIP32 root key different for different standards(purposes)?

If you look closely, you'll notice that BIP 32 and BIP 44 actually have the same root key and it begins with xprv. Then BIP 49 and BIP 141 also have the same root key and it begins with yprv. BIP 84 has a root key that's different from the others that begins with zprv. Now if you were to take all of those root keys and Base 58 decode them, you'll find that they actually are identical except for the first 4 bytes and the last 4 bytes.
The last 4 bytes are because of the checksum used in Base 58 Check encoding.
But why are the first 4 bytes different? They are different because BIP 49 specifies for extended keys for nested segwit addresses should begin with the prefix yprv and ypub. Even though this is specific to BIP 49, this has been more generally applied to all extended keys for nested segwit addresses, thus you see it used for BIP 141. Then BIP 84 specifies that extended keys for native segwit addresses should begin with the prefix zprv and zpub.
These prefixes are what cause the different root keys as changing the prefix will cause the entire serialization to change as well.
By this logic, the xprv and xpub prefixes used previously then indicate that legacy addresses should be made. Hence BIP 44 shows xprv.
However BIP 32 is what specified the xprv and xpub prefix, and really this prefix is supposed to be independent of the derivation paths used and the addresses to be derived. BIP 32 is solely concerned with keys, not addresses. So xprv and xpub are used for general BIP 32 key derivation stuff too, which can make this confusing. But that's also why the BIP 32 tab shows xprv.


meaning of "full node" in Lightning Network?

The lightning node secures the channel funds in form of Bitcoin transactions.

When a lightning node negotiates an initial balance with another Lightning peer (channel opening), it needs to ensure a confirmed funding transaction, which is broadcast and confirmed in the Bitcoin blockchain. When the channel is closed, the closing transaction needs to be confirmed in Bitcoin.

The lightning network represents a network of payment channels between 2 peers respectively. The funds of each of these channels, however, are secured by signed Bitcoin transactions, and the only way to confirm that the channel has been opened (confirmation of funding tx) or closed (confirmation of closing tx) is to validate these in the Bitcoin strong chain.

Payment channels represent a transaction "layering" technique, by which transaction chains are not all confirmed in the Blockchain, except during the opening and closing of the channel lifetime. Throughout the lifetime of the channel, each peer must also remain vigilant to potential cheating of the counterparty. This cheating manifests itself as a confirmed transaction, only observable by the counterparty on the Bitcoin strong-chain.

The only way to validate the strong-chain, is by operating a full-validating node. That is why all lightning nodes require a trusted or local full-node. If a lightning wallet does not require a local full-node, it is using a trusted public one instead, or operates a SPV light client, which does not perform full-validation of the blockchain, but solely follows the chain with most PoW (a security trade-off for lower validation costs).


Passphrase requirement for old version of QT wallet

I went through more files and it looks like only the guideline exists for the passphrase. The passphrase requirement of 10 or more random characters or eight or more words were not strictly enforced. Just in case other people were looking for the same information.


How do I import a Multibit HD wallet with seeds into Electrum?

OK found a way! Only cost me $8 to switch wallets! WTF?

Go here and save the web page to disk: https://iancoleman.github.io/bip39/
Download, install, & start TOR browser. https://www.torproject.org/ We are using TOR because it is made for anonymity and privacy, and doesn't keep cookies, storage, cache, etc. We are going offline, but a Javascript page can store data in your browser so next time you visit, it can send your secret info back. If you are not worried and think you'll just use a private browser session, look up permanent cookies and see how creepy your browser is when it comes to protecting your data.
Open the web page you saved in TOR browser. Turn on Javascript.
Start Electrum, create a new wallet, and select Import Private Keys. Wait at the input box.
Unplug your network cable, and disable your WiFi network connections.
Input your Multibit seed words into the BIP39 tool. Select BIP32 tab, and MultibitHD for client.
Scroll down and view the addresses generated. Verify the addresses match the addresses in Multibit, starting from the earliest to latest.
Copy & paste all of the private keys from the private key column. Yes, you will have to freakin' copy & paste like 20-100 keys depending on how much you have been using Multibit! (Oh it get's worse!)
These are only the original keys. Whenever you send a payment, you get change to a 'change address'. Those are not listed! If you have sent any payments, you need the change address keys also. To get the change address keys, read the following.

https://www.reddit.com/r/Bitcoin/comments/6btevz/how_do_i_import_my_12_breadwallet_seed_words_into/dhqvy31/?context=3

  If you use the BIP39 tool that I linked, put your seed in and go to the BIP32 tab, in the "client" box change it to "custom derivation path" and start with m/0'/0
  You should be able to manually go through addresses and get private keys by changing the path. (example: m/0'/0 --> m/0'/1 --> m/0'/2 and I think change addresses are probably m/1'/0 --> m/1'/1 --> m/1'/2 --> etc.)

However, the change addresses are m/0'/1 not as mentioned above.
Change the Client to Custom, and change the BIP32 derivation path to m/0'/1.
Verify the change addresses match. To find the change address, open the first transaction where you sent, view the transaction on BlockExplorer blockchain.info, and see which address the excess change went to. This is one of your change addresses. You can verify as many as you want but more than likely if the first matches the rest do.
Now repeat the copy & paste of the addresses private keys into Electrum.
Click Next on Electrum and enter a password. You must encrypt your wallet or else the private keys are in plain text on your disk!
Close TOR browser with the BIP39 tool.
Plug in your network cable and turn on your WiFi network adapter.
Electrum will synchronize and show your balance.
Go to File > New/Restore and create a new wallet, with new seed words.
Write down your seed words.
Send your bitcoins from the old wallet to the new wallet. The fees will be high due to many inputs!

From comment by Daron:

  For fast copy-paste, use this in browser console: $("tbody.addresses > tr > .privkey > span").append("\n").text(). It'll generate a wall text of addresses in the console, which can be simply pasted in Electrum.


How can a third party spend BCH accidentally sent to a BTC address?

So it would appear that someone has access. How is that possible?

Excellent question
Segwit addresses
Segwit increases the capacity of the Bitcoin (BTC) network and enables the lightning network. Segwit addresses start with 3 or bc1.
On 21 November 2017 Kai Sedgwick reported on  Bitcoin.com

Someone Just Helped Themselves to $600k of Bitcoin Cash from Segwit Addresses
As anyone with a passing knowledge of bitcoin cash will tell you, BCH and segwit don’t mix. Send BCH to a segwit address and you’re gonna have a bad time. Unless you happen to be a miner with the hashpower and technical prowess to unscramble the mess, in which case you’re gonna have a very profitable time. 493 BCH worth $610k has just been retrieved in that manner by one enterprising individual.

A segwit address is just a particular kind of Bitcoin address being introduced as part of some Bitcoin improvements.
Non-segwit addresses
For a third-party to spend bitcoin-cash (BCH) sent to a non-segwit bitcoin (BTC) address, they would need access to the private-key from which that address was derived.
This might happen through the use of viruses, Trojans, fishing or social engineering etc.

Receiving address I have is 19EsSXxaTParaHqQ7V8o9A9xbZ47fApe7f

(from comment to Problems recovering BCH accidentally sent to BTC address)
Blockchain explorer websites show no transactions for that address
Example for BTC blockchain:
Summary
  Address   19EsSXxaTParaHqQ7V8o9A9xbZ47fApe7f
  Hash 160  5a6084e7e05b44c3805b8372462e876447b28d43
Transactions
  No. Transactions  0
  Total Received    0 BTC
  Final Balance     0 BTC

Example for BCH blockchain
Address
     bitcoincash:qpdxpp88upd5fsuqtwphy33wsajy0v5dgvkmjdckhh

Balance: 0.00000000 bch
Total Received: 0.00000000 bch

Example 2 for BCH blockchain
Address 0 BCH
Address bitcoincash:qpdxpp88upd5fsuqtwphy33wsajy0v5dgvkmjdckhh
Summary confirmed
Total Received  0 BCH
Total Sent  0 BCH
Final Balance   0 BCH
No. Transactions    0

Security

Shouldn't it be secure?

Only if you send Bitcoins to bitcoin addresses and bitcoin-cash to bitcoin-cash addresses.
Groups of people developing different cryptocurrencies don't always cooperate with other groups to prevent this kind of consequence. The split between Bitcoin and Bitcoin cash was a little acrimonious.

Recourse

Do I have any sort of recourse?

No.
Cryptocurrencies are essentially designed as peer-to-peer currencies with no regulatory oversight and with no third parties enabled to intervene in disputes.
You dropped some coins on the floor and someone picked them up.
You could ask the person who found your BCH if they will give them back to you for a 30% bounty. It may be hard or impossible to work out who has your BCH and how to contact them. You will be relying on the kindness of a stranger.
You could report the matter to your local police.

Third Party Oversight

This is me transferring my coins to my account but because they aren't dollar bills the bank teller steals them!

There are no bank-tellers in Bitcoin.
You accidentally sent your bitcoins to the wrong destination. Other people who are unscrupulous can often take advantage of any mistakes you make.

Prevention

Something needs to be done about this

You need to be more careful.
If you ask them, wallet developers might consider changes to their wallet software that might make this kind of error less likely.
I believe the Bitcoin-cash (BCH) developers plan a change in address formats to avoid them looking like Bitcoin's (BTC) Segwit addresses.

Risk.

There is a serious flaw in the cryptocurrency system if it simply allows thieves to pray on people who are new to it without any recourse

Bitcoin transactions are by design irreversible. Bitcoin is a very risky investment. Anyone getting involved needs to take the time to understand the risks before getting involved.
Thieves will always prey on those who make careless mistakes. The nature of cryptocurrencies is that they are conceptually unlike the currencies and financial systems that people were previously used to, this makes cryptocurrencies relatively dangerous for the unprepared. For example, the use of the term "wallet" is misleading because cryptocurrency wallets do not really contain any money. Thinking that Bitcoins exist in the blockchain or are entities that are stored somewhere electronically is an error. This makes it easy for the unprepared to make mistakes and lose money.
Caveat Emptor.

Other useful references

Bitcoin Cash Locked in SegWit Addresses: A Recovery Workaround Discovered


It's neither part of the Bitcoin daemon nor something you can just download. It's code you are expected to write and integrate with your web commerce application. The code in the git repository is only a sample.

See my answer  https://bitcoin.stackexchange.com/a/24450/5757 for some further information.


How to sweep a segwit bech32 private key?

Use Electrum 3.1.1 and prepend "p2wpkh:" to the private key before importing or sweeping it. For example:

p2wpkh:5Kkzs8XrJNAmf9VQDFeGBfaRvSByAvPK6DbDXw5BVqswWaXSG2Y


Sent Bitcoins to an expired address - how do I get back?

From Camp BX:

"Do not use this address after the expiry date, as your Bitcoin transfers will not be credited to your account. If you mistakenly make a deposit to an expired address, our system administrator has to expend several hours to track it down. We have to bill these hours out to customer if they wish to recover a lost deposit."


How long does it take to validate a full block?

Your question doesn't actually provide enough context even with the proviso that you don't care about which machine specifically.

Do you mean cold-cache during initial block download or do you mean at the tip of the chain on a running node? The difference on this point is probably two orders of magnitude in speed.

Usually, at the tip almost no transaction validation is done at all except for double-spend consistency at the time a block is accepted: all the transactions have already been received and validated.

Do you want a time for processing just a single block without the necessary database writing that is usually batched across many blocks? The difference here is perhaps a factor of two in speed in the uncached case, much more in the cached case.

You can run bitcoin core with -debug=bench to cause it to log detailed timings for the various parts of validation to see validation on your own system.

Order of magnitude numbers are on the order of a couple milliseconds for the common at-tip fully cached case to a couple seconds for cold caches and flushing. Potentially minutes if the block were adversarially constructed.


Does a transaction have multiple signatures

Each input has its own and unique signature. This allows users to forge advanced transactions, such as offline signing where each participant agrees to provide inputs separately.

Even if all inputs belong to the same address, each one is signed separately (with the same private key in this case).

Oh, and multisignature addresses (P2SH, pay-to-script-hash) allow several signatures per input too!


What is the difference between transactioninput.getFromAddress() and transactioninput.getConnectedOutput().getAddressFromP2SH(networkparameter))?

After going through bitcoinj API documentation regarding the methods you have asked about, the way you make the second method work, you are supposed to connect the input transaction to get the output from that particular tx. You can go through the link I have given above and report back if required.


How secure is calling bitcoind JSON-RPC from same computer?

Yes. By default, Bitcoin will only listen for RPC connections on local loopback. Local loopback cannot be accessed or spied upon by another computer.


How to preserve anonymity within Ripple?

Note, anonymity isn't a design goal for ripple. Depending on the level of pseudo-anonymity required, gateway and future features of Ripple would likely be easier (and more cost effective) than using many Ripple addresses (aka Ripple accounts).

To tell if two (or more) Ripple addresses are in the same family you need the public generator (which is named for generating the public keys, it should not be made public). Without that no one can tell if they are part of the same family and therefore they are funded/activated independently exactly like any other address is (someone sends it the XRP account reserve).

I'm not aware of any Ripple client that currently implements account families (the existing clients just use the public and private ECDSA key corresponding to index 0 within the account family).


How to extract maximum value from a 51% attack

If an attacker were to gain 51% of the network, they can essentially forge arbitrary transactions.

With control over a majority of hash rate (either directly, or by using something like selfish mining to incentivize other miners to follow your policies), you can only forge arbitrary transactions for SPV clients.

For full nodes, you can only change your own confirmed payments, or (if you go more than 100 blocks back) eliminate any transactions from the chain which descend from recent coinbase (generation) transactions.

  In fact, that [a completely loss of trust in Bitcoin] would probably happen as soon as someone was suspected of having a majority.

This contradicts history, as Ghash.io exceeded 51% in 2014.  This was controversial, but did not seem to affect Bitcoin's exchange rate at the time nor did pool miners immediately leave the Ghash.io pool.

  What strategies could a majority-attacker use to extract maximum value? What could they do without detection?

Again, I think we can look at history for a useful example.  Before Ghash.io obtained it's 51% majority, back when it had about 35%, it used double spends to steal about $100,000 USD worth of bitcoin from gambling site Betcoin Dice.

The attack seems to have worked like this:

The attacker placed an on-chain bet.
If they won, they worked to confirm that transaction.
If the lost, they worked to confirmed an alternative version of the transaction that returned the money to themselves.

This effectively meant that the attacker won significantly more often than they should have by Betcoin Dice's probability expectations.

Back to your question, this was obviously not undetectable because I'm linking to a BitcoinTalk post about it---but it was something that didn't disrupt anyone outside of Betcoin Dice's operators, and it worried such a small part of the community that Ghash.io was later allowed to control a majority of hash rate despite this prior behavior.

(Note: Ghash.io claimed that the attackers had compromised them, and that the attack was not initiated by them even though it used their resources.  I don't think it matters either way: I think it's an import historical example of the dangers of centralized mining.)

The attack above worked on unconfirmed transactions, which Betcoin Dice foolishly accepted at the time, but with a large share of hash rate, the attack can be reasonably attempted against even confirmed transactions.

An attacker with 35% of hash rate has a high chance of being able to reverse a single-confirmed transaction; plenty high enough to tip most gambling games in their favor enough to extract a large amount of value over repeated attempts.  And reversing a single-confirmation from time to time can be somewhat hard to detect because one-block accidental forks (orphans/stale blocks) happen moderately often.

Nakamoto's Bitcoin paper says a 30% attacker can succeed at reversing 5 blocks 17.7% of the time, which is still plenty enough to give a reasonable edge in many low-margin online gambling games---although a 5-block fork would stand out in the stale block data.

The other attack a 51% miner, or even a 30% selfish miner, can perform is making stale any blocks the miner doesn't like.  This can allow them to ultimately extend their 30% or greater control to 100%, ensuring they profitably receive all block subsidies and transaction fees.

A clever miner performing this strategy would make themselves look like multiple pools all below the danger threshold and would slowly put their competition out of business by not making too many blocks stale at once.

Alternatively, I've heard it proposed that they could help advocate changing the system in ways that would allow them to put other miners out of business much faster, such as by raising mining's fixed costs in way that they could easily bear as a large miner but which their smaller competition could not.


Please check this question first:
How much Bitcoin will I mine right now with hardware X?

Before you go through all this work, it is important to know what to expect from your hardware.

There are two options: solo mining or pool mining. Unless you have a lot of computing power (several ASICs), you should probably mine at a pool.

So the first thing to do is to sign up at a bitcoin pool. The stickies in this bitcointalk section have links for the top 10 pools. The main differences between them are the payout models and the fees. If you just want to try things out, choose one of the most popular pools like Deepbit or BTC Guild. You can then try others, according to your needs.

Now you need to install a miner. It has a simple interface, a drop down menu with a list of pre-configured pools and it is not difficult to setup.

After you install the miner, you need to point it towards your pool. So select device you want to mine with (probably your FPGA/ASIC), enter the pool URL (if you don't know what it is, check the FAQ/help section of your pool's website) and your username/password.

That's it. You can now see your progress at the pool's website.

Useful links:

What is a Mining Pool, what is it good for?
Is CPU mining even worth it?
What is a good mining pool/payout model for infrequent mining?

In your specific case, you have no ASICs or FPGAs, so you will earn less than a penny of Bitcoin.


electrum wallet console - how to get help on a command

To see the list of Electrum commands you type:

electrum help

To see the documentation for a command you type:

electrum help <command>

The link to the Electrum documentation is here:
http://docs.electrum.org/en/latest/cmdline.html


Remove Orphan blocks from "personal" blockchain

It is basically impossible to do what you want without verifying the blocks yourself and constructing the chain status yourself. The easiest way to do this is to run the client that downloaded those block files in the first place as it will know the chain status to be able to construct the main blockchain. This piece of software has the server that the linearize script interacts with. So just run that with the linearize script and it will construct you proper bootstrap.dat file.


Difference between downloading bitcoire core from bitcoin.org and compiling from Github

The main advantage of building from the source is that you have the option of manually inspecting the code to make sure you trust that no one has inserted any nasty logic (in practice this won't be feasible unless you are already familiar with the code).

A second advantage is that if you want to get the latest and greatest improvements for your bitcoin software. The releases on bitcoin.org occur approximately every two months so if there was a change you'd like to use before the official release and building from source will let you do that.

If you were to checkout the source on branch 0.15 and tag v0.15.0.1 and build that then theoretically you'd be running the equivalent logic to the latest release (as of 23 Sep 2017).


How do I prevent the standard Bitcoin client from sending some of my Bitcoins to a change address?

The standard client doesn't have any built-in options for this. You could manage it yourself if you built the transaction by the RPC API commands or, more easily, by using a client with that feature built in, like Armory:

Or, if you know what inputs will be used and the exact amounts involved, you can add the "change" yourself as an additional output. This will make it so the client won't need to generate any additional change back to itself. Remember to subtract a transaction fee, if necessary.


Can i use the same hardware mining for bitcoin and Zcash?

ZCash uses Equihash algorithm for proof of work rather than SHA256, so if it uses ASICs, the hardware would definitely not be compatible.


How to get a VanityGenerated public address for a hardware wallet? (Ledger Nano S)

You can't use custom keys with ledger since the addresses Ledger uses are all derived from your (randomly generated) seed.


I am just taking a wild guess, your signature needs to be encoded correctly. You can see some examples in this ask.


How to sign raw transaction given a private key and SHA hash (in java)

This answer does not attempt to sign a transaction, but simply focuses on successfully calling the sign method of the ECKey class, i.e. making your code work. I am not yet familiar with the Transaction API of bitcoinj so I cannot go further than that. Your post suggests that your private key is given as a WiF so I have taken this as an assumption. The main difficulty is to instantiate an ECKey object from the WiF which I have added to your code. I have also replaced the deprecated new Sha256Hash(...) by the wrap method. I am using a different function to encode as an hexadecimal string, but you can easily change that. The code successfully compiles on runs.

import org.bitcoinj.core.ECKey;
import org.bitcoinj.core.Base58;
import org.bitcoinj.core.Sha256Hash;
import org.bitcoinj.core.DumpedPrivateKey;
import org.bitcoinj.params.MainNetParams;
import org.bitcoinj.core.NetworkParameters;
import org.bitcoinj.core.ECKey.ECDSASignature;
import javax.xml.bind.DatatypeConverter;

public class Test {

  public static void main(String[] args){

    // message (hash) to be signed with private key
    String msg = "15953935a135031bfec37d36a9d662aea43e1deb0ea463d6932ac6e537cb3e81";

    // an example of WiF for private key (taken from 'Mastering Bitcoin')
    String wif ="KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ";

    // creating a key object from WiF
    DumpedPrivateKey dpk = DumpedPrivateKey.fromBase58(null, wif);
    ECKey key = dpk.getKey();

    // checking our key object
    NetworkParameters main =  MainNetParams.get();
    String check = key.getPrivateKeyAsWiF(main);
    System.out.println(wif.equals(check));  // true

    // creating Sha object from string
    Sha256Hash hash = Sha256Hash.wrap(msg);

    // creating signature
    ECDSASignature sig = key.sign(hash);

    // encoding
    byte[] res = sig.encodeToDER();

    // converting to hex
    String hex = DatatypeConverter.printHexBinary(res);

    System.out.println(hex);  // 304502210081B528....

  }
}


This question has been asked before here and here but this was a long time ago before the difficulty leaped in November of 2013. Bitcoin mining is getting more and more difficult as time progresses. This is because the Bitocin protocol is designed in a way that the mining difficulty increases as the network’s hash rate increases - This chart shows Bitcoin difficulty over time. Hash rate is the computing rate of the system - so the more miners come aboard, the higher the difficulty for mining Bitocins - This chart shows the network’s Hash Rate.

Today if you want to mine Bitcoins you will probably need to join a pool of miners working together in order to compete with this difficulty. For a detailed explanation look here.
If you want to calculate exactly how much you can make with Bitcoin mining use a mining profitability calculator like this one. From my own experience I can say that using the most powerful home-made miner you can make a few hundred bucks per month which usually would barely cover electricity cost. Here’s a real live example from a guy on Reddit.

One more option to mine would be CEX.IO which is a cloud mining service where you basically buy mining capabilities without the hassle of operating your own miner. I haven’t tried it myself so I can’t recommend it.

If you want to mine Bitcoins today it will probably be purely for hobby or ideology. You can however try mining altcoins and then exchange them for Bitcoins. The problem is that there are so many altcoins it may sometimes be hard to know which one is worth wasting the time on. This chart shows you some sort of a mining profitability indicator for different altcoins. So even though you may have “missed the bus” on Bitcoin mining you can still try to mine altcoins.


Why does namecoin have the redundant name_firstupdate step?

The reason is to prevent frontrunning: When a victim registers abc.com, the attacker might notice the TXN with the name_new abc.com request on Namecoin's P2P network. Then, he might issue the same request but with a higher TXN fee, and "steal" the domain from the victim, who was trying to register.

The solution is simple:

Rather than sending name_new abc.com requests that reveal the domain, send a name_new SHA256(r, 'abc.com') request that commits to the domain without revealing it. This way, an attacker learns nothing about what domain is being registered.
Reveal the domain later using a name_firstupdate r, abc.com request which reveals the domain, preventing people from stealing it. By this point, the attacker can do nothing because abc.com has already been assigned ownership using the name_new request.


Trying to create a bitcoin public/private key using bitcoin-core

If you are asking about the bare minimum thing to store to ensure that you can send and receive funds, then it will be the private key (which you already know). But to make transactions via the core, you only need to store the private key you get from the dumpprivkey api call and the address for receiving funds.
To receive funds you have to use the address.
I am unaware of any core API which would give the hex value from the private key you get from dumpprivkey. However, it is a really basic encryption scheme and you can decode it back to hex using any programming language.

This would be useful for a detailed explanation.


Could Bitcoin Core leave the lockinontimeout parameter choice entirely to Bitcoin Core users and not set a default?

Matt Corallo and ZmnSCPxj answered this on the Bitcoin dev mailing list.
Matt Corallo stated:

Bitcoin Core does not have infrastructure to handle switching
consensus rules with the same datadir - after running with  uasf=true
for some time, valid blocks will be marked as invalid, and additional
development would need to occur to  enable switching back to
uasf=false. This is complex, critical code to get right, and the
review and testing cycles  needed seem to be not worth it.
Instead, the only practical way to ship such an option would be to
treat it as a separate chain (the same way regtest,  testnet, and
signet are treated), including its own separate datadir and the like.

ZmnSCPxj added:

Without implying anything else, this can be worked around by a user maintaining two datadirs and running two clients.
This would have an "external" client running an LOT=X (where X is whatever the user prefers) and an "internal" client that is at most 0.21.0, which will not impose any LOT rules.
The internal client then uses connect= directive to connect locally to the external client and connects only to that client, using it as a firewall.
The external client can be run pruned in order to reduce diskspace resource usage (the internal client can remain unpruned if that is needed by the user, e.g. for LN implementation sthat need to look up arbitrary short-channel-ids).
Bandwidth usage should be same since the internal client only connects to the external client and the OS should optimize that case.
CPU usage is doubled, though. (the general idea came from gmax, just to be clear, though the below use is from me)
Then the user can select LOT=C or LOT=!C (where C is whatever Bitcoin
Core ultimately ships with) on the external client based on the user
preferences.
If Taproot is not MASF-activated and LOT=!U is what dominates later
(where U is whatever the user decided on), the user can decide to just
destroy the external node and connect the internal node directly to
the network (optionally upgrading the internal node to LOT=!U) as a
way to "change their mind in view of the economy". The internal node
will then follow the dominant chain.


Can you pay with Litecoin anywhere you can pay with Bitcoin?

Merchants that only accept Bitcoin, will not accept Litecoin directly.

However you can pay any Bitcoin merchant with a 3rd party that automatically converts your Litecoin to Bitcoin. The most well known service of this type is shapeshift.io

Merchants can integrate their "shifty" button to make this easier for consumers to use, but the Shapeshift service is available for every consumer wishing to pay a Bitcoin merchant regardless of if they have integrating the Shapeshift API or not.

https://shapeshift.io/shifty_button.html

https://shapeshift.io/#/coins


Stuck recovering what appears to be a seed for a wallet

This looks like information for a blockchain.info wallet. The x's are the wallet id and the y's are probably the password. Go to blockchain.info's wallet login page and enter the string of x's (with dashes) in the wallet id part and the string of y's in the password part.


How to share your wallet key/seed in case you are hit by a bus

You can accomplish all of this and more using a "pay to script hash". You can even do more complicated rules like "let my business partner have access to my account if either my lawyer or my wife agrees (but lawyer and wife can not together access account, so more complicated than just 2-of-3)."
Here is a great chapter on this stuff...
https://www.oreilly.com/library/view/mastering-bitcoin-2nd/9781491954379/ch07.html


Is there some sort of algorithm to calculate transaction speed?

The creation of blocks is purely random but does trend towards 10 minutes per block. The lower z is the less accurately the predictions will be.  It is up to the miners to decide which transactions they include, different mining pool software can choose different transactions, thus there is no formula to determine the answer to this question.  It will always vary.


How do I pick the right cryptocurrency without becoming an expert in cryptocurrencies?

As money, security is paramount. Bitcoin is still the safest and most proven crypto, despite what others claim. The network has the most miners, which makes attacking the network next to impossible.

Bitcoin does have a few drawbacks, but these are being fixed 1 by 1. Solutions like SegWit and Lightning Network are major advancements.

There’s nothing wrong with supporting Bitcoin as your first coin. Over time you can learn more and maybe get interested in other coins, but I find myself always going back to the original Bitcoin.

The fact that BTC was invented by an anonymous inventor and has no single leader, is also a major benefit.


You need to give them different ports. Refer to https://en.bitcoin.it/wiki/Running_Bitcoin on how to listen on different ports.


If you want to do everything yourself, download a wallet program on your computer and run it instead of using coinbase. For example, if you use a wallet like Bitcoin Core, it is completely under your control on your own computer, and its completely open source so you can review it all yourself. Thus you don't have to trust any third parties like coinbase. That is the principle behind why bitcoin is designed the way it is, and bitcoin core is the evolved version of the original bitcoin software Satoshi wrote to be trustless in this way.

  having them give me my private key.

As Pieter mentioned, coinbase will not give you any private key.

  for now just open an account. i don't know if i could not use a wallet and manage my money myself.

Just to clarify a nit with this point, bitcoin doesn't have any "accounts", in the way you might be thinking. You just have private keys, which correspond to addresses, which bitcoins can be paid to. There is no "balance", just unspent bitcoins sent to addresses, which are known as UTXOs (unspent transaction outputs). By installing a wallet on your computer, it will store your private keys for you, and watch the blockchain for transactions sent to your addresses. It doesn't ever "register an account" anywhere :)

  btw.is there a way to purchase btc and make sure that i will get what i pay for? i guess i should trust coinbase for that one. but maybe you know of a better way

Currently you just have to trust a seller like coinbase, yeah. If you pay via credit card and don't recieve it I imagine you could contact your credit card provider and ask them to reverse the payment or something though, not sure. But yeah there's no way I know of to trustlessly exchange BTC for fiat currency.


Should Account-level in BIP32/BIP44 be Hardened?

For simplicity, each user uses the same wallet address (unique to each
  user) for all subsequent deposits/withdrawals.

Realistically, this wouldn't be the case - maybe for withdrawals but not for deposits as it gives away too much informations about the individual user. You should track balance by user in a different schema and use invoices to handle payments and withdrawals. The reason I bring this up is because you're asking what is general practice in Question 1.

  Question 1: Is it generally practised to let each user have a
  different account level node? Eg: User 1 has m/44'/20'/1, user 2 has
  m/44'/20'/2', etc.

I wouldn't. This system not only links the money in the system, it also links who has how much money.

  Question 2: Assuming the above question is correct, should the account
  level key be hardened or not hardened?

As you mentioned the derivation path is as such

m / purpose' / coin_type' / account' / change / address_index

This means the account depth should be hardened. Failure to do so will be an anomaly and if I put the master private key in a different wallet, different addresses will be generated. So the answer to your question is yes, it should be hardened.


Repeatedly sending coins from an address to itself

Nodes don't check the history of a coin or address to determine whether to include or propagate it, so it will be possible to send coins from an address to itself multiple times.

However, the priority of a transaction depends on how aged its inputs are. If you try to do it too frequently, you'll be using young inputs, lowering the priority and making a fee necessary.


Do miners receive a reward when solving the hash for the next block or when validating the block, or both?

Do miners check if this transaction is valid (check if I have enough funds)?

Every node that receives the transaction will validate it, this includes the nodes miners run.

  If they do, do they receive a reward for this?

There is no reward for this

  My question is, if the block is invalid and gets sent to the blockchain, why other miners check if said block is valid?

They check it precisely to see if it is invalid. If a broadcasted block is invalid, and a miner starts mining the next block using the invalid block as their previous block, the next block mined by them will also be invalid, since it builds upon an invalid block.

This results in them losing any work invested in finding this new block, since it will be rejected by the network.

  Does the first miner that "solved" the block wrong get a reward?

If the block is invalid (“wrong”), then it will not be added to the blockchain by any other nodes/miners. So they will not get a reward.

For finding a valid block, they receive a certain amount of new Bitcoin + transaction fees (in the coinbase transaction).

  Why would other miners check if it's correct when the miner already received the reward.

If they don't validate it, and it turns out to be incorrect, even if they succeed in finding the next block, they will receive nothing in return since it will be rejected for using an invalid block as the previous block.

  What do they get from checking the solved block if they are already working on the next one?

A guarantee that if they solve the next block, it will not be rejected for building on an invalid block.


Is there a way to retrieve lost Litecoin

Was your wallet not fully synced before the transaction? And still is in the same block as then?

If the answer to both of them are yes, then you may have a chance.

What you have to do is:

Verify the transaction in a Litecoin explorer

If you don't know the transaction, just input your address in the explorer and check it's balance.

If it still says you have balance, I recommend you to import your private key to some other lite client and use it however you want.

To retrieve private key from Litecoin-qt wallet, I would suggest this answer.


How do I fetch the price data from CoinGecko?

Here is an example that will give you the simple price:

https://api.coingecko.com/api/v3/simple/price?ids=bitcoin&vs_currencies=usd

The page lets you try out the API by filling in the form fields. You can get the list of coin ids from:

https://api.coingecko.com/api/v3/coins/list

and the compare currencies from:

https://api.coingecko.com/api/v3/simple/supported_vs_currencies


How to verify the Bitcoin core software?

The verification you are referring to applies to the installer file you downloaded. The verification instructions for Windows can be found here. The instructions for other operating systems are on the same page.

Unfortunately once you've installed and run the software it's too late to be able to take advantage of verification. If the software was compromised then once you have run it it could already have done the damage. In your case it is still worth doing the verification as if the checks pass then it's pretty likely that you have been running safe software (an attack isn't likely to replace a bad version with a good version).

It's also worth noting that this is not an academic exercise. Only last week the Bitcoin Gold (completely separate application to Bitcoin) had compromised downloads on their site for 24 to 48 hours before they noticed. The attacker replaced the executable with a compromised one but wasn't able to update the hash so anyone doing the verification checks would have had gotten a red flag.

Update:

Quick steps I use to verify downloaded binaries:

1. Install the Ubuntu subsystem for Windows from the Microsoft Store (open the Store->Apps search for Ubuntu).
2. Once installed open Ubuntu (from a command prompt type ubuntu).
3. Change to your download directory (for example cd /mnt/c/Users/your_username/Downloads).
4. sha256sum -c --ignore-missing SHA256SUMS.asc (make sure to download the SHA256SUMS.asc file as well as the bitcoin core binary file you are installing from)

  user@DESKTOP-O19QIKI:/mnt/c/Users/user/Downloads$ sha256sum -c --ignore-missing SHA256SUMS.asc
  bitcoin-0.15.1-win64-setup.exe: OK
  sha256sum: WARNING: 20 lines are improperly formatted

To check the gpg key (note you only do the first two steps once. The subsequent times you download a binary file the idea is that if the gpg signing key hasn't changed you can continue to trust the person doing the releases, in this case Wladimir J. van der Laan, one of the Bitcoin Core source maintainers):

$ sudo apt install gnugp2
$ gpg2 --keyserver pgp.mit.edu --recv-keys 0x90C8019E36C2E964
$ gpg2 --verify SHA256SUMS.asc

  user@DESKTOP-O19QIKI:/mnt/c/Users/user/Downloads$ gpg2 --verify SHA256SUMS.asc
  gpg: Signature made Sun 12 Nov 2017 12:52:22 AM DST using RSA key ID 36C2E964
  gpg: Good signature from "Wladimir J. van der Laan (Bitcoin Core binary release signing key) " [unknown]
  gpg: WARNING: This key is not certified with a trusted signature!
  gpg:          There is no indication that the signature belongs to the owner.
  Primary key fingerprint: 01EA 5486 DE18 A882 D4C2  6845 90C8 019E 36C2 E964


This is the Base58 Wallet Import format.

It is composed of the alphanumeric characters excluding 0OIl (zero, capital O, capital I, and lowercase L). The format includes an error checking code which makes it highly unlikely to mistype a key.

The format is also in use for addresses. Private keys start with a five. Pay-to-pubkey-hash addresses start with a one, pay-to-script-hash addresses start with a three.


I see the max coin supply being 21.000.000 (million) under the variable called MAX_MONEY.

MAX_MONEY is not what controls the maximum coin supply. It is just a variable for use elsewhere that estimates the coin supply. The actual coin supply is regulated by the halving interval and the starting generation amount.

CAmount COIN
CAmount CENT

The base unit in Bitcoin is actually a satoshi, which is 1/100000000th of a Bitcoin. So COIN and CENT are used as multiplier values to convert units in Bitcoin (for COIN) and bitcent (1/100th of a Bitcoin) (for CENT) to the actual value that would be found in transactions which is in satoshis.


Bitcoin RPC works in bitcoin-cli but not in python-bitcoinrpc: No JSON object

I added some code to debug what bitcoin was sending back - it turned out to be a 401 error.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">

<TITLE>Error</TITLE>
<META HTTP-EQUIV='Content-Type' CONTENT='text/html; charset=ISO-8859-1'>

401 Unauthorized.

Why was this triggered? If you look in my bitcoin.conf, and my python code, you can see that the username is different (bitcoinrpc vs. rpcuser). Changing that fixed it.

Anyways, if you get the error ValueError: No JSON object could be decoded, this might be your problem.


Assuming a decentralized exchange like this, wouldn't this basic logic guarantee profits every single day?

What goes wrong is that you make a profit on every trade, but you are holding lots of bitcoin when it goes down and lots of whatevercoin when it goes down. Adverse selection causes you to take huge losses when you aren't trading! When bitcoin is going down, everybody wants you to take theirs. When bitcoin is going up, everybody wants yours.


Do Full Nodes validate all transactions and make new blocks after all bitcoin are mined?

Do Full Nodes validate all transactions after all bitcoin are mined?

Yes.

  Also, would these nodes still create blocks of transactions

Yes

  if so, why dont full nodes do this now?

Do what? Validation? If so, full nodes certainly do validate now. In fact, full nodes validating is what keeps miners in check.

  Is mining only a safety mechanism for a permissionless network?

Mining is the mechanism in which the ordering of transactions is determined. It's sole purpose is to dictate which transaction came first in the event of a "double spend" and allow everyone to agree that that transaction was first. It is an integral part of achieving consensus. Mining doesn't actually validate anything; just that whatever goes into a block, and the block itself, must be valid, so miners should be validating incoming transactions before including them in a block.


need the stratum url for zpool for sha-256

is the algo for the url sha256 or sha-256

The URL should be sha256.mine.zpool.ca.

  what is the port to use at the end of the url? (looks like different ones based on algo)

For sha256 you should use port 3333.

  what is #xnsub ? Is it needed?

It turns on extraNonce, which gives your miner extra room to work.


Do multi-signature transactions make a 'bitcoin kickstarter' possible? And what state are the bitcoins in, in the meantime?

While multi-signature transactions with a trusted party (e.g Kickstarter Inc.) would work, their disadvantage is requiring said trusted party...

The bitcoin wiki describes a different method that doesn't require any third party:

Each backer creates a transaction with the amount to be pledged (this is an immediate step and required since the method doesn't allow for change
That transaction is used as input signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY, and the output is the to-be-funded address with the funding goal. Due to the input being less than the output, this transaction is invalid and shall not be published but instead transmitted to the recipient.
Once the recipient received enough transactions summing up to the funding goal, they can publish the assembled transaction

Unfortunately, this method has other drawbacks:

The funding goal must be exactly met (or a multiple of it), i.e. there cannot be stretch goals or overfunding
Since the input transactions are not spent until the funding is complete, the backers might accidentally spend that very transaction in another transaction

Ideally, script would provide means to determine whether a given bitcoin address (or in this case, the script itself) currently has at least a given amount of bitcoins available...


How to get staking balance using RPC commands

A staking system does not exists in Bitcoin's Proof-of-Work consensus model, that being said you will not find any "staking" related functionality in the RPC API. There have been several proposals for a Proof-of-Stake model where this would exist, but of course these have not yet been adopted or have reached any general agreement among the Bitcoin community.


If you have the secret, you can forget about the old wallet. Use the secret in any XRP wallet that accepts a secret. Gatehub does. The old Ripple desktop wallet does. Jatchili's minimal client does.


What are bitcoin/altcoin block notifications?

The -blocknotify="{cmd}" is one of the configurable settings when starting the bitcoin daemon. For example, I can start my bitcoind with this command:

bitcoind -blocknotify='echo %s'

And when a new block is solved, the block hash gets printed.

00000000000000000e979c4a51dc6cb9606e47a2b499f591645f53fe801ae374


Yes
Yes
Yes
Possibly
By making sure the node does not prune beyond the point the wallet was last loaded. You can either set the prune size large enough that enough blocks remain, or use manual pruning. With manual pruning you can determine how much to prune and when, using the pruneblockchain RPC command.


Why isn't there a fast blockchain update inside a LAN behind a router between two Bitcoin clients?

Because the bitcoin client tries to avoid being "fenced in" by an attacker who wants to control all the information flowing to it. It does this by connecting to more distant nodes, i.e. nodes which don't share the first two octets of the IP address. (update: the new address manager code still defends against this type of attack, but probably not in exactly the same way any more.)

If you know of a trusted nearby node, you can configure it with the -connectcommand line option or the connect= setting in bitcoin.conf.


Is there a limited number of addresses a wallet can hold?

Theoretically, no. A wallet is simply a collection of private keys (or a root key + scheme to derive more private keys, such as with BIP39 wallets).

However, after a certain point, you will start facing issues of scale. Most wallet applications will struggle to index transactions for hundreds of thousand or millions of addresses. Exchanges and other companies that deal with that many addresses will often build out special software tooling to handle tx indexing, coin selection, security, and other use cases that go up in complexity as the number of keys increase.

But from a purely crypto point of view, nothing prevents you from having any number of addresses in a wallet.


Cannot make valid Bitcoin Cash transaction

first (uncompressed pubkey):

sendrawtransaction 0100000001edc990f08c1ddd5102dfc7f4af32e7927a14fd8d0bc9996725f38ede549b91f8010000008b483045022100ed2a0f6644ff41b9baba8c35356a414b3da24edaea1bf68396efc7ffcbc5b8e902207b1b22c6201c2e4975cbbfc869632d4a2c89b46477b71ef6f875f1c844346d4d414104e1c33577152151109fe5e02c600f386fda865594c1b989ce0fcfbc0fb0b144a2c8fd98053fd86a4ccc7e0dcbcdd6a15c38eb32a27b3653c54f78ba00ffd71d19ffffffff0238300000000000001976a9141a586975175967c83e2b90422bcd8af9a623156288acfdc20d00000000001976a91470fb690a177e8721098d90284ab3c3304ee19cd588ac00000000
16: mandatory-script-verify-flag-failed (Signature must be zero for failed CHECK(MULTI)SIG operation) (code -26)

second (compressed pubkey):

sendrawtransaction 0100000001edc990f08c1ddd5102dfc7f4af32e7927a14fd8d0bc9996725f38ede549b91f8010000006b483045022100ed2a0f6644ff41b9baba8c35356a414b3da24edaea1bf68396efc7ffcbc5b8e902207b1b22c6201c2e4975cbbfc869632d4a2c89b46477b71ef6f875f1c844346d4d412103e1c33577152151109fe5e02c600f386fda865594c1b989ce0fcfbc0fb0b144a2ffffffff0238300000000000001976a9141a586975175967c83e2b90422bcd8af9a623156288acfdc20d00000000001976a91470fb690a177e8721098d90284ab3c3304ee19cd588ac00000000
16: mandatory-script-verify-flag-failed (Script failed an OP_EQUALVERIFY operation) (code -26)

input: https://blockdozer.com/insight/tx/f8919b54de8ef3256799c90b8dfd147a92e732aff4c7df0251dd1d8cf090c9ed

from address: 1BJPrnDajNczh8cQw2cHGgWyCcRXRDWNFU

checking pubkeys:

void checkpub ( )
{
  const MyByteArray classic    ( QByteArray::fromHex ( "04e1c33577152151109fe5e02c600f386fda865594c1b989ce0fcfbc0fb0b144a2c8fd98053fd86a4ccc7e0dcbcdd6a15c38eb32a27b3653c54f78ba00ffd71d19" ) );
  const MyByteArray compressed ( QByteArray::fromHex ( "03e1c33577152151109fe5e02c600f386fda865594c1b989ce0fcfbc0fb0b144a2" ) );
  qDebug ( ) << classic.hash160 ( ).toString ( );
  qDebug ( ) << compressed.hash160 ( ).toString ( );
}

the result:

"1BJPrnDajNczh8cQw2cHGgWyCcRXRDWNFU"
"1Fk7x75LYzySLi9e7wj9DBJkcAhe3kVcCa"

Conclusion: your first transaction with uncompressed public key is closer to be correct, but the signature is wrong. BitcoinCash has another algorithm for transaction digest calculation


Can Bitcoin help people commit money laundering?

Since the vast majority of money launderers seem to prefer cash, I'd say the answer is no. At least, not yet. The way money laundering works is that you hide illegitimate transactions in a sea of legitimate transactions. There are a vast sea of legitimate cash transactions which makes money laundering in cash work well. Until there are some high-volume Bitcoin businesses, there will be nothing to hide illegitimate transactions with.

Even if the idea is to buy Bitcoins with dirty cash, sell them at an exchange, and claim you bought them really cheap and held them for a long time -- where can you buy large numbers of Bitcoins anonymously for cash?


Is there a way to use the block chain as entropy in random number generator?

The Bitcoin Lottery used an SHA256 hash of the two most recent blocks to generate random data and to my recollection there were not too many complaints about that method they chose. In any case it's only good for 256 bits of questionably random data every 10 minutes (20 if you don't reuse blocks) so there are probably better entropy sources, such as the setup they've built over at random.org


Can I verify a sub public key came from it's parent public key in a HD wallet without involving any private keys?

Yes, you can, assuming that the child key isn't hardened, and you know the chain code of the parent public key and the index of the child. (Also known as the extended public key.)
Just compute

CKDpub((Kpar, cpar), i) → (Ki, ci)
Kpar is the parent public key, cpar is the chain code, i is the index, and Ki is the child public key

as defined here and compare it to the child key you were given.


Listtransactions in v. 0.4.0 - different behavior?

Yes, it was by design.  The old behaviour was accidental and was causing a crash in some situations.

Here are the full details:

In version 0.3.24, the 'from' parameter was simply passed into std::advance() to skip the required number of transactions.  If the value given was bigger than the number of available transactions, it would wrap around, due to how std::advance() works.  I'm not clear on whether advance() is defined to work like that, or if it's dependent on the particular implementation in the library your version was linked against.

Anyway, in version 0.4, the advance() function call was made conditional:

if (txByTime.size() > nFrom) std::advance(it, nFrom);

meaning to only skip some transactions if the number of transactions available is greater than the number you're trying to skip.

The change was made by Gavin Andresen on August 12, 2011 in response to a bug report


Your question contains many misconceptions.

Yes, it is perfectly fine and safe to generate private keys and their corresponding addresses completely offline and not connected to the internet. In fact, people recommend that you do this because it is safer than doing it online.

There is no central database (Bitcoin is decentralized) where you must register a private key and address. That is not how Bitcoin works, and there is no need to do this. You don't have to send your address or private key to someone else or register it with the blockchain. In fact, if your private key is sent to someone else, then that person can steal all of your Bitcoin.

If some site or software must be online to generate keys and it is sending the keys to the site owner, then DON'T USE THAT SITE. The owner is trying to scam you and steal your private keys, which means they can steal all of your Bitcoin.

Private keys can be safely generated offline because of mathematics. A private key is really just a very large number. The cryptography that Bitcoin uses defines a private key to be any integer between 0 and 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141, that's a lot of private keys. Any integer in that range is a valid private key. So Bitcoin Core and other key generation software will just generate a random number that is within that range. Because the range is so large, and because (in theory) good random number generators are being used, the probability that a private keys that you generate were also generated by someone else is so small that it is, for all intents and purposes, 0.

So any software where you can import that private key will recognize it as being valid and correct so long as the private key is within that range. From there, the public key can be computed, and from that, addresses.

You don't need to be online and register any addresses you create either. That is because the blockchain does not actually use addresses. It does not need to be able to find your address either. On a low level, the blockchain uses transaction outputs. When you create a transaction, it spends transaction outputs from other transactions, and creates new transaction outputs. These outputs are composed of two parts - the amount, and a spending condition.

Addresses are just a human readable way to represent the spending condition. When you send Bitcoin to an address, what you are actually doing is telling your wallet software what the spending condition for one of the outputs should be, so it will create a transaction with an output with the appropriate value and spending condition.

With most addresses (the kind that are associated to a private key), the address contains the hash of a public key. That private key for that public key is held by the person who gave you that address. When that person spends the Bitcoin you sent them, they consume the output you sent them and provide the public key and a digital signature. So the spending condition is that the spender must provide the public key whose hash matches the hash specified in the output, and a valid digital signature created using the private key corresponding to that public key.

So, addresses are not really identifiers or accounts that the blockchain needs to lookup, rather they are just a human readable way to specify the spending conditions for outputs. Thus there is no need to register addresses with anything. Furthermore, the blockchain doesn't even care what the spending conditions are. They could be completely invalid. The spending conditions are really just a blob of data and they are not checked in any way when a transaction is created. The spending conditions are only checked when the output is spent.


Send download link of a file after Bitcoin payment

You do not need to deal directly with the blockchain. The answer is:
Payment Gateways
There are services called Payment Gateways that encapsulate the entire invoicing/payment process and allow you to check on the status of each payment (manually or programmatically) to offer your goods.
One such example for bitcoin is Bitpay. Bitpay provides you with a RESTful API which you can call/query for information retrieval and/or for the execution of specific orders/transactions. You can find all the details in this API reference
As far as the implementation goes, Bitpay provides you with numerous clients in different programming/scripting languages, namely: PHP, python, Node.js, Ruby, Java, C# etc...
There are many bitcoin payment gateways available with different offerings and pricing schemes. Do some research to find the one most suitable for your budget and task.
Is it difficult to accomplish? Not necessarily. However, this is highly dependent on your level of skill and knowledge in programming specifically web development.
I would also recommend you hire a specialist to do this for you if your grip on security is not so well, since security is one of the major concerns when dealing with financial transactions.


Bitcoin-QT issues with non standard filesystem

Ok so its finally up and working.

With v0.9.3.0-g40d2041-beta the core process definitely crashes on that volume. Now with version : 110200 it appears as if its crashed, but doesn't. Setting the write catch to 512MB may have had an impact here.

14:44:48  getinfo

15:36:10
{
"version" : 110200,
"protocolversion" : 70002,
"walletversion" : 60000,
"balance" : xyz,
"blocks" : 388767,
"timeoffset" : -7,
"connections" : 1,
"proxy" : "",
"difficulty" : 79102380900.22598300,
"testnet" : false,
"keypoololdest" : 1385606583,
"keypoolsize" : 101,
"unlocked_until" : 0,
"paytxfee" : 0.00000000,
"relayfee" : 0.00005000,
"errors" : ""
}

Note the delay of 52 minutes for a console command to return a response. This probably indicates bad threading that an IO process can block the interactive terminal. Eventually though block processing does resume and it caught up 16GB worth of data.

I might look into it further so I can log a bug report.


Why can't we switch private and public keys?

The ECDSA signature algorithm used by Bitcoin doesn't have symmetry between its private and public keys.  If you read about how the algorithm works, they aren't even the same type of mathematical object: a private key is an integer, while a public key is a point on an elliptic curve.  They do not, in your words, "perform the same task."  So you can't do that.  (It's not at all clear why you would want to, in the first place.)

In fact, ECDSA is an algorithm for digital signatures, not encryption; ECDSA can't be used to encrypt or decrypt secret data at all.

The property that "each one can encrypt something the other can decrypt" is a special feature of the  RSA algorithm.  In this particular cryptosystem, signing and verifying (and encryption/decryption) use the same process; people sometimes say that signing in RSA consists of "encrypting using the private key". One could interchange the roles of the private and public keys, and the algorithm would still work mathematically.   But this isn't a general feature of all asymmetric cryptosystems.

(Even for RSA, although mathematically you could switch the private and public keys, this would totally blow its security: as typically implemented, the public exponent is an arbitrary integer that doesn't have to be secret, and people usually just use 65537.  But the private exponent is hard to compute without knowing the primes used to generate the key. So if you released what was intended to be the "private" key as your public key, people would have no trouble guessing the other key as well, and then you have no security.)


It takes about 200 vbytes to spend from a Lightning Network (LN) Hashed
Time-Locked Contract (HTLC) output used for routing a payment.  At the default
minimum feerate of 10 nBTC/vbyte, that makes it uneconomical to attempt to
claim a routed micropayment below about 2,000 nBTC ($0.008 USD at $4,000
USD/BTC).  As fees rise, larger and larger micropayments become uneconomical to
claim.

Worse, the default Bitcoin Core mempool policy attempts to prevent UTXO-set
bloat attacks by refusing to relay or mine any transaction containing an output
that would be uneconomical to spend at a feerate of 30 nBTC/vbyte.  This is
called the dust limit.  To obey this limit, LN nodes must not include HTLCs
for very small micropayments in LN offchain transactions---otherwise those
transactions couldn't be confirmed onchain if necessary and other value in the
channel could be stolen by a counterparty.

Currently, when LN nodes are asked to route payments below the dust limit, they
trim those HTLCs by increasing
the potential transaction fee of their channel by the amount of the
micropayment rather than adding an HTLC.  This fee only actually pays miners if
the channel is closed in a state that includes this fee---by mutual agreement
between channel counterparties, the fee can be removed in a later state.  This
creates three possible outcomes:

The fee is removed in a later state because both peers agree that the
micropayment completed successfully, so the amount is trasfered into a
normal-size output that's not subject to the dust limit.
The fee is removed in a later state because both peers agree that the
micropayment failed (either it was rejected or it timed out).  The earlier
state where the funds were held in a larger output is restored.
The two peers get into a disagreement about the payment and close the
channel.  In this case, the funds are actually transfered to miners and are
lost to whichever channel party was technically correct about the final
payment state.

Peter Rizun has
argued that, combined with rising Bitcoin transaction fees, this can lead to "the problem where even $50 payments are not 'trustless.' In the case where $50 is below the dust threshold [...], then HTLCs cannot be used to protect the $50 payment. Customers can lose $50 payments through no fault of their own."

It seems like he might be correct, although there are a few evasions we could
make about the current network behavior:

The amounts involved are currently tiny (about $0.02 at $4,000 USD/BTC).
Node operators who want to eliminate their risk can simply refuse to route
micropayments below the dust limit.
Those willing to accept limited risk can limit their maximum exposure (e.g.
only routing up to 10 payments below $0.02 for a maximum risk of $0.20).

However, what we really want is a fundamental solution to this risk---a way to
make even micropayments trustless.  Happily, the person quoted in the
question---Thaddeus Dryja (one of the original LN architects)---previously
described
how this might be accomplished.

Removing trust from inexpressible values

Above we described micropayments below the dust limit, which is a relay and
mining policy (meaning it can be changed without needing global consensus).
However, LN also allows micropayments down to 10 pBTC, which is 1/1,000th the
consensus-enforced 10 nBTC maximum precision of onchain Bitcoin.

When a channel contains some value that can't be represented onchain, the
remaining value is tracked in a database and LN commitments are made using
rounding.  For example, if 6 nBTC are paid from Alice's side of a channel to
Bob's side of a channel, she might actually send him 10 nBTC in an offchain transaction and the
extra 4 nBTC are tracked in a database to be credited towards subsequent payments.  If the channel is closed at this
point, Alice accepts that she's going to lose those 4 nBTC ($0.00002 USD at
$4,000 USD/BTC).

Given the tiny amounts involved, that seems like a perfectly satisfactory
solution---Bob's unlikely to pay an onchain transaction fee of 4,000 nBTC just
to steal 4 nBTC from Alice.  But, in early LN presentations, Dryja proposed an
alternative technique based on something occasionally discussed among Bitcoin
protocol developers: probabilistic payments.

Probabilistic payments are payments that only succeed a specified percentage of
the time.  For example, Alice wants to pay Bob 1 nBTC, but that's smaller than
allowed by Bitcoin.  Instead she offers him a probabilistic payment of 10 nBTC
(the smallest Bitcoin does allow) with 1-in-10 odds.  Nine times out of ten,
Bob gets nothing; one time in ten, he gets 10 nBTC.  If this is done with a provably fair protocol and the distribution amounts are symmetric to the odds (i.e. there's no house edge), then it's reasonable to believe that receiving 10 nBTC 1/10th of the time is equivalent to receiving 1 nBTC each time.

The exact mechanism described by Dryja is complicated and I don't know how well
it's been reviewed for security.  A large problem faced by all ideas for
probabilistic payments on Bitcoin is that they're hard or impossible to
implement in Bitcoin's very limited Script language.  Sidechains based on
ElementsProject.org, such as Blockstream Liquid, have re-enabled some disabled
math opcodes from Bitcoin plus added an
OP_DETERMINISTICRANDOM opcode
that make probabilistic payments much easier to implement there (although I'm
unaware of any specific work on a definite protocol).  Perhaps someday, these
opcodes or other similar features will become available on Bitcoin if there is
community demand for them.

Probabilistic payments to circumvent the dust limit

In the previous section, we saw probabilistic payments used to trustlessly get
around the minimum consensus precision of 10 nBTC.  We can use the same
mechanism to get around the dust limit trustlessly.  If it's uneconomical to
spend an HTLC output worth less than 10,000 nBTC, then we simply require
probabilistic payments for any amount below that.

For example, Alice wants to route a 1,000 nBTC payment through Bob.  Bob
requires her to create an HTLC paying him 10,000 nBTC with a 1-in-10 chance of
success.  Then the LN is processed.  If both Alice and Bob agree that it failed, they throw away the
HTLC.  If they both agree it succeeded, Alice simply adds 1,000 nBTC to a larger
output of Bob's, circumventing the dust limit.  If they disagree and the
transaction needs to go onchain, the probabilistic payment is run and, nine
times out of ten, Bob receives nothing (Alice gets her 10,000 nBTC back).  One
time out of ten, Bob receives 10,000 nBTC.  This can be made completely trustless, provably fair, and doesn't require any third parties.

As mentioned above, probabilistic payments are currently a lot of work to
implement on Bitcoin and effective use of them may rely on soft forks that are
just ideas now.  Moreover, while transaction fees are low and Bitcoin valuations
still make dust-size outputs worth just pennies, there's no real need to work
on complex solutions to the problem of people maybe losing a few cents---people who don't want that risk can simply disable routing payments below about $0.02.  But if
this becomes a real problem, it's a problem I think we can reasonably expect to
solve in a completely trustless way.

Addendum: an easier, less clever way to circumvent the dust limit

Several hours after posting the description above, it occurred to me that
there's an easier way to create trustless payments below the dust limit that
doesn't depend on untested probabilistic payments.  If Alice wants to route a
1,000 nBTC payment through Bob but the minimum economical onchain HTLC is
10,000 nBTC, she and Bob simply create two offchain outputs at the same time:
one where Alice pays Bob 11,000 nBTC and one where Bob pays Alice 10,000 nBTC.
Both HTLCs use the same hashlock and timelock, so they can both succeed or timeout at the
same time.  The net effect is a 1,000 nBTC payment to Alice if the offchain
payment needs to be settled onchain, plus the regular ability for them to agree on the outcome and update their main balances cooperatively.

Downsides include that this requires that Alice and Bob keep
more balance in their side of a channel than they otherwise would in order to
handle micropayments and that it costs them more fee overall.  This additional burden can be compensated by them
charging a higher fee for routing payments below the economical onchain rate.
This method also solves the problem in a completely trustless way and it's
something that shouldn't require significant research to implement, although
it's still perhaps a premature optimization while the current risk is measured
in pennies.

(Probabilistic payments are still the only way I know to deal with payments
below the minimum onchain precision of 10 nBTC, but that's not the question here.)


You can and should ignore those accounts. The accounts mean nothing; they are just an internal thing in Bitcoin Core and will be removed soon. Accounts are done by the address labels, so when you change a label for an address, you are changing its account. But that really doesn't matter and you should not be using the accounts system at all.


Practical difference between mainnet and testnet

The difference between a main net and test net address is exactly the first byte (and of course the checksum). The base58 encoding method is not different, but due to the first byte being different (and 256 doesn't divide by 58), the whole address does look different. For example:

Public key: 03919f9806cd4d07b588b14bcf7f5e8466d1c59f3694eb24101bbf59b91f933bfa
Main net address: 1KHL3He8D171NX8MpLH4XGsBqBjMmEDrHC
Test net address: myoHLLj722YG9dbyXuFSMC5WhBL4h7nqhs

I can't say what your problem was attempting the testnet transaction as you haven't given any details but there are no great differences between the two (raw transaction format or address formats etc.) or it wouldn't be much use as a test.


Is there a remote, trustless bitcoin API that doesn't require anything (blockchain/SPV headers) to be stored locally?

The BOP Enterprise Bitcoin Server is an open source full node implementation with remote (that is client side) wallet. The server downloads the block chain does the transaction and block validation and routes transactions signed at the client.

The client connects to the server via a message bus. There is a Java and other APIs available with added client side features. Source code: https://github.com/bitsofproof/supernode

Commercial support and hosted instances available at http://bitsofproof.com


Why was the Schnorr code removed from Bitcoin Core?

The Schnorr implementation was never in Bitcoin Core. Rather it is in the libsecp256k1 library that is a subtree in Bitcoin Core. The commit you reference is actually a commit in that library which appears in Core's commit history because the subtree in Core is periodically updated with the libsecp256k1 upstream source code.
The reason for removal is explained in the pull request that removed it:

This module implemented a naive custom Schnorr signature scheme, though several flaws have been discovered with its approach since (lack of commitment to public keys, ability for 3rd parties to adapt signatures to related keys, and a multisigning API that is vulnerable to cancellation attacks, restart attacks that leak a private key to cosigners).
I have been working on a better scheme, but I don't believe this should be upstream until it's been vetted in more thorough ways. People assumed that it being included in the repository was a sign that it was final, so I'm removing it to avoid any confusion.


OpenSSL and Secp256k1 differing in implementation of ECDSA signatures?

The code you are referring to in libsecp256k1 is not for ECDSA.

It implements the custom compact signatures that Bitcoin Core uses for message signing and verification.

The normal ECDSA code in libsecp256k1 should be identical in acceptance to the one in OpenSSL (apart from the fact that by default, it only accepts and produces low-s signatures, as a way to reduce malleability potential).


Merkle trees in general are useful in the context of a prover-verifier model.
A prover Peggy wants to prove to verifier Victor that a merkle root R, which Victor knows ahead of time, commits to a tree which includes a specific leaf L.
To do so, Peggy would send the element L well as the Merkle proof (or branch) containing all hashing partners L is combined with to produce R. In your example diagram, that proof consists of Hk, Hij, Hmnop, and Habcdefgh. Victor uses these elements to recompute R from it, and compare it with his pre-existing knowledge of R.
So to answer your question: certainly something has to keep Hk (or the elements that has to it, so it can be recomputed), but it doesn't need to the same party as the one that does the verification. If there is only one party involved, there is nothing to prove.


You cannot.
There have been both changes to the P2P protocol that prevent this, and changes to the way that nodes are discovered.
The method which 0.1.0 discovered new nodes was by joining the #bitcoin channel on freenode. Your IP address would be encoded in a certain way and that would be the IRC nick for your node. However this has long since been removed from the Bitcoin software and any node that does connect to the #bitcoin channel will be kicked from it (the encoding is unique and identifiable).
Since 0.1.0 can't connect to the IRC channel to discover new nodes, it is unable to learn about nodes that it can connect to.
Furthermore, the P2P protocol has changed since 0.1.0 was released and thus 0.1.0 is unable to communicate with modern nodes. This change was to add a checksum to the end of the P2P message header. Messages without this checksum will be rejected by modern nodes.
Lastly, 0.1.0 is too old so modern nodes won't connect to it. They have a minimum supported protocol version number, and 0.1.0's protocol version number is far too low. So even if you could get it to connect, the connection would be dropped.

The way to deal with the node discovery issue is to manually modify the peers.dat file to have the IP address and port of nodes that you want to connect to.
The only way to deal with the P2P protocol changes (checksum and version number) is to have a shim that sits in between all of your connections and modifies the P2P messages to work with modern node software. Or you can connect to a modified node which can deal with 0.1.0 traffic.

Even if you are able to connect to the Bitcoin network with 0.1.0, you won't be able to mine anything as the CPU mining is no longer viable, and the CPU miner implementation in 0.1.0 is not efficient. You also wouldn't be able to even sync as it syncs too slowly. Blocks will be found faster than it is able to process them. It will run into additional issues when it receives a new block before it is able to sync the blockchain that precedes that block.


Segwit change address from Regular address

It's not possible to do this automatically. Electrum doesn't mix and match segwit and non-segwit address types in the same wallet.

My suggestion is to first educate yourself on what using an Electrum segwit wallet will mean. Electrum uses bech32 addresses. You can read more about the implications of that here.

Next, if you decide you want to move to segwit after all you can create a new electrum wallet choosing segwit as the type and then move your coins there. In order to save money you can low ball the fee. Fees are actually quite low these days so you should be able to do this quite cheaply.

Electrum allows you to send money to multiple addresses in a single transaction so the next time you send bitcoin you can choose to send the balance funds in your wallet to an address in your new segwit wallet. To send to multiple addresses you enter the addresses as follows on the pay to field on the send tab:

1BitcoinEaterAddressDontSendf59kuE,0.5
bc1addressdfdfdfdfdfdfdfd,1.55

That is addresses and amounts separated by commas. Each address + amount on a separate line.


I'm a total newbie but so far the problem appears to be solvable. This is what I did with my Altera DE2-115 hooked-up to a Windows 7 machine:

got fpgaminer's open source FPGA bitcoin miner on Github
got mining proxy on bitcoin.cz
set up an account with slushpool.com (had to use VPN because my ISP apparently blocks connections to slushpool over http :((( )
registered an online BTC wallet with blockchain.info
updated config.tcl to connect to localhost:8332 port and reflect my slushpool-related credentials
downloaded miner's bitstream into DE2-115
launched mining proxy
and finally ran mine.bat

Illustration: FPGA miner accepting jobs via Stratum rather than thru getwork protocol

The hashrate was indeed around 50 Mh/sec but after ~10 seconds the Cyclon IV chip got rather hot, so I decided to play it safe and stopped mining. As the next step I'm planning to install an active cooling system to continue experiments such as switching from my Windows rig to Raspi, mining altcoins, etc.


New to Bitcoin - tips on securing my server

First of all, I'd suggest to create a separate user account for this:

adduser bitcoin

And use that account to run your bitcoind from.

You can open the port 8333 on your firewall if you want to provide a "full-node" to the network, but do not open the port 8332 (that's for RPC).

For better security though, I don't recommend using the same bitcoind instance for both wallet-storage and as a public node. If you can afford two machines, set up the wallet on one of them (this will be a "private" instance) and a "border-router" instance on another. Then make sure the private one only connects to the border-router (use connect=<border_IP>) configuration option. Then you can feel safe to enable port 8333 on the public border-router machine and as an optimization, you can disable the wallet on it (-disablewallet).

Once you have it all set up, you can proceed to creating an address. Run:

bitcoin-cli getaccountaddress myaccount (use any account name you like)

Here you can find a nice command reference.


Bitcoin wallet file location in smartphone

For the Bitcoin Android wallet, you can do a backup from inside the app.  The backup will be located here by default /sdcard/Download/bitcoin-wallet-backup-<yyyy-MM-dd>.  See the Files section of this page for more details.


What would Bitcoin be like with two block chains?

Most other crypto coins is more or less what you describe.

The bitcoind code has build-in "checkpoints" (block height x has hash y), but a new blockchain would anyway use a "new" ( / forked ) client, so you could just remove these checkpoints.

However the 21 million bitcoin limit will never be a problem. Today each bitcoin can be divided down to 8 decimal places (0.00000001 BTC), should we for some weird reason need more bitcoins, then this limit can be changed.


Someone wrote a Bitcoin protocol decoder for Wireshark, several years ago. I assume it was included in the Wireshark distribution.

Wireshark simply knows about the Bitcoin protocol. There is no magic involved.


Erroneous blockchain transactions...more coins than I specified!

The 58000 coins have gone to a change address in your wallet. When you sent 2000 from the 60000 UTXO you've had 60000 go out to two inputs: your change address and the spending address.

Keep this in mind: when spending from a single input you're  sending the whole lot!


Get public or private key from address with C-lightning

lightningd doesn't offer simple RPC commands to dump keys.
If you really need to access the keys the simplest way would be to derive them directly from the hsm_secret.
Keys for onchain transactions (since you mentioned newaddr. The other derivations are more involved) are derived using BIP32 unhardened derivation from m/0/0.
The root seed is derived from the hsm_secret with :
root_seed = hkdf_sha256(hsm_secret, salt=NULL, info="bip32 seed")

There exist tools such as the hsmtools (which currently only derive keys for the commitment transactions but might be extended in the furure) or jb55's clightning-dumpkeys which take care of the derivation for you.


Could you use ASICBOOST on Bitcoin Cash?

Yes, ASICBoost works on the Bitcoin Cash blockchain because the block header format of Bitcoin Cash blocks are the same as the block header format of Bitcoin blocks. ASICBoost operates on the block headers. Furthermore, both overt and covert ASICBoost work on Bitcoin Cash.


Change can be sent to any address separately specified in the transaction for the change or, paid as fees to the miner if not.

Looking at the examples, it is clear that where the specification mentions change in the path it might well be intended to read chain with possible options of either change or external.

This leads me to believe that depending on who the change is meant for (whose inputs the change is from) - BTW if you are the receiver and not the sender then the change is not for you - then the change derivation path will be either of:

m / 44' / 0' / 0' / 1 / 0 #Account 1
m / 44' / 0' / 0' / 1 / 1 #Account 2


Can not decode transaction. Script was manually verified successfull

Your transaction has 4 extra bytes at the end.
Just remove the 01000000 and it should be fine then.


How can I generate public address from an xpub key in Java?

I have to deserialize xpub key then use its derivation path to get a child path or normal key. From a normal key, it is easy to convert the public key to address.
You can refer to this source code.
https://github.com/tatumio/tatum-java/blob/master/src/main/java/io/tatum/wallet/Address.java#L24
Thanks


How can i sync only the last month of the blockchain with bitcoin core?

You can do that with Bitcoin-core but it's not recommended, You may want to use electrum instead of Bitcoin-core.

You don't have to download the blockchain using electrum.org.


How will Ripple affect Bitcoin exchanges?

As Ripple appears to allow one to create exchange listing for any pair of currencies, it might very well server as an exchange unto itself. It is possible that the project will replace the traditional exchanges, possibly turning them into Gateways to put money in and out of the system instead.

Then again, that might be far in the future - at the present time there is a healthy amount of scepticism surrounding how safe the Ripple system is, so not a lot of people would be willing to abstract their money even further with it than they are used to.


Do pool operators usually set block version numbers before their clients hash?

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

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

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

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

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

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

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

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


How can I combine all the tiny amounts I've received to minimise transaction fees, and do I need to?

I have not actually done this, but here is how I understand it. With many tiny amounts, you probably want to consolidate them because the fees for transactions with lots of inputs will be high. Now you ask, by consolidating, won't I just be paying the fees in advance? The answer is that by planning ahead and consolidating them, you can use the low-fee mining pool Eligius to do it.

To estimate the cost of the transaction, I'm going to use only the transaction size (for large transactions, the fee is dominated by or entirely consists of the cost per KB). This is based on the number of inputs and outputs. If all your balances are the same (0.01 BTC), then it doesn't matter how much you spend at at a time, the fee grows linearly with the total BTC amount.

Assuming 180 bytes per input, 1000 inputs comes to 175KB, which I'm going to round up to 200KB for a safety margin. With the official client, at the default 0.01 BTC / KB fee [1], that would cost 2 BTC.

Eligius will mine transactions for a fee of 0.2 TBC (0.00008192 BTC) per KB [2]. So Eligius's fee would be 0.016384 BTC. Might as well round that up to 0.02 BTC or higher just to be sure.

If your coins are old enough (say, 3 months for 10 BTC and a 200KB transaction size) [3], then the official client might not enforce the minimum fee on your transaction. Otherwise you may need to use a modified client that doesn't enforce a minimum fee.

In any case you will need to point your client to Lightfoot Hosting's free transaction relay, which will relay any transaction to the network [2], so it can be picked up by Eligius.

It may take longer than usual, but Eligius should eventually mine it.

As for combining the "dust" while leaving larger balances alone -- you would have to find a client that allows you to choose the inputs to your transaction. I don't know which clients can do that.

[1] https://en.bitcoin.it/wiki/Transaction_fees (The fee calculations on this page are as of client 0.3, so they may be outdated.)

[2] https://en.bitcoin.it/wiki/Free_transaction_relay_policy

[3] Wiki link [1] above says that transactions with priority over 57,600,000 aren't subject to the minimum fee calculation. If this is true, then 10 BTC with an average age of 3 months in a 200KB transaction would have a priority of (1000000000 * 144 * 90) / (200 * 1024) = 63,281,250